Community
Participate
Working Groups
Image encoders (note: encoders, not decoders) are only currently guaranteeing to work with an ImageData as provided by the matching decoder. This is not very useful since to really manipulate the ImageData a user often needs to create an Image and then gets a different ImageData back. Image encoders should check the ImageData passed in and use the internal ImageData.bitblit call to convert it to a supported format (depth/scanlinepad/palette features). If a user needs more elaborate control over the details of image encoding (level of compression etc.), a third party library dedicated to handling image formats will have to be used. The proposed change will only serve the basic needs.
Do I understand correctly that this bug was split off from Bug 38186, and that voting for this bug will allow people to save images as GIF files?
Saving an ImageData as a GIF is expected to work if your image data is of bit depth 1, 4 or 8. If you wish to be able to save into GIF an image with a different bit depth, yes you can vote for this PR.
ICO probably needs to handle more depths also. Here's the current depths handled: boolean isValidIcon(ImageData i) { if (!((i.depth == 1) || (i.depth == 4) || (i.depth == 8))) return false; int size = i.palette.colors.length; return ((size == 2) || (size == 16) || (size == 32) || (size == 256)); }
*** Bug 120722 has been marked as a duplicate of this bug. ***
Also, from the newsgroup: [Eclipse 3.2M3, gtk] Snippet194 (write an animated gif) throws with message "Unsupported color depth" under linux. This is because the return value from Image.getImageData() is always 24-bit-direct, since Image.init() blits the 4-bit indexed data into 24-bit direct data.
*** Bug 168071 has been marked as a duplicate of this bug. ***
I see the same behavior as comment #5 on MacOS X Even though I'm creating an Image using Indexed (isDirect == false) ImageData with a depth of 4 (or 8), the image created always has a depth of 32 and is direct, due to the Image.init() blit call, resulting in "unsupported color depth" errors when using ImageLoader.save Can you verify whether or not this will be addressed as part of the Linux-GTK duplicate bug
so.... is there a solution for this problem? i'm trying to create some ImageData instances and put them into an array for the imageLoader instance, and it still gives me the depth error. i do not want that the ImageData instances will be restricted to a very few number of colors... please help.
The issue still exists on E4.10, can it be fixed? We have lots of TIFF images getting this error!
Do you mind trying on Gtk with latest version? SWT now uses the gdkpixbuf library which has far better and broader support.
