Episode 039: Different Tones and a View into the NEAR Future
Podcast Video (27.1 MB) [22:00m]: Download (8892)
Torrent: Play in Popup | Download (78) The images used: Play in Popup | Download (66)
I have some very nice news about the upcoming version 2.6 of GIMP. Exclusively for Meet the GIMP! before it will hit the mailing lists tomorrow.
The rest of the show covers toning monochrome images and includes a new feature - the Blunder Alert Overlayâ„¢. The image here is a tritone of blue in the shadows, red in the midtones and orange in the highlights.
The slideshow for the monochrome challenge and the fully randomized drawing of the winner will be on next week. I hadn’t looked on my calendar when I set the 31th of March as the final date. Next challenge will end on Tuesday, then I have a week to make the stuff ready.
I have some links for you:
- rore’s split tone example from flickr
- The GIMP users group discussion there
- Duotone in Wikipedia
- Gimpforum.de has the screenshot, not gimpusers. Sorry for the mix up.
Contact me!
You can leave your comments on this blog or write me a mail.
This work is licensed under a
Creative Commons Attribution-Share Alike 2.0 Germany License.
April 1st, 2008 at 9:35 pm
Rolf:
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…
April 1st, 2008 at 9:57 pm
Thank you!
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.
April 2nd, 2008 at 1:59 am
It seems to me that the blunder alert is more of a blunder than what was happening underneath. if you make midtones of the ‘middle’ layer == black, then that would make it effect everything EXCEPT the midtones. Why would that be correct?
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.
April 2nd, 2008 at 7:57 am
Wow.
I’m one minute in, and there’s already a GEGL checkbox in 2.6?
AWE-FREAKING-SOME!
April 2nd, 2008 at 8:21 am
Yes. Right now that effects a pretty limited set of things.. like threshold, color balance, levels, and a few other color tools at the moment. The only reason a checkbox exists is for the dev’s to be able to compare GEGL results with old results (eg.. the levels tool with GEGL enabled produces more accurate results because it’s gamma-correct and calculated with floating point precision)
April 2nd, 2008 at 11:18 am
@Rolf.
Even on this dangerous day April 1st, you did a show. You presented a nice way of toning. As in the case of monochrome conversion the full control way (episode 34), the layers and masks give lots of control where and how to colorize.
Another way was pointed out to me by Tim Jacobs at 23hq : menu Colors->Map->Sample Colorize and a gradient. This does not give the full control of layers and masks but on the other hand it does give better control over the colours to use. See also :
http://www.gimpguru.org/Tutorials/SampleToning/
@David gowers.
So if I understand this correctly, GEGL makes the linear workflow superfluous. Or are there still issues which require the linear workflow?
April 2nd, 2008 at 11:35 am
@David Gowers
On the other hand GEGL based processing is slower in order of magnitudes, up to being useless for real work right now
April 2nd, 2008 at 2:13 pm
“@David gowers.
So if I understand this correctly, GEGL makes the linear workflow superfluous”
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.
April 2nd, 2008 at 2:37 pm
@David Gowers
Should we expect this in 2.6.0 or, rather, in the next major release after 2.6.0?
April 2nd, 2008 at 2:43 pm
After 2.6.
Exactly when remains to be seen. It’s not specifically planned. A near novice could do it once the two conditions above have been satisfied, it’s more or less simple grunt work. Only finetuning the code would require any great technical knowledge, so this will be a great opportunity to get into GIMP development when the time comes.
April 2nd, 2008 at 3:12 pm
David, and what about using old 8-bit conversion for preview and engaging 8-16-8 bits pipeline when user presses OK? Of course, if user agrees with such a workaround in settings?
April 2nd, 2008 at 3:43 pm
@David gowers
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
April 2nd, 2008 at 4:22 pm
@ Serge
You should assume that all plugins are dumb. Color management is still a fairly new part of GIMP — for example, previews are not colormanaged, the color selector is not colormanaged, plugins are not smart.. they really aren’t at all. The only ones uneffected are the ones that don’t actually blend pixels (like Tile).
“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.
April 2nd, 2008 at 4:30 pm
@Alexandre:
Never. I believe if you asked Sven Neumann, he’d say ‘That’s a horrible hack, and we would be stupid to do it.’. Time spent doing that would be better spent implementing the facility for calculation in different levels of precision, and then porting the code to actually do the calculation across into such a version.
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.:)
April 2nd, 2008 at 4:52 pm
Thank you very much, David. I appreciate your explanation very much. Colour management and colour spaces start to make sense to me now.
Are you a developer for GIMP? Your knowledge is not exactly that of the average end user.
April 2nd, 2008 at 5:05 pm
David, I could predict such an answer from Sven, so I asked you :). Thank you for the explanation. But the idea is obvious - to make preview alive, it can be made in less accurate but quicker way. Not using GEGL at that point could be a workaround for 2.6, not more, not less.
Is GEGL internal RGB linear (not sRGB), while being floating point?
April 2nd, 2008 at 11:37 pm
Many of these comments are extemely interesting!
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)
April 3rd, 2008 at 1:35 am
@Alexandre:
All operations so far work in an extended precision form of scRGB (unless they work in something else entirely, like L*a*b* or yuv colorspace or just y (greyscale). L*a*b* and y* are linear too, not sure about yuv.)
http://en.wikipedia.org/wiki/ScRGB_color_space
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
April 6th, 2008 at 5:49 am
[...] Episode 039: Different Tones and a View into the NEAR Future [...]
April 6th, 2008 at 3:45 pm
[...] In der neuesten Folge von Meet the Gimp geht es um unterschiedliche Farbtöne - und so entstand dieses Bild: [...]
April 12th, 2008 at 10:50 am
[...] Shooting abgegangen war, habe ich in der Bildbearbeitung mehr als üblich getan. Inspiriert von Meet the GIMP! habe ich das getonte Bild oben erstellt. Und irgendwo habe ich die Tage ein Triptychon gesehen. Am [...]
September 20th, 2008 at 6:30 am
I found a variant of the method illustraded in this tutorial that enables to change at will the colors of the tones without having to merge a copy of the background layer with a color each time.
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.