c2g improvements
This discussion is connected to the gimp-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.
| c2g improvements | Jacek Poplawski | 01 Jun 15:55 |
| c2g improvements | Partha Bagchi | 01 Jun 21:46 |
| c2g improvements | Alexandre Génin | 03 Jun 17:47 |
| c2g improvements | Alexandre Prokoudine | 03 Jun 18:33 |
| c2g improvements | Alexandre Génin | 03 Jun 20:16 |
| c2g improvements | Jon Nordby | 03 Jun 20:40 |
| c2g improvements | Jacek Poplawski | 03 Jun 20:46 |
| c2g improvements | Øyvind Kolås | 03 Jun 20:58 |
| c2g improvements | Jacek Poplawski | 03 Jun 21:11 |
| c2g improvements | Jon Nordby | 03 Jun 22:10 |
| c2g improvements | Partha Bagchi | 03 Jun 22:15 |
c2g improvements
hello,
I like the effect of c2g operation available in GIMP for a long time, lots
of people use it for kind of "HDR" effect but I think it's nice way to
increase local contrast of some specific areas of photo or add nice looking
noise
However, the main problem of current implementation of c2g is its
inefficiency, it takes a lot of time to process standard size photo.
I am author of delaboratory and I started implementing c2g-like operation in my project, after few days I was able to achieve something similar to GIMP/GeGL c2g but much faster.
I would like to implement something like that to GIMP. I don't want to modify existing c2g code, because I assume current implementation is well designed (mathematicaly) and should stay. So it would be nice to create something like "simple c2g" or "c2g lite" or just "local contrast boost" operation.
My question is - are you interested at all in this kind of code? Will it be accepted in GIMP? Because my main concern is that I don't want to implement something which will never be used. I am not aware of current state of project (I mean project management, not code) and I don't know what's the process of submitting code to GIMP/GeGL right now.
c2g improvements
On Fri, Jun 1, 2012 at 11:55 AM, Jacek Poplawski wrote:
hello,
I like the effect of c2g operation available in GIMP for a long time, lots of people use it for kind of "HDR" effect but I think it's nice way to increase local contrast of some specific areas of photo or add nice looking noise
It is unfortunate that people use c2g for "HDR" effect. I think (use it as such) it is precisely meant for local contrast enhancement and if you want great b&w architectural "blueprint".
c2g improvements
Hi
Please please take time to implement this ! I'll be glad to lend a hand for testing/tutorials/etc. (I don't have coding skills).
I use c2g on almost every photo : my workflow often only consists in adjusting global contrast (levels/curves), and then using c2g for adjusting local contrast, usually with different radiuses. It a fantastic tool, much better imho than all the wavelet-* filters that always produce a 'dreamy' effect.
The only drawback is that it takes ages to process the photo, so I always end up making some compromise between noise level and processing time... so a speedup would be *very* useful !
Alex
Le Friday, June 01, 2012 05:55:43 PM Jacek Poplawski a crit :
hello,
I like the effect of c2g operation available in GIMP for a long time, lots of people use it for kind of "HDR" effect but I think it's nice way to increase local contrast of some specific areas of photo or add nice looking noise
However, the main problem of current implementation of c2g is its inefficiency, it takes a lot of time to process standard size photo.I am author of delaboratory and I started implementing c2g-like operation in my project, after few days I was able to achieve something similar to GIMP/GeGL c2g but much faster.
I would like to implement something like that to GIMP. I don't want to modify existing c2g code, because I assume current implementation is well designed (mathematicaly) and should stay. So it would be nice to create something like "simple c2g" or "c2g lite" or just "local contrast boost" operation.
My question is - are you interested at all in this kind of code? Will it be accepted in GIMP? Because my main concern is that I don't want to implement something which will never be used. I am not aware of current state of project (I mean project management, not code) and I don't know what's the process of submitting code to GIMP/GeGL right now.
gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
c2g improvements
On Sun, Jun 3, 2012 at 9:47 PM, Alexandre Gnin wrote:
I use c2g on almost every photo : my workflow often only consists in adjusting global contrast (levels/curves), and then using c2g for adjusting local contrast, usually with different radiuses. It a fantastic tool, much better imho than all the wavelet-* filters that always produce a 'dreamy' effect.
Out of curiousity, what is the relation of Marco's wavelet filters to local contrast? :)
The only drawback is that it takes ages to process the photo
Could it be that GIMP simply hasn't entered optimization phase with regards to GEGL yet? :)
Alexandre Prokoudine http://libregraphicsworld.org
gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
c2g improvements
Out of curiousity, what is the relation of Marco's wavelet filters to local contrast? :)
Well I'm not an expert but my understanding of wavelet decompose is that it decomposes the image into different details scales. So if you duplicate the Wavelet scale xx layers after using wavelet-decompose, it will make the bright details at that scale brighter and the dark details and that scale darker, ie increasing local contrast.
I don't know the relationship between the two, but I it looks very similar to increasing local contrast with unsharp mask, but with direct control over different radius.
Maybe that's not what the filter is designed for, but in some cases I find it to do a pretty good job.
I made a quick&dirty xcf, that probably explains better than I do : https://dl.dropbox.com/u/35934134/ex.xcf.tar.gz
Could it be that GIMP simply hasn't entered optimization phase with regards to GEGL yet? :)
Well then I'm looking forward, keep up the awesomeness :)
Alex
Le Sunday, June 03, 2012 10:33:50 PM Alexandre Prokoudine a crit :
On Sun, Jun 3, 2012 at 9:47 PM, Alexandre Gnin wrote:
I use c2g on almost every photo : my workflow often only consists in adjusting global contrast (levels/curves), and then using c2g for adjusting local contrast, usually with different radiuses. It a fantastic tool, much better imho than all the wavelet-* filters that always produce a 'dreamy' effect.
Out of curiousity, what is the relation of Marco's wavelet filters to local contrast? :)
The only drawback is that it takes ages to process the photo
Could it be that GIMP simply hasn't entered optimization phase with regards to GEGL yet? :)
Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list
gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
c2g improvements
On 1 June 2012 17:55, Jacek Poplawski wrote:
hello,
I like the effect of c2g operation available in GIMP for a long time, lots of people use it for kind of "HDR" effect but I think it's nice way to increase local contrast of some specific areas of photo or add nice looking noise
However, the main problem of current implementation of c2g is its inefficiency, it takes a lot of time to process standard size photo.I am author of delaboratory and I started implementing c2g-like operation in my project, after few days I was able to achieve something similar to GIMP/GeGL c2g but much faster.
Hi Jacek,
c2g is a GEGL operation. You will find it in operations/common/c2g.c
in the GEGL tree.
I would recommend first finding out what causes the current slowness you experience: Is it the GEGL integration in GIMP? (compare c2g usage in GIMP with using GEGL directly). Is it due to some overhead in GEGL core? Or maybe there is room for optimization in the operation itself?
I would like to implement something like that to GIMP. I don't want to modify existing c2g code, because I assume current implementation is well designed (mathematicaly) and should stay. So it would be nice to create something like "simple c2g" or "c2g lite" or just "local contrast boost" operation.
My question is - are you interested at all in this kind of code? Will it be accepted in GIMP? Because my main concern is that I don't want to implement something which will never be used. I am not aware of current state of project (I mean project management, not code) and I don't know what's the process of submitting code to GIMP/GeGL right now.
If you are going to do a new operation, the right way to do it is in GEGL. GIMP and others can then use it.
c2g improvements
On Sun, Jun 3, 2012 at 10:40 PM, Jon Nordby wrote:
c2g is a GEGL operation. You will find it in operations/common/c2g.c in the GEGL tree.
I know this code pretty well because I was analizing it for days and implementing my own version for delaboratory :)
I would recommend first finding out what causes the current slowness you experience: Is it the GEGL integration in GIMP? (compare c2g usage in GIMP with using GEGL directly). Is it due to some overhead in GEGL core? Or maybe there is room for optimization in the operation itself?
there are few things... reading from 3 different arrays is 3 times slower than reading from 1 array, at least under Linux... but the overall algorithm does too much things that's why I proposed to create "c2g lite" which will not be so mathematically correct but give similar effect... for instance is relative brightness really so important in envelopes.h? also the luts are generated everytime from start, while I found out that generating one big array and use subset of data give similar results
c2g improvements
On Sun, Jun 3, 2012 at 10:46 PM, Jacek Poplawski wrote:
there are few things... reading from 3 different arrays is 3 times slower than reading from 1 array, at least under Linux... but the overall algorithm does too much things that's why I proposed to create "c2g lite" which will not be so mathematically correct but give similar effect... for instance is relative brightness really so important in envelopes.h? also the luts are generated everytime from start, while I found out that generating one big array and use subset of data give similar results
Caching the LUTs sounds like an optimization that should go in directly, though I doubt that is what is taking most of the time. Beware that stress/c2g should also work on HDR images and not only on images with data in the 0.0-1.0 range.. For some of the rationale behing stress/c2g see http://pippin.gimp.org/papers/Kolaas_11_jist.pdf which is a publication based on the approach explored by these GEGL ops.
/Ø
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://pippin.gimp.org/ http://ffii.org/
c2g improvements
On Sun, Jun 3, 2012 at 10:58 PM, Øyvind Kolås wrote:
Caching the LUTs sounds like an optimization that should go in directly, though I doubt that is what is taking most of the time.
Well my primary concern is - are gimp developers at all interested in any work on improving c2g. I like Gimp and I use it very often but I am not sure about project management here and experiences from reading this list in previous years weren't very good.
c2g improvements
On 3 June 2012 23:11, Jacek Poplawski wrote:
On Sun, Jun 3, 2012 at 10:58 PM, Øyvind Kolås wrote:
Caching the LUTs sounds like an optimization that should go in directly, though I doubt that is what is taking most of the time.
Well my primary concern is - are gimp developers at all interested in any work on improving c2g.
The maintainer (of GEGL) has here expressed an interest in getting this optimization in - that is a pretty strong yes.
c2g improvements
On Sun, Jun 3, 2012 at 6:10 PM, Jon Nordby wrote:
On 3 June 2012 23:11, Jacek Poplawski wrote:
On Sun, Jun 3, 2012 at 10:58 PM, yvind Kols wrote:
Caching the LUTs sounds like an optimization that should go in directly, though I doubt that is what is taking most of the time.
Well my primary concern is - are gimp developers at all interested in any work on improving c2g.
The maintainer (of GEGL) has here expressed an interest in getting this optimization in - that is a pretty strong yes.
-- Jon Nordby - www.jonnor.com
There is another thread here (somewhere) where I had posted numbers for c2g operations in gegl using a D800 sample jpeg. The optimization suggested by yvind lead to a substantial improvement in speed at least on Windows.
gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
