On 26/01/2019 20:03, Normand Fortier wrote:
So far, my understanding is this.
DT works in LAB color space. Most modules work in that space ("The
local color pickers run in the color space of the individual module,
which is usually L"; see also
http://www.darktable.org/usermanual/en/color_management.html). The
main histogram and the global color picker, at least, display rgb
values. One would think that those values are converted from LAB
values, but instead, those modules obtain RGB values after converting
to the monitor color space.
If I am correct, it means DT modules do not all work on the same
image: most work in LAB color space but some work on the image after
conversion to the (RGB) monitor color space. See for example the two
files appended: hist_mon.png shows the main histogram and the tone
curve with my monitor profile selected for display, while
hist_srgb.png shows the same information with srgb profile selected
for display: the histogram in the tone curve looks identical, while
the main histogram visibly differs. Note that the tone curve histogram
is set to display rgb.
To me, this inconsistent behaviour is undesirable: I would expect all
modules to work on the same underlying image.
The latter is how at least some other programs work.
- Lightroom:
"Lightroom uses a wide gamut RGB space similar to ProPhoto RGB to do
all the image calculations, and the histogram and RGB percentage
readouts are based on this native Lightroom RGB space."
http://www.adobepress.com/articles/article.asp?p=1930486
- RawTherapee:
Uses ProPhoto as default working profile
(https://rawpedia.rawtherapee.com/Color_Management#Working_Profile).
The UI indicates "If enabled, the working profile is used for
rendering the main histogram and the Navigator panel, otherwise the
gamma-corrected output profile is used". If I open my original png
image with patches, the display of pixel rgb values (in the Navigator
module) correspond to values written into the patch.
My impression is that it would be possible for modules displaying rgb
values numerically or graphically to obtain such values through a
conversion of the LAB values at the appropriate step of the pipeline
-- this is what the global color picker does when it offers to display
LAB and RGB values of a given area.
Can anyone provide feedback as to whether the above is correct?
If so, I could write a bug report, although I am not sure of the title
or what should be requested. Note that there was a discussion around a
request for rgb curves, that could be relevant:
https://redmine.darktable.org/issues/9559
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org
I'm new to darktable, and am finding this mailing list invaluable.
I have same concerns as described in this thread. My use case is that I
want to match the LAB luminosity of a colorchecker patch in an
unprocessed raw file in DT with the reference luminosity value for the
patch so I can produce an adequately accurate 'standard' colour profile
for my camera. I'm shooting with studio flood (5k which is the cc
reference) so can adjust exposure quite finely by moving lamp distance.
I was intending to use global colour picker, but now I'm at a loss, as
in my view, the camera profile should depend only on the raw file and
the cc references, not the output profile of my laptop monitor.
Also I want to use dt to set white balance for a shoot during raw
processing taken from an image that includes colorchecker. But now I'm
concerned that this too will be based on my monitor not the underlying
file values so may affect colour in the resulting tiffs/prints
Really interested to hear dt dev feedback.
____________________________________________________________________________
darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
