On Sat, Jun 30, 2012 at 9:30 PM, Calculemus wrote:
> I am interested in contributing image processing algorithms to GIMP.
> I need advice where do I find resources. I need book recommendations,
> where to find papers, or any other resource to study from.
Personally I'm a bit puzzled. What specifically do you mean with
"contributing image processing algorithms to GIMP"?
Writing arbitrary C code for image processing is probably not a good
idea. But if you are interested in contributing to the project, there
are several areas we'd be grateful for help in. Most image processing
will now be happening in GEGL (www.gegl.org) which is used by GIMP.
There always are filters to be ported to GEGL operations, new GEGL
operations to write, existing operations to be ported to use OpenCL
for hardware acceleration etc.
On Sat, Jun 30, 2012 at 10:22 PM, Calculemus <[hidden email]> wrote:
> Since I have had an image processing and computer vision course and
> interested later in Masters in the area, I am mostly interested in
> implementing image processing algorithms, in this case as you say "new GEGL
> operations". Where can I find ideas/suggestions what needs to be done?
> Thanks for the quick responce ;)
gimp-developer-list mailing list
[hidden email] https://mail.gnome.org/mailman/listinfo/gimp-developer-list
You sent it off-list again :) "Reply to All" would help :)
The text means that you read source code (and code comments) of an
existing GIMP filter, then rewrite it into a GEGL operation. AFAIK,
some filters do mention papers they are based on, and some don't, but
many of the latter are generic enough. E.g. some rely on other common
algorithms such as convolution matrix.
Some of the filters have quite customized UI, e.g. the Flames plug-in.
In that case it's OK to just port the back-end so that proper UI could
be written later when we figure out how to do that. Right now all
ported ops in the Git master branch use the skeleton of the "GEGL op"
I suggest you have a look at the code of some simple existing GIMP
filter that has already been ported to a GEGL operation. E.g. "Whirl
> Wow the filters list is big. It is exactly the thing I want to work on.
> I am just confused about "Read the plugin you want to port, understand the
> algorithm hidden in it. ".
> So this is already done in GEGL and basically you want to use it in GIMP? Or
> they are not implemented anywhere and I am supposed to know the algorithm
> and do it from scratch?
> I have done a whole book on image processing algorithms, I can tackle this
> one and probably do more than the two GSOC students together :D
I need to implement compositors for a project I work on, such as soft-light, hard-light, overlay, etc. like the ones in Photoshop. I see gegl has all those. But they use different math than the one I see in the original Adobe reference that is used for Photoshop and
After Effects. To make things worse, on the web you can find even other approaches for the same operation, like soft-light for example. Someone can shed some light on this?
Am 08.07.2012 10:20, schrieb Calculemus:
> I need to implement compositors for a project I work on, such as
> soft-light, hard-light, overlay, etc. like the ones in Photoshop. I see
> gegl has all those. But they use different math than the one I see
> in the original Adobe reference that is used for Photoshop and
> After Effects. To make things worse, on the web you can find even
> other approaches for the same operation, like soft-light for example.
> Someone can shed some light on this?
for a quite comprehensive comparison of many, many blend modes -- including several softlight formulas -- you might want to check out my article .
The big table  at the beginning of the article features the comparison list.
In the link section there is also a site with ready-to-use C code, IIRC.
hi again and sorry for the ultra-late answer. I'm putting this back on the list so it can be found in the archives.
Am 08.07.2012 17:14, schrieb Calculemus:
> I am still confused though, how do I make a decision on which
> formula to use for soft-light for example? Can I pick the "best" one,
> or there is no best one and it does not matter which one I pick?
In short: it doesn't matter much, the various softlight modes produce quite similar results.
In bullet points:
- It is a good idea to adhere to the industry standard photoshop 
- It is a good idea to adhere to the open industry standard SVG 
- GIMP does neither, it uses the 'pegtop' formula [4,9] -- and does so whithout problems
- The best formula is the illusions.hu one  -- in theory, for some sense of 'best'
In full glory: the subtle differences in the softlight modes can be explained by looking at the
ideas behind the formulas. In my regard this is an exercise of mere academic interest since
the artistic needs for a softlight blend mode are satisfied by any of the formulas. I'm happy to
be proved wrong here, though.
Regarding notation, i'll follow the conventions given in : the variables a and b represent the values
of the base layer and the blend layer, in that order. The values are in the range [0..1].
The original motivation behind the photoshop formula  is presumably to allow for local gamma correction:
where the blendlayer value b is a mid gray of b=0.5, the result is identical to the base layer's value a.
Lower values of b result in darking the image, up to b=0 which corresponds to a gamma correction with gamma=0.5.
Brighter values of b give brighter results, up to b=1 which corresponds to gamma correction with gamma=2.
The photoshop formula has a downside:
The way the formula switches between the brightening and the darkening case results in a certain kind
of discontinuity in the graphs which has been illustrated in the pegtop article .
The corresponding 'gradient angle' diagram in  also displays a discontinuity around b=0.5.
In theory, this discontinuity results in suboptimal properties regarding the
transfer of blend layer midtone texture to base layer highlights and shadows.
The pegtop formula  successfully avoids this discontinuity and improves
local contrast transfer properties (in theory). However, it breaks the symmetry between darkening
and brightening curves: b=1 does not result in gamma correction anymore, while b=0 still
corresponds to gamma=0.5. This can best be seen by comparing the 'curves' diagrams in .
The ilhu formula  resolves the discontinuity in the photoshop formula in a more elegant way,
keeping the symmetric gamma correction properties. Another difference from the photoshop formula
is that ilhu provides a gamma curve for any value of b, not just for the extrema b=0 and b=1
as the photoshop formula does (not counting the neutral case for b=0.5)
Now interestingly, the SVG formula  (which has not been examined in the blog article)
follows the photoshop math but introduces a special case when brightening the shadows of the base layer:
for b>0.5 (blending effect is brightening) and a<0.25 (shadows of the base layer),
a different formula is used which provides less intense brightening than the photoshop formula.
I'm short on references for the motivation of this modification. On a general
note, i think that blend mode formulas are not a good place to compensate for
any weaknesses of a given color representation.