Bug 360422

Comment 1 Ravikanth Somayaji 2011-10-10 06:47:59 EDT

More observations - if I load it using the ImageData constructor the image depth is 16 bit and palette.isdirect is false.

However, when I load it using the Image constructor with a null device, the image depth is forced to 24 bit and the palette.isdirect is set to true.

I agree if my display is a 24 bit then the image information would be changed to 24 bits, but why when I provide a null device it does the same?

Comment 2 Ravikanth Somayaji 2011-10-10 06:59:28 EDT

Okay, now I understand why even a null device converts the 16 bit image to a 24 bit image. Is there a way to keep it at 16 bit and palette data false and still get the Image constructor to load the image?

Comment 3 Ravikanth Somayaji 2011-10-10 07:15:54 EDT

Okay, now I understand why even a null device converts the 16 bit image to a 24 bit image. Is there a way to keep it at 16 bit and palette data false and still get the Image constructor to load the image?

Comment 4 Carolyn MacLeod 2011-10-11 10:38:47 EDT

Would it be possible for you to attach the image? Thanks!

Comment 5 Ravikanth Somayaji 2011-10-11 11:01:12 EDT

Created attachment 204955 [details]
Image size scaled to 1002x668

Please find image attached. Although, actual size of the image is 4 times this.

Comment 6 Carolyn MacLeod 2011-10-11 14:52:21 EDT

Just some observations, for now.

Please don't use null for Display - you should always use "display".

On Linux, I can load the attached image (as depth 24, direct palette) using:
   new Image(display, filename); // uses native loading
but I get the "Unsupported color depth" error when I try to use:
   new ImageData(display, filename); // uses non-native java code to decode image

On Windows, the native loader loads without throwing an error (depth 16 direct palette), but it looks funny (blue and green instead of black and white).
The non-native loader has the same Unsupported color depth error as Linux.

On Mac, the native loader works, and it converts the loaded image to depth 32 (direct palette). The non-native loader has the Unsupported color depth error.

I am not sure why you are getting palette.isdirect is false, and I am getting a direct palette for this image.

There are a few similar bugs here: bug 37767, bug 92626, and possibly bug 38232 (which says it is for encoding, but some of the trouble is with the decoder).

Are you able to use native loading? (i.e. new Image(display, filename))
Or do you need to use non-native (i.e. new ImageData(display, filename)) for some reason, like perhaps you need to load from a stream? (I do not have the source for ImageFigure, so I don't know what it is doing).

Comment 7 Ravikanth Somayaji 2011-10-12 08:30:07 EDT

I have succumbed to using new Image(display, image, SWT.IMAGE_GRAY) which gives me the image in Gray scale, more what i wanted in the first place.

However, like you said, I don't understand why I see palette.isDirect false in my case. that may probably be because of the image encoding.

Is there any way to retain the Image depth as 16 bit even though the display is 24 bit. This would help in future processing of the image, in the case that I wouldn't need to right shift my bits to get the expected value.

Comment 8 Carolyn MacLeod 2011-10-12 14:18:56 EDT

In bug 92626 comment 8, SSQ said that X Windows had a limitation that XCopyArea() required that the destination and source drawable have the same depth. So a Pixmap that was created with a depth other than the root drawable depth (screen depth, i.e. 24), would have to be converted (which would be slow, or take more memory). However, it may now be possible to compose drawables with different depths using the XRender extention. This needs to be fully investigated. Unfortunately, we do not have the resources to do this at this time (i.e. we are all maxed out). If you are interested, you can look at the code in Image.java. We may need to remove some deprecated items, like gdk_pixbuf_render_to_drawable and anything to do with GdkImage. We may need to switch to Cairo Image surfaces to get the behavior you want: http://cairographics.org/manual/cairo-Image-Surfaces.html. Or perhaps we can get away with using gdk_pixbuf_copy_area. I don't know - I would have to spend some time to try it out, and as I mentioned, my slate is full for now. I would be happy to make time to review a patch.

Comment 9 Eric Williams 2018-08-30 14:53:28 EDT

We have since switched to Cairo, so the issue with XCopyArea() should no longer be an issue. Please reopen this ticket with a snippet if the issue continues on 4.9 with GTK3.22.