GNOME.org
 

Re: [Gimp-user] color management -- basic question

On 01/09/2017 04:41 PM, Casey Connor wrote:


The only reason I was playing with the output profile and monitor
profiles was mainly to test my understanding of it, not because I was
developing a particular workflow.



The "colorful image" I was using was one of the test images here:
http://joco.name/2014/03/02/all-rgb-colors-in-one-image/
I used one of the 4096x4096 8-bit-per-channel images, which I scaled to
1024x1024 -- I just wanted an image to play with that I could be sure
would show me a shift when/if it happened -- in other words, it's just a
test image and I just assigned a randomly-chosen larger-than-sRGB gamut
to it so I could see how the rendering intents looked --  so it has no
associated color space, afaik, it's just "all the values" (or was, until
I scaled it down.)
Thanks! for the link - those are some seriously cool and beautiful images. The only "all colors" images I knew of is Bruce Lindbloom's image here, and it's strictly utilitarian: http://brucelindbloom.com/index.html?RGB16Million.html (as an aside, there is much useful color management information on Bruce Lindbloom's website).
It seems to me that the kind of experimenting you are doing is the best way to acquire a hands-on understanding of color management. 



I now understand that with the generic sRGB profile I was using I
shouldn't expect the rendering intents to look any different from each
other.

Longer-term, I was interested to work in wider color spaces for the sake
of photography. I'd just be exporting to Wide Gamut (or whatever larger
space) and opening that up in gimp. The hope was to possibly retain some
more detail, soft-proof to check what's out-of-gamut, experiment, and
otherwise possibly get better results with certain transformations in
Gimp.
I recommend using Rec2020 or ACEScg as your "go to" wide gamut color space (but not when using default GIMP, for reasons already mentioned) - ACEScg is used by people making images for cinema, Rec2020 is the up-and-coming standard for monitors, and both of these spaces are good all-around editing color spaces.
If you edit in wide gamut color spaces, it's important to keep in mind the color gamut of your monitor profile, as your monitor simply can't show you colors that are out of gamut with respect to your monitor profile (and unless your monitor profile is accurate, the colors you see aren't a reliable guide to editing).
When I work with interpolated raw files, I use Rec2020 for initial editing (specifically a linear gamma version of Rec2020, "Rec2020-elle-V4-g10.icc"). But I also try very hard to make sure that the colors I produce while editing will fit into the sRGB color gamut for display on the web.
When affordable Rec.2020 monitors finally reach the consumer desktop (and if browsers ever are properly color-managed), editing and soft proofing will both be a lot easier. 


From what you said it sounds like the CCE is the version to use if
I'm going to go through with that plan, since it amends certain tools to
not assume sRGB under the hood, but maybe the default version of gimp
would still be useful just to get a feel for what's out-of-gamut, and I
could still use g'mic tools if they work in Lab/Lch/etc, right?
Currently g'mic also is hard-coded to use the sRGB Y and XYZ values for calculating things like Luminance and for converting to LAB/LCH/etc. I did a bit of testing, and as far as I can tell there is something not quite right about the g'mic conversions to LAB even for sRGB images. So yes, g'mic has some really nice transforms. And no, those transforms can't be counted on to be accurate. Useful, yes. But not accurate. 


(Also, I hope to profile my monitor soon.)
Profiling your monitor is a good thing to do. If your monitor is relatively new and has a good sRGB preset, then what you see right now is probably a pretty good guide to what your images actually look like. But not all monitors come with good sRGB presets.
If you use ArgyllCMS to profile your monitor, you have the option to make a LUT profile for exploring out of gamut colors. But I would recommend also making a matrix profile and using the matrix profile for normal image editing. If you have questions about making monitor profiles, the ArgyllCMS mailing list is a good place to start. 




There are many versions of the sRGB ICC profile
(http://ninedegreesbelow.com/photography/srgb-profile-comparison.html). Most
of these versions are matrix profiles. Where did you get the sRGB
profile that you are using as the monitor profile, and what's its
exact file name?


From color.org, I think, judging by metadata? Not actually sure where it
came from -- sRGB_IEC61966-2-1_black_scaled.icc
Yes, that is one of the older color.org sRGB profiles. You might want to put that profile somewhere where you'll never accidentally use it. 



But yeah, nothing carefully-chosen, whatever it is -- I did read up a
bit on the variety of sRGB profiles (thanks again to your site) and I
know that I shouldn't trust or use or speak to any of them before
checking ninedegreesbelow.com. :-)


If you need ICC profiles, I provide a suite of well-behaved ICC
profiles here: https://github.com/ellelstone/elles_icc_profiles -
click the "Clone or download" button to download the zip file, just
ignore the code folder (unless you feel like compiling your own set of
profiles), and look in the "profiles" folder to find the already made
ICC profiles. This profile: "sRGB-elle-V4-srgbtrc.icc" is exactly
equivalent to the GIMP built-in sRGB profile.


I'm sorta curious why GIMP's built-in sRGB profile rarely appears in
menu lists of available profiles -- e.g. the monitor profile choice, or
the soft-proofing profile choices? I only see it when converting an
image to a new color profile, and that makes me wonder if I'm still
misunderstanding something fundamental about profile types.
Unfortunately currently LCMS soft proofing algorithms have very many "gotchas" and limitations: https://bugzilla.gnome.org/show_bug.cgi?id=772266
So currently trying to soft proof to the built-in GIMP sRGB profile is a waste of time as LCMS soft proofing will report that all the colors are in gamut.
The PhotoFlow GIMP plug-in can be used to soft proof images, but I'm not sure if the soft proofing code has been ported to the stable branch of PhotoFlow. PhotoFlow soft proofing explicitly contains code that works around the LCMS soft proofing limitations. 


I absolutely agree with you that LCH is amazing, and now that it's
available, I can't imagine ever trying to edit without LCH. Default
GIMP and CCE both provide the LCH blend modes. In addition CCE
provides LCH color pickers and an LCH Hue-Chroma tool. So if even if
you only ever edit sRGB images, you might find CCE worth using until
these capabilities are added to default GIMP 2.9.


Yeah, those overlay modes are great (and thanks once again to your
website for cluing me in to them).
I think you might mean "layer blend modes"? - "overlay" is the name of a particular blend mode, but it's not one of the LCH blend modes. 


Are your LCH tools in the roadmap for
2.9 or 2.10?


https://bugzilla.gnome.org/show_bug.cgi?id=749902
https://bugzilla.gnome.org/show_bug.cgi?id=753163
Keep in mind that someone has to do the coding and there are many, many, many parts of GIMP that need attention before 2.10 is released. 


That'd be super. I was about to file a FR for Lch mode in
the native gimp levels dialog... is that already planned?
Well, what you can do is duplicate the layer, use GIMP's "Colors/Levels" or "Colors/Curves" or "Colors/Exposure" and set the layer blend mode to "Lightness", which will leave the Hue and Chroma of the original layer unaltered. 


(I've been
using g'mic's colors->curves in Lch mode and it works great to boost
shadows without altering colors.)
Again, if you like what you see when you use g'mic, that's wonderful. But please don't assume that what you see is "correct by the numbers". You'd have to do some testing to confirm, and again g'mic is hard-coded to use sRGB Y and XYZ values and the sRGB TRC. 

Best,
Elle
--
http://ninedegreesbelow.com
Color management and free/libre photography
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]