Transparent GIFs

> Did you look at Graphics.PNGImageReader found in parcel ImageReaders?
> PNG seems to be a better-fitted format for these types of tasks, given
> that it supports more types of palettes and transparency. PNG is also
> "open" and free to use.
>
> I poked around using this class and found that I could send #mask to
> the reader in order to obtain a Depth1Image containing the mask.
> Sadly, for all images the mask was completely filled (all back).
>
> Previously I have learned that VisualWorks currently only has proper
> support for black/white (1-bit) masks, and therefore I looked more
> deeply into how "Color Type 2" is supported. I did not try using alpha
> samples for transparency. With color type 2, "each pixel is an R,G,B
> triple." In addition, both 8 and 16-bit color values are supported. I
> only looked at 8 bit support (16,7 million colors). With color type 2,
> a single color value is specified as being the transparent color.
>
> I then tried running image TBRN2C08 from the PNG test suite:
> (ImageReader fromFile: 'TBRN2C08.PNG') mask
> Still the image was totally black.
>
> Looking at the code, I found that transparentPixelValue was wrong.
> Method #processTransparencyChunk seems to have a bug, and I changed
> the line
> transparentPixelValue := ((65280 + red bitShift: 8) + green bitShift: 8)  
> + blue.
> into:
> transparentPixelValue := ((red bitShift: 16) bitOr: (green bitShift:
> 8)) bitOr: blue.
>
> Note that my change only corrects the scenario I describe. It might
> introduce other problems. Maybe Cincom could look at it.
>
> After doing the changes, I was able to obtain a correct Depth1Image
> for the example. Using this I it is easy to create an OpaqueImage:
> OpaqueImage
> figure: (ImageReader fromFile: 'TBRN2C08.PNG') image
> shape: (ImageReader fromFile: 'TBRN2C08.PNG') mask
>
> Having succeeded with this, the task now is finding a paint program
> that allows making "Color Type 2" PNG images. I did not look at this
> yet.
>
> PNG specifications are at  
> http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html
> Test suite are at http://www.schaik.com/pngsuite/
>
> Runar Jordahl
> http://www.cincomsmalltalk.com/userblogs/runarj/blogView

> thanks, I was aware of the PNG reader but not that PNG could be used for
> creating transparent images, I thought it was like a higher end JPG.
> Unfortunaltey, it seems that at least as far as transparency the VW
> implementation is not ready for prime time.
>
> When using tools like Photoshop etc there is a right way i.e. as far as
> VW is concerned to create transparent GIFs. More specifically, there is
> a way that will work with ArborGIFImageReader. I have not found a way of
> making the stock GIF reader work as far as transparency.
>
> The good news is that the ArborGIFImageReader works fine and that as far
> as we are concerned GIF is a fine enough format for creating transparent
> images. The specific transparency option that we must use does not seem
> to be, as far as we are concerned, to be a big sacrifice. I'll share
> that when I recall what that is. Also GIF works fine for us. These
> images are used strictly for icons and sometimes some other embellishments.
>
> thanks for the info on PNG.
>
> -Charles

> How is the stock GIF reader not working for you? I've been using it for  
> a couple of years now to import all icons for VW from external  
> transparent GIFs.
>
> See ImageReader class>>iconFromFile:toClass:selector:. Or using the  
> reader "by hand", you send #image to the reader to get the figure for  
> your opaque image and #mask to get the mask. (And then you'd probably  
> want to wrap those in CachedImage).
>
> PNG reader doesn't handle transparency, that's true.
>
>
> Charles A. Monteiro wrote:
>> thanks, I was aware of the PNG reader but not that PNG could be used  
>> for creating transparent images, I thought it was like a higher end  
>> JPG. Unfortunaltey, it seems that at least as far as transparency the  
>> VW implementation is not ready for prime time.
>>  When using tools like Photoshop etc there is a right way i.e. as far  
>> as VW is concerned to create transparent GIFs. More specifically, there  
>> is a way that will work with ArborGIFImageReader. I have not found a  
>> way of making the stock GIF reader work as far as transparency.
>>  The good news is that the ArborGIFImageReader works fine and that as  
>> far as we are concerned GIF is a fine enough format for creating  
>> transparent images. The specific transparency option that we must use  
>> does not seem to be, as far as we are concerned, to be a big sacrifice.  
>> I'll share that when I recall what that is. Also GIF works fine for us.  
>> These images are used strictly for icons and sometimes some other  
>> embellishments.
>>  thanks for the info on PNG.
>>  -Charles
>
>

> Charles A. Monteiro wrote:
>> ah, so that perhaps the issue is with the definition of "supported". I  
>> feel it reasonable that one should be able to tell an ImageReader to  
>> load a file and return a readily displayable object i.e. an object that  
>> does not require any further manipulations in order for it to render as  
>> intended.
>
> The issue is actually with the definition of "image". VW understanding  
> of it does not include transparency. You cannot have Images with  
> transparent pixels that you could just read from a file and display.
>
> OpaqueImages are not Images. They are not even PixelArrays. They are  
> displayable, but anything you can do to an image, like change the color  
> of a pixel, you can't do to an OpaqueImage. This is the point of view of  
> GIFImageReader--it preserves the protocol of #image as something that  
> answers an Image, and adds an extra method for the opacity information,  
> as something that doesn't fit in the pure Image model.
>
> I do think GIFImageReader is missing an #opaqueImage method. But,  
> redefining #image to be "smart" and return OpaqueImage when image has  
> transparency is actually a rather misguided hack that dilutes the  
> protocol of #image. It should be a different method instead, something  
> like #displayableObject. As it is, all you can expect from the result  
> now is that you can send #displayOn: to it--but you no longer know it's  
> an Image, with pixels, palette and all those other things. And, whether  
> you get a real image or not depends only on the input.
>