RSS/Atom feed Twitter
Site is read-only, email is disabled

Gegl Operation : Retinex

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

3 of 3 messages available
Toggle history

Please log in to manage your subscriptions.

Gegl Operation : Retinex Geert Jordaens 29 Jul 16:08
  Gegl Operation : Retinex Joao S. O. Bueno 18 Dec 18:44
   Gegl Operation : Retinex scl 18 Dec 22:03
Geert Jordaens
2010-07-29 16:08:37 UTC (over 14 years ago)

Gegl Operation : Retinex

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?

Joao S. O. Bueno
2013-12-18 18:44:01 UTC (almost 11 years ago)

Gegl Operation : Retinex

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

scl
2013-12-18 22:03:00 UTC (almost 11 years ago)

Gegl Operation : Retinex

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