Community
Participate
Working Groups
Build Identifier: 20110916-0149 I have a 16bit unsigned image which I'm trying to load into an Draw2d canvas using ImageFigure. When I load the image using the SWT image constructor, the image canvas throws an SWT Exception stating that the Image has an unsupported colour depth Reproducible: Always Steps to Reproduce: 1.Use a 16bit unsigned image 2.Load the image into SWT Canvas or Draw2d canvas using an ImageFigure
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?
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?
Would it be possible for you to attach the image? Thanks!
Created attachment 204955 [details] Image size scaled to 1002x668 Please find image attached. Although, actual size of the image is 4 times this.
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).
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.
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.
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.
