GNOME Bugzilla – Bug 115793
Discrepency between display and preview for INDEXEDA images
Last modified: 2004-01-11 17:42:33 UTC
As reported in bug #55700 and bug #86627, there is a display problem for indexed images with alpha: the image display shows the thresholded alpha, but the preview (in the Layers dialog) shows the progressive transparency. See for example the image in attachment (id=17663) submitted by jimmac: http://bugzilla.gnome.org/showattachment.cgi?attach_id=17663 This PNG screenshot shows an image (on the left, with thresholded alpha) and its preview (on the right, with full alpha). Even if fixing or improving the INDEXEDA mode could take some time (see the discussion in bug #86627), it would be nice if the image display and its preview could show a bit more consistency (either both thresholded or both full alpha).
I had a look at this code, and it seems to me that the code that thresholds alphga in indexed images isn't in the projection or display code, as asserted before, but is actually in the indexed code. In gimpimage-convert, function median_cut_pass2_fixed_dither_gray lines: 2970 if ((dest[ALPHA_I_PIX] = 2971 ((alpha_dither ? 2972 ((src[ALPHA_G_PIX] << 6) > (255 * dmval)) : 2973 (src[ALPHA_G_PIX] > 127) 2974 ) ? 255 : 0))) And again, function median_cut_pass2_no_dither_rgb, lines 3045 if ((dest[ALPHA_I_PIX] = 3046 (alpha_dither ? 3047 ((src[alpha_pix] << 6) > (255 * DM[(col+offsetx+ 3048 (src[alpha_pix] > 127) 3049 ) ? 255 : 0) And again, median_cut_pass2_fixed_dither_rgb, lines 3138 if ((dest[ALPHA_I_PIX] = 3139 (alpha_dither ? 3140 ((src[alpha_pix] << 6) > (255 * dmval)) : 3141 (src[alpha_pix] > 127) 3142 ) ? 255 : 0) And again, median_cut_pass2_nodestruct_dither_rgb 3242 if ((has_alpha && (alpha_dither ? 3243 ((src[alpha_pix] << 6) > (255 * DM[(col 3244 (src[alpha_pix] > 127))) 3245 || !has_alpha) ... 3283 else 3284 { /* have alpha, and transparent */ 3285 dest[ALPHA_I_PIX] = 0; 3286 } And so on... Seems to me like the quantisation is done to the alpha channel at the time we convert to indexed, not when we display it. I'm not sure what we do in the png loading though... Anyway, this is backed up by the fact that when you get an indexed image in a plug-in, the alpha channel is always either 0 or 255. Cheers, Dave.
Bolsh, this code you quote is only executed if you convert from RGB to Indexed. There is some code in the projection that causes the problem this bug-report refers to. The code you quoted is not used in this particular case.
I was going to reply something similar to what Sven has just posted: what happens when an image is converted from RGB[A] to INDEXED[A] is one thing, but there are other ways to create an INDEXEDA image. In addition, some operations performed later on the image may introduce alpha values that are different from 0 or 255. Did you look at the screenshot provided by jimmac and linked from my description of the bug? The problem is quite obvious in this screenshot.
Created attachment 17920 [details] another screenshot (PNG, 20KB)
The screenshot above shows another example of the problem. I loaded the toucan image from http://www.libpng.org/pub/png/pngs-img.html (I used the one on the left, called stefan_pal_rgba.png). As you can see, the image view shows a thresholded shadow while the preview in the Layers dialog shows the shadow with full alpha. You can also try with the sample images mentioned in bug #86627.
Yes, I have looked at the screenies. I don't see any code in the png loader which thresholds the alpha channel, and as teh preview shows, there's an alpha channel there to be saved. But I don't see where in the display code the alpha channel gets thresholded. Could you point out where this happens, please? Cheers, Dave.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
The thresholding seems to take place in paint-funcs/paint-funcs.c, in all appearances of the number 127 except the ones in the function compute_transition, and in the function initial_indexed_a_pixels in paint-funcs/paint-funcs-generic.h. Hope this helps.
After taking a closer look at the code which thresholds alpha for indexed images, I don't think that the thresholding can be safely removed for 2.0. As a suggested temporary solution, the following patch adds the same threshold to the previews so that they are consistent with the image.
Created attachment 23231 [details] [review] Suggested patch to fix bug #115793 for 2.0
Forgot to add the PATCH keyword.
Looks good to me!
2004-01-11 Pedro Gimeno * app/core/gimpdrawable-preview.c (gimp_drawable_preview_scale): Apply threshold to alpha in the same way as it is applied to the image in indexed mode. Fixes bug #115793, at least until the alpha thresholds in indexed images are removed. * plug-ins/FractalExplorer/Display.c: Fix zoom undo handling issues. Closes bug #82478.