GNOME Bugzilla – Bug 157915
Retinex filter preview widget misbehaves
Last modified: 2005-06-21 18:08:07 UTC
this one's easy to reproduce, but the technique isn't easy to document. while trying out the different levels of retinex, using the radio buttons and preview widget provides, the preview sometimes turns grey, black, displays incorrect previews or gets stuck on a certain portion of the image. ah, one issue is that the filter is only applied to the area of image currently in focus of the preview widget, I haven't explored this filter much yet but it appears that results vary hugely based on how much of the image is processed. steps to attempt to reproduce: 1. open an image that will give you a reasonable area to scroll in the preview widget 2. bring up the retinex window 3. start abusing the preview widget, scroll around it by dragging inside the preview area, switch between levels a bit, that kind of thing.
The fact that the preview is sometimes not accurate because it only works on the previewed area is a known side-effect. If it turns out that it is not acceptable for Retinex, than we should probably better remove the preview there.
Would be nice to get some comments here. Otherwise we will just have to remove the preview from the Retinex plug-in for 2.2.
Perhaps an aspect preview (showing a scaled-down version of the full image) would work better here?
2004-11-13 DindinX <dindinx@gimp.org> * plug-ins/common/retinex.c: use a GimpAspectPreview instead of a GimpDrawablePreview. Fixes bug #157915. Also fixed the funny behaviour of the progress bar.
It still does it in Gimp 2.2.1 -- namely it (or its lower part) turns gray or black. I was about reporting it as a new bug... It doesn't seem to be reproducible on all images now, so I'll attach one on which I can observe it easily. Comment #1 IMO offers a false explanation because the preview is *always* good in a fresh dialog, no matter mode or parameters. It is corrupted when settings are *changed*, even back to initial settings which it displayed the preview correctly with.
Created attachment 35517 [details] Test case
At the moment I'm not able to check this. However the algorithm behind retinex does not guarantie that always a correct result is achieved. below a snipset of the code : parameters alpha/gain and offset are here arbitrary choosen (after reading a lot of documents). They basicly TRY to shift/limit the output of the algorithm back into a range that can be converted without serious loss to O .. 255. /* Final calculation with original value and cumulated filter values. The parameters gain, alpha and offset are constants. */ /* Ci(x,y)=log[a Ii(x,y)]-log[ Ei=1-s Ii(x,y)] */ alpha = 128.; gain = 1.; offset = 0.; for (i = 0; i < size; i += bytes) { gfloat logl; psrc = src+i; pdst = dst+i; logl = log((gfloat)psrc[0] + (gfloat)psrc[1] + (gfloat)psrc[2] + 3.); pdst[0] = gain * ((log(alpha * (psrc[0]+1.)) - logl) * pdst[0]) + offset; pdst[1] = gain * ((log(alpha * (psrc[1]+1.)) - logl) * pdst[1]) + offset; pdst[2] = gain * ((log(alpha * (psrc[2]+1.)) - logl) * pdst[2]) + offset; } Probably as mentioned in the enhancement report (do not have the number at hand) These parameters could also be made modifiable with the above mentioned values as a default.
I think this can't explain the problems. Sometimes the preview doesn't become gray or black but strangely shifts instead. I'm attaching screenshots. However, if it's an uninitialized values/corrupted memory problem (like it seems to be), it may be hard to reproduce even on the same image.
Created attachment 35535 [details] Fresh dialog screenshot
Created attachment 35536 [details] The same dialog after mode change
Created attachment 35537 [details] The same dialog after another change
Little remark : I haven't yet figured out how gimp_drawable_get_thumbnail_data (drawable->drawable_id, &width, &height, &bytes); works But if it works on a stored copy of a thumbnail (previously generated) and a alpha layer was added or removed during image processing without regenerating the thumbnail. Then the difference in BPP between drawable and thumbnail could explain the shift of the image
explain why I think there could be a difference : the preview widget is initialised with the bpp of the drawable and not with the bpp of the thumbnail : therefore a difference in rowstride occurs.
gimp_drawable_get_thumbnail() retrieves the thumbnail out of the core's thumbnail cache.
Haven't been able to pinpoint the exact cause but it seems reproducable with all images where 1:2 > height/width 2:1 < height/width
Valgrind showed the problem immediately. Fixed in both branches. 2005-06-21 Bill Skaggs <weskaggs@primate.ucdavis.edu> * plug-ins/common/retinex.c: initialize memory before using. Fixes bug #157915.