Hi -

just ressurrecting the thread to get the ball rolling again.

It looks like this still remains to be rewritten for GEGL?

(what lead me to do this? I've hit the "retinex" filter description while translating the
GIMP manual, and went happily to gimp master to check how retinex would behave in a 32 bit per channel image - just to find it was not there)

On 29 July 2010 11:08, Geert Jordaens wrote:

hello,

I'm trying to port the retinex operation of gimp to a Gegl operation and facing following problems.

First approach :

1. a GeglOperationMeta since the Retinex algorithm depending on the parameters needs multiple blurred images (gegl:gaussian-blur).

2. The difference between the original image and each of the blurred images have to be summed an result in an intermediate image. This seems not possible without implementing an operation with a specific calculation :

intermediate[n] += weight * (log (input[n] + 1.) - log (blur[n]))

3. The next step would be another specialised op that performs :

logl = log(intermediate[0] + intermediate[1] + intermediate[2] + 3.) dest[n+i] = (gain * ((log(alpha * (input[n]+1.)) - logl) * intermediate[n]) + offset);

4. Finally the values have to be corrected with the variance and mean calculated on the whole image.

Second approach : GeglOperationAreaFilter implemented steps 1..3 of first apporach within the process method.
The same problem for step 4.

Any suggestions on :

How to go with step 4 since the operations process method can only calculate a mean and variance for its ROI?

Additional observation for Retinex and Gaussian Blur if the value of scale/stdev is equal or bigger then the default size of the gegl ROI then way the splitting in smaller chunks becomes a bottleneck. If the extra area needed around the ROI is important in respect to the ROI what kind of operation should be used?

_______________________________________________ Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Hi,

On 18.12.2013 at 10:29 PM Joao S. O. Bueno wrote:

It looks like this still remains to be rewritten for GEGL?

Looking at the [GEGL porting matrix] you are right.

(what lead me to do this? I've hit the "retinex" filter description while translating the
GIMP manual, and went happily to gimp master to check how retinex would behave in a 32 bit per channel image - just to find it was not there)

I just tried with a quite current master build on Linux and found it at the end of the Colors menu. You can find the code in GIMP 2.8 and master sources - it's /plug-ins/common/contrast-retinex.c.

I looked in the help and found the [webpage of the plug-ins author]. It seems the algorithm dates back to 1996, which is quite old and in the meantime there happened [further research] about the topic.

IMHO to go with GIMPs product vision to provide cutting-edge and fast algorithms it should considered to first check whether now exist improvements to the 1996 Retinex algorithm (resp. Rahman Tone-mapping operator). Perhaps there's also something usable in the former years' GSOC GEGL branches. The best would surely be if the potential contributor came to IRC and spoke with the devs.

Kind regards,

Sven

[GEGL porting matrix]: http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL

[webpage of the plug-ins author]: http://www-prima.inrialpes.fr/pelisson/MSRCR.php

[further research]: http://scholar.google.com/scholar?q=multiscale+retinex&hl=de&as_sdt=1%2C5&as_ylo=1996&as_yhi=2013