You of course need to start with a B&W image. Create a new layer, and fill it with a plain color (for instance, blue). On this color layer, add a layer mask, and copy and paste the background layer in the mask. Set the layer mode to “overlay” and you are done : you have the “light” layer.

Do the same but invert the layer mask to obtain the “dark” layer, with a different color in the layer itself.

Which means, yes, linear RGB. (with HDR support + wider gamut than the current display standard sRGB)

..
..

@Sarge:
I have done some development on GIMP. I don’t regularly contribute code, though. I *am* both experienced and curious about graphics technology, and I took the time to find these things out because I could see that it would solve many of my headaches. Principally, I really wanted correct antialiasing (which is very difficult to achieve if not working in linear RGB, and simple to achieve if you are.) I also have a lot of experience with other people saying the colors on a picture are different than I drew it with

It would be nice to index them in a database, so they don’t get forgotten, and so they can be referenced. Is that maybe achievable with some kind of a tagging (and “permalink”?) mechanism?

Just dreaming,
..jim (don’t know what I’m really talking about)

Are you a developer for GIMP? Your knowledge is not exactly that of the average end user.

OTOH, I may have misunderstood the plan behind GEGL. It is possible that rather than calculating in other precisions, we would instead ensure that data is passed around in standard scRGB as much as possible, so conversion is minimized. If you really must know what the plan is, ask Oyvind Kolas what he thinks.

Also, the conversion is 8-80-8 .. Because AFAIK the calculation is done in double-precision floating point.:)

“I suppose that GEGL on the other hand would not need the CIE D65 profile to down size correctly because GEGL would take into account gamma. Is that correct?”
It’s what you’d expect, but no — the ICC profile defines the colorspace exactly, whereas GEGL defines it in simple fomulaic terms. You should assume that you can get good results with GEGL, but only assume you have right results if you have all your color management ducks in a row, so to speak — meaning that you have an accurate working profile, monitor profile, (and if you need it ) printer profile. The more you have correct, the better (truer, more consistent and predictable) your results will be.

Any fool can casually mess around with images, but to get a correct result, you have to put some thought and effort in. Things can’t ‘just work’ yet in the world of computer imagery. When scRGB (look it up in wikipedia if you’re interested) becomes standard, then many of us will be able to forget about having a good working profile, because we will have a sensibly behaving colorspace as the default for computers. In the foreseeable future, I believe we will still need to concern ourselves with monitor and printer calibration + profiles.

I do not want to bother you but now I see a chance to understand things better; so please do not mind my asking

I have used an example of Eric Brasseur by down sizing an image of his. That goes indeed terribly wrong in GIMP unless I use a linear workspace with a CIE D65 colour profile. I suppose that GEGL on the other hand would not need the CIE D65 profile to down size correctly because GEGL would take into account gamma. Is that correct?

Even with GEGL implemented in GIMP things can still go wrong in a non-linear workflow, because certain filters for example do assume linear data and apparently work outside of the scope of GEGL? Is that the way I have to see it? And in order to prevent this hit and miss work a linear work space, preferably L*a*b, is the way to go?

I thank you in advance, Serge

Should we expect this in 2.6.0 or, rather, in the next major release after 2.6.0?

No. Basically, if you don’t have a linear workflow, you’re just asking for trouble. There are HORDES of accidental mistakes you can commit, because almost all image processing software (including most of GIMP) wrongly assumes that data is linear, Additionally, a non linear workflow is just plain confusing — linear workflow eliminates a lot of bizarre guesswork needed to calibrate your color, curves, etc.. choices.

For example, you mention:
Colors->Map->Sample Colorize
however, this distorts the brightness of the colors.. some end up darker, some brighter, than they originally were, unless you are using a linear workflow*. The method Rolf shows also distorts brightness.

* note — most grey->color mapping filters do distort brightness, even on linear data. That’s because they use a fast approximation of brightness (weighted RGB average), rather than accurate calculation (L*a*b* conversion, discarding the a* and b* components). So, using linear will vastly improve things, but to do it right, it’s better to work in L*a*b* colorspace.. or use a filter that does. ‘Sample colorize’ could do things right, but currently doesn’t. it misestimates the brightness of the sample colors, and ‘preserves’ a usually incorrect luminance if the relevant option is enabled. linear workflow only reduces the grossness of these errors.

Getting a professional quality result requires a linear workflow, indisputably.

http://www.4p8.com/eric.brasseur/gamma.html
details some of the reasons that doing otherwise will tend to end in you banging your head against the wall.

@Alexandre:
Yes, currently the GEGL code path does roughly the following:
*Convert the 8bit, assumed gamma 2.2 integer data to floating point
*apply the operation
*convert back the floating point data to 8bit gamma 2.2 data.

Whereas the old code path simply runs the 8bit pixel data through a precalculated lookup table. There are no seriously optimized versions of the relevant code paths for GEGL yet. simply writing a version of the operation that accepts 8bit, assumed gamma 2.2 data would be able to achieve results of similar quality, only a little slower than the old code.
For various practical reasons, that will happen later, after the relevant operations are proven sound and the architecture to support it is in GEGL.

On the other hand GEGL based processing is slower in order of magnitudes, up to being useless for real work right now

@David gowers.
So if I understand this correctly, GEGL makes the linear workflow superfluous. Or are there still issues which require the linear workflow?

I’m one minute in, and there’s already a GEGL checkbox in 2.6?

AWE-FREAKING-SOME!

Are you aware that the process you do, with creating a layer, filling it with a color, setting it to Overlay mode, and merging down, can be done much easier?
Just pick the color, and use Bucketfill on the layer with ‘fill whole selection’, and ‘Overlay’ mode. I realize this is less visual than what you do. I hope you mention things like this, to remind people you can do things faster than the ways you portray.

It is a crop from the one in the video, the original shot is in full size and the xcf in reduced size (file size concerns, not unwilling to share) in the file to download.

I love the image that you have used along with this blog entry! Perhaps it derives from the video clip, which I have not watched yet. It is gorgeous…