Re: [darktable-user] Inaccurate color display or color picker?

[Edgardo Hoszowski]

> I may not be understanding all the issues correctly, but this seems much
> less useful than basing the values on an output profile that you actually
> intend to use for exporting to. Would it make sense to have the
> picker/histogram always use the profile that the soft proofing toggle is
> set to (whether soft proofing is enabled or not)? Or would changing to this
> behavior be to dispruptive to existing workflows?
>
The main issue now is that is not clear the requirement or use-case, or
maybe there are many workflows with different needs. This way is the most
generic so people that want to check using the output color profile can do
it, and people that want it with the soft proofing also have a way to do
it. If this is an overkill and is better to have it only with one of those
profiles there's no problem, that can be done.


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

No problem, Edgardo. Thanks for all your work!

Normand

Le 19-02-07 à 13 h 13, Edgardo Hoszowski a écrit :
You are mixing things and getting off-topic here, we'll never be able to 
define a requirement this way.


The final histogram/color picker/overexpose does collect the data at the 
end of the pipe, that is, when it has finished processing the image. Not 
converting it to another profile makes no sense, as the last module can 
work on any colorspace, and the program will be choosing for you how the 
data is displayed.
What the PR does is to allow you to select the colorspace (or profile) 
on which the data is displayed. If you want you can select the 
colorspace of the last module, that's up to you.


El jue., 7 feb. 2019 a las 14:58, Normand Fortier 
(mailto:normand.fort...@cgocable.ca>>) 
escribió:


Le 19-02-07 à 07 h 36, Edgardo Hoszowski a écrit :
 > PR 2069 is ready, please test it.

Thank you for the quick response! Sorry for the long posts, but I think
we're not quite on the same page. I am still trying to figure how to
incorporate your PR into my DT source, so I can't test yet, but I read
the comments under your PR, here is my take.

The short story: the histogram and global color picker should indicate
the values at the end of the last module in the history stack (or of
whatever module/step is selected in history), without converting
them to
another profile, be it the destination/output profile or the display
profile. I don't see this as being tied to over/underexposure
specifically.

The detail: I admit I am still confused as to which profile is used by
DT modules that work in RGB. My initial understanding of the behaviour
of the global color picker and the main histogram was that, since they
report rgb values as per the display profile, it meant that the working
profile for RGB modules was the display profile. But your comment now
mentions that ProPhoto is actually being used as a working profile. On
the other hand the manual mentions the output color profile being
applied (at the place in the pipeline where DT switches from working in
Lab to working in RGB, I gather). Where does the ProPhoto profile come
into play then? Which modules work in ProPhoto, and which ones work in
the output profile?

If indeed modules working in rgb use ProPhoto as a profile, then
that is
good news, but then I would expect the main histogram and the global
color picker to provide data (histogram itself + rgb values) according
to the ProPhoto values.

As I mentioned earlier, that is what RawTherapee does: it 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".

That is also what Lightroom does: "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

Normand


darktable user mailing list
to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org






darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[jys]

On Thu, Feb 7, 2019, at 09:57, Normand Fortier wrote:

> That is also what Lightroom does: "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

I may not be understanding all the issues correctly, but this seems much less 
useful than basing the values on an output profile that you actually intend to 
use for exporting to. Would it make sense to have the picker/histogram always 
use the profile that the soft proofing toggle is set to (whether soft proofing 
is enabled or not)? Or would changing to this behavior be to dispruptive to 
existing workflows?

-- 
jys

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Edgardo Hoszowski]

You are mixing things and getting off-topic here, we'll never be able to
define a requirement this way.

The final histogram/color picker/overexpose does collect the data at the
end of the pipe, that is, when it has finished processing the image. Not
converting it to another profile makes no sense, as the last module can
work on any colorspace, and the program will be choosing for you how the
data is displayed.
What the PR does is to allow you to select the colorspace (or profile) on
which the data is displayed. If you want you can select the colorspace of
the last module, that's up to you.

El jue., 7 feb. 2019 a las 14:58, Normand Fortier (<
normand.fort...@cgocable.ca>) escribió:

> Le 19-02-07 à 07 h 36, Edgardo Hoszowski a écrit :
> > PR 2069 is ready, please test it.
>
> Thank you for the quick response! Sorry for the long posts, but I think
> we're not quite on the same page. I am still trying to figure how to
> incorporate your PR into my DT source, so I can't test yet, but I read
> the comments under your PR, here is my take.
>
> The short story: the histogram and global color picker should indicate
> the values at the end of the last module in the history stack (or of
> whatever module/step is selected in history), without converting them to
> another profile, be it the destination/output profile or the display
> profile. I don't see this as being tied to over/underexposure specifically.
>
> The detail: I admit I am still confused as to which profile is used by
> DT modules that work in RGB. My initial understanding of the behaviour
> of the global color picker and the main histogram was that, since they
> report rgb values as per the display profile, it meant that the working
> profile for RGB modules was the display profile. But your comment now
> mentions that ProPhoto is actually being used as a working profile. On
> the other hand the manual mentions the output color profile being
> applied (at the place in the pipeline where DT switches from working in
> Lab to working in RGB, I gather). Where does the ProPhoto profile come
> into play then? Which modules work in ProPhoto, and which ones work in
> the output profile?
>
> If indeed modules working in rgb use ProPhoto as a profile, then that is
> good news, but then I would expect the main histogram and the global
> color picker to provide data (histogram itself + rgb values) according
> to the ProPhoto values.
>
> As I mentioned earlier, that is what RawTherapee does: it 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".
>
> That is also what Lightroom does: "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
>
> Normand
>
>
> 
> darktable user mailing list
> to unsubscribe send a mail to
> darktable-user+unsubscr...@lists.darktable.org
>
>


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

Le 19-02-07 à 07 h 36, Edgardo Hoszowski a écrit :

PR 2069 is ready, please test it.


Thank you for the quick response! Sorry for the long posts, but I think 
we're not quite on the same page. I am still trying to figure how to 
incorporate your PR into my DT source, so I can't test yet, but I read 
the comments under your PR, here is my take.


The short story: the histogram and global color picker should indicate 
the values at the end of the last module in the history stack (or of 
whatever module/step is selected in history), without converting them to 
another profile, be it the destination/output profile or the display 
profile. I don't see this as being tied to over/underexposure specifically.


The detail: I admit I am still confused as to which profile is used by 
DT modules that work in RGB. My initial understanding of the behaviour 
of the global color picker and the main histogram was that, since they 
report rgb values as per the display profile, it meant that the working 
profile for RGB modules was the display profile. But your comment now 
mentions that ProPhoto is actually being used as a working profile. On 
the other hand the manual mentions the output color profile being 
applied (at the place in the pipeline where DT switches from working in 
Lab to working in RGB, I gather). Where does the ProPhoto profile come 
into play then? Which modules work in ProPhoto, and which ones work in 
the output profile?


If indeed modules working in rgb use ProPhoto as a profile, then that is 
good news, but then I would expect the main histogram and the global 
color picker to provide data (histogram itself + rgb values) according 
to the ProPhoto values.


As I mentioned earlier, that is what RawTherapee does: it 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".


That is also what Lightroom does: "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

Normand


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Edgardo Hoszowski]

PR 2069 is ready, please test it.


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[dt-list]

Normand Fortier (2019-Feb-06, excerpt):
> We need the display profile to display the image on the monitor that DT is
> using, but the ultimate destination of the image is something different: it
> could be the Web (sRGB) or a printer. In my case I export images with
> ProPhoto and then the Turboprint driver applies the correct profile for the
> printer and paper combination.

This is exactly my understanding as well.  Unfortunately, my knowledge
is *very* imited, I'm just a user, far from an expert!

> In other words the display profile and the output profile (meaning: the
> profile that will be used for export) are different and should be treated
> distinctly in DT. As M. Moy said in an earlier post (same thread):
> "A more rigorous approach would run the image through the pipeline up to the
> output color profile, and then export to monitor space to display the image
> and to another monitor-independant space for the picker and histogram."
> I think this is also what S. Klinger what referring to in yet another post
> from same thread:

Yes.  In my understanding, the whole idea of color management is to
give on screen the *impression* of what an image would look like when
printed.  From that perspective, I don't see why I'd want to know the
pixel values used to do so on screen, *unless* exporting for exactly
that screen.

Doing it different from what Matthieu Moy said sounds broken to me.
But I wonder: When I'd like to know the color that appears in the
output, then by what means?  E.g., if the output was a CMYK printer,
what should the color picker do?  Tell me the CMYK values?  Or RGB
values derived from them?  In the latter case, I doubt it would be the
same values as passed to the screen.

I do not know...


-- 
http://stefan-klinger.deo/X
I prefer receiving plain text messages, not exceeding 32kB. /\/
  \

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

> You are talking about the final histogram & color picker only, and
> that's very different from having in synch over/under exposed, gamut
> check, final histogram & color pick, all on the same colorspace, so
> could you please clarify that?

Though my initial post was about the main histogram and global color 
picker, I realized it was a wider question as other modules work in RGB 
(channel mixer for instance).


Remco, thanks for the hint about the order of modules! So DT applies all 
modules that work in input (camera) RGB, then the modules that work in 
Lab, then the output RGB profile, then the modules that work in RGB?


The problem then becomes the fact that DT does not distinguish between 
display profile and output (destination) profile; actually it assumes 
that the display profile is the destination profile.  The only use case 
in which this is optimal is the one that Edgardo described: using sRgb 
as a display profile while creating images for the Web.


In my case I want to export images in a color space that is wider than 
the printer profile that Turboprint is using, so that no data is lost in 
that conversion -- that's why I use ProPhotoRGB. But setting ProPhoto as 
my display profile in DT means I am editing blindly since the image then 
looks very different (and bad!) on my monitor. The problem is going to 
appear anytime someone wants to output an image using a profile 
different from the display profile.


So I would like DT to use, say, ProPhoto as a working profile for 
modules that work in RGB, or even better allow user to choose which 
working RGB profile to use, while keeping the display profile distinct. 
Then I know I am not forcing unnecessary narrowing conversions. I can 
then use softproofing to evaluate the effect in the destination profile 
(printer, sRgb, whatever). Right now, why do we even have softproofing, 
if the expectation is that DT will display images using the output 
(destination) profile?


Normand

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Remco Viëtor]

On mercredi 6 février 2019 16:18:50 CET Normand Fortier wrote:
> Thank you for looking into this. Here is what I understand,
> unfortunately my knowledge is quite limited, so thanks for your patience!
> 
> We need the display profile to display the image on the monitor that DT
> is using, but the ultimate destination of the image is something
> different: it could be the Web (sRGB) or a printer. In my case I export
> images with ProPhoto and then the Turboprint driver applies the correct
> profile for the printer and paper combination.

(...)
> I would prefer that, past the stage where camera (input) RGB is used,
> processing be done within the largest possible color space to minimize
> artifacts, etc (this is why DT used 32bit floating, I assume). Since
> some modules work/display data in RGB and some in Lab, the RGB space
> should be as large as possible to minimize data loss during to and fro
> conversions. Adjustments for a narrower space on output should be done
> on export or using soft proofing.

https://www.darktable.org/usermanual/en/color_management.html
explains the different colour spaces used within darktable and when the 
conversions happen.

According to that page, the initial part of the pipeline is in the camera-
specific RGB space, then there's a conversion to CIELAB, and  the (narrowing) 
conversion to a standard RGB space happens towards the end of the pipeline (at 
the "output color profile" module). To see where the different modules appear 
in the pipeline, look in the leftmost module tab i nthe darkroom (the tab with 
the "power switch" symbol).

Remco




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Edgardo Hoszowski]

I do most of my processing for the web so the current design is good enough
for me, and more important, I'm not sure about your needs. What I do want
as a user is the over/under exposed, gamut check, final histogram & color
pick to work on sRGB, because that is what I use to export. That happens to
be my display profile, so I'm happy (let's say).

You are talking about the final histogram & color picker only, and that's
very different from having in synch over/under exposed, gamut check, final
histogram & color pick, all on the same colorspace, so could you please
clarify that?

No matter your answer, there's a catch, right now there are some modules
after the output color profile, so if you use some of those modules,
results may be different on the color pick & histogram and the exported
image, this is a limitation of the current design that is being fixed wit
PR 1841 [1] (but don't hold your breath on this)

We are talking about the requirement here, so there's no need to go into
implementation specifics.

[1] https://github.com/darktable-org/darktable/pull/1841

El mié., 6 feb. 2019 a las 12:19, Normand Fortier (<
normand.fort...@cgocable.ca>) escribió:

> Thank you for looking into this. Here is what I understand,
> unfortunately my knowledge is quite limited, so thanks for your patience!
>
> We need the display profile to display the image on the monitor that DT
> is using, but the ultimate destination of the image is something
> different: it could be the Web (sRGB) or a printer. In my case I export
> images with ProPhoto and then the Turboprint driver applies the correct
> profile for the printer and paper combination.
>
> In other words the display profile and the output profile (meaning: the
> profile that will be used for export) are different and should be
> treated distinctly in DT. As M. Moy said in an earlier post (same thread):
> "A more rigorous approach would run the image through the pipeline up to
> the output color profile, and then export to monitor space to display
> the image and to another monitor-independant space for the picker and
> histogram."
> I think this is also what S. Klinger what referring to in yet another
> post from same thread:
> "Hmmm, does that mean that the histogram is calculated from the
> on-screen representation instead of from the image that would be
> created just before export?  I was hoping for the latter, and expected
> that to be also used to implement gamut checking?"
>
> I would prefer that, past the stage where camera (input) RGB is used,
> processing be done within the largest possible color space to minimize
> artifacts, etc (this is why DT used 32bit floating, I assume). Since
> some modules work/display data in RGB and some in Lab, the RGB space
> should be as large as possible to minimize data loss during to and fro
> conversions. Adjustments for a narrower space on output should be done
> on export or using soft proofing.
>
> This is what RawTherapee and Adobe products do, I think: PS uses
> ProPhoto as a working space, but offers Lab modules as well (while DT
> takes the reverse approach). (See earlier post:
>
> https://www.mail-archive.com/darktable-user@lists.darktable.org/msg06968.html
> ).
> In this perspective the display profile is not satisfactory since it
> could be rather narrow. Besides, using the display profile for modules
> that work in RGB means such processing done on the image will be
> impossible to reproduce exactly on a different monitor (unless keeping a
> copy of the profile of the monitor with which the image was processed).
>
> Normand Fortier
>
> Le 19-02-05 à 22 h 23, Edgardo Hoszowski a écrit :
> > In dt some modules work on camera rgb, others on lab or prophotoRGB or
> > whatever the output color profile returns. The final histogram and color
> > picker collect the data after the last module (gamma) has been processed
> > and display it in the display profile (and lab).
> >
> > The color picker is returning inaccurate results and is being fixed in
> > PR 2066 [1] (you are welcome to test it)
> >
> > Other than that, I'm not sure what your request is. We are talking about
> > the final histogram, so this is the right place to collect the data. Do
> > you want the data to be displayed in other format than the display
> profile?
> >
> >
> > [1] https://github.com/darktable-org/darktable/pull/2066
> >
> >
> > El mié., 23 ene. 2019 a las 15:22, Normand Fortier
> > (mailto:normand.fort...@cgocable.ca>>)
> > escribió:
> >
> > I am creating test images in order to get a better grasp on soft
> > proofing for printing. These images simply contain patches of
> different
> > shades of gray. I created them using Inkscape and then exported to
> png
> > (see appended image).
> >
> > If I inspect the image using Geeqie or Gimp with the same monitor
> color
> > profile I am using in Darktable, the rgb values all match the
> intended
> > value: each hexagonal patch has an rgb value which corresponds to its
> 

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

Thank you for looking into this. Here is what I understand, 
unfortunately my knowledge is quite limited, so thanks for your patience!


We need the display profile to display the image on the monitor that DT 
is using, but the ultimate destination of the image is something 
different: it could be the Web (sRGB) or a printer. In my case I export 
images with ProPhoto and then the Turboprint driver applies the correct 
profile for the printer and paper combination.


In other words the display profile and the output profile (meaning: the 
profile that will be used for export) are different and should be 
treated distinctly in DT. As M. Moy said in an earlier post (same thread):
"A more rigorous approach would run the image through the pipeline up to 
the output color profile, and then export to monitor space to display 
the image and to another monitor-independant space for the picker and 
histogram."
I think this is also what S. Klinger what referring to in yet another 
post from same thread:

"Hmmm, does that mean that the histogram is calculated from the
on-screen representation instead of from the image that would be
created just before export?  I was hoping for the latter, and expected
that to be also used to implement gamut checking?"

I would prefer that, past the stage where camera (input) RGB is used, 
processing be done within the largest possible color space to minimize 
artifacts, etc (this is why DT used 32bit floating, I assume). Since 
some modules work/display data in RGB and some in Lab, the RGB space 
should be as large as possible to minimize data loss during to and fro 
conversions. Adjustments for a narrower space on output should be done 
on export or using soft proofing.


This is what RawTherapee and Adobe products do, I think: PS uses 
ProPhoto as a working space, but offers Lab modules as well (while DT 
takes the reverse approach). (See earlier post:

https://www.mail-archive.com/darktable-user@lists.darktable.org/msg06968.html).
In this perspective the display profile is not satisfactory since it 
could be rather narrow. Besides, using the display profile for modules 
that work in RGB means such processing done on the image will be 
impossible to reproduce exactly on a different monitor (unless keeping a 
copy of the profile of the monitor with which the image was processed).


Normand Fortier

Le 19-02-05 à 22 h 23, Edgardo Hoszowski a écrit :
In dt some modules work on camera rgb, others on lab or prophotoRGB or 
whatever the output color profile returns. The final histogram and color 
picker collect the data after the last module (gamma) has been processed 
and display it in the display profile (and lab).


The color picker is returning inaccurate results and is being fixed in 
PR 2066 [1] (you are welcome to test it)


Other than that, I'm not sure what your request is. We are talking about 
the final histogram, so this is the right place to collect the data. Do 
you want the data to be displayed in other format than the display profile?



[1] https://github.com/darktable-org/darktable/pull/2066


El mié., 23 ene. 2019 a las 15:22, Normand Fortier 
(mailto:normand.fort...@cgocable.ca>>) 
escribió:


I am creating test images in order to get a better grasp on soft
proofing for printing. These images simply contain patches of different
shades of gray. I created them using Inkscape and then exported to png
(see appended image).

If I inspect the image using Geeqie or Gimp with the same monitor color
profile I am using in Darktable, the rgb values all match the intended
value: each hexagonal patch has an rgb value which corresponds to its
displayed number (e.g. "24" -> rgb 24,24,24). However in DT, the values
provided by the global color picker (set to point and rgb) are
different.

For example, in the upper left group:
24 -> (29,29,28)
25 -> (29,30,29)
26 -> (30,30,29)
27 -> (31,31,30)
28 -> (31,32,31)
29 -> (32,33,32)
30 -> (33,34,33)

I set the monitor profile explicitly in Geeqie and Gimp, as well as in
DT using the monitor icon in lighttable mode and the soft proofing and
gamut icons in darkroom mode.

It seems DT is not displaying the image properly, or the picker is
reporting faulty values. Could anyone offer an explanation?
Thanks!

Normand


darktable user mailing list
to unsubscribe send a mail to
darktable-user+unsubscr...@lists.darktable.org






darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Edgardo Hoszowski]

In dt some modules work on camera rgb, others on lab or prophotoRGB or
whatever the output color profile returns. The final histogram and color
picker collect the data after the last module (gamma) has been processed
and display it in the display profile (and lab).

The color picker is returning inaccurate results and is being fixed in PR
2066 [1] (you are welcome to test it)

Other than that, I'm not sure what your request is. We are talking about
the final histogram, so this is the right place to collect the data. Do you
want the data to be displayed in other format than the display profile?


[1] https://github.com/darktable-org/darktable/pull/2066


El mié., 23 ene. 2019 a las 15:22, Normand Fortier (<
normand.fort...@cgocable.ca>) escribió:

> I am creating test images in order to get a better grasp on soft
> proofing for printing. These images simply contain patches of different
> shades of gray. I created them using Inkscape and then exported to png
> (see appended image).
>
> If I inspect the image using Geeqie or Gimp with the same monitor color
> profile I am using in Darktable, the rgb values all match the intended
> value: each hexagonal patch has an rgb value which corresponds to its
> displayed number (e.g. "24" -> rgb 24,24,24). However in DT, the values
> provided by the global color picker (set to point and rgb) are different.
>
> For example, in the upper left group:
> 24 -> (29,29,28)
> 25 -> (29,30,29)
> 26 -> (30,30,29)
> 27 -> (31,31,30)
> 28 -> (31,32,31)
> 29 -> (32,33,32)
> 30 -> (33,34,33)
>
> I set the monitor profile explicitly in Geeqie and Gimp, as well as in
> DT using the monitor icon in lighttable mode and the soft proofing and
> gamut icons in darkroom mode.
>
> It seems DT is not displaying the image properly, or the picker is
> reporting faulty values. Could anyone offer an explanation?
> Thanks!
>
> Normand
>
>
> 
> darktable user mailing list
> to unsubscribe send a mail to
> darktable-user+unsubscr...@lists.darktable.org


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Dusenberg]

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

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

Screen captures mentioned in text below.

Le 19-01-26 à 15 h 03, Normand Fortier a écrit :

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






darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

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

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

dt-l...@stefan-klinger.de :

Matthieu Moy (2019-Jan-24, excerpt):

dt runs
the image through the whole pipeline, displays the result and uses
it for the picker and histogram. A more rigorous approach would run
the image through the pipeline up to the output color profile, and
then export to monitor space to display the image and to another
monitor-independant space for the picker and histogram. That may
happen one day, but it's not how it is today indeed.


Hmmm, does that mean that the histogram is calculated from the
on-screen representation instead of from the image that would be
created just before export?  I was hoping for the latter, and expected
that to be also used to implement gamut checking?

That comment ties is with what I am trying to do. Say I find that a 
given matte paper shows detail between rgb(30,30,30) and (250,250,250) 
(hypothetical for a b image), I would like to process the image so 
that its tones fall appropriately between those values.


If the global color picker only shows values after conversion to the 
monitor profile, then those values are not related to the values in the 
image on export and cannot be used. I cannot know which areas of the 
image fall below, at or above a precise threshold. Pressing the 
softproofing icon does not help because although it does show the effect 
of the printer profile visually, the values reported by the global 
picker are the same as without softproofing, i.e. they reflect the 
monitor profile and not the printer profile.


I've looked at the histogram with different monitor profile (without 
checking the box in the global picker that affects the histograms), and 
it does change, so it seems to work like the global picker. If that is 
so (I would like a confirmation) then the situation is much worse 
because even the histogram cannot be trusted when one wants to print.


I wonder if someone who knows DT better than I do could perhaps confirm 
or deny these findings?



darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[dt-list]

Matthieu Moy (2019-Jan-24, excerpt):
> dt runs
> the image through the whole pipeline, displays the result and uses
> it for the picker and histogram. A more rigorous approach would run
> the image through the pipeline up to the output color profile, and
> then export to monitor space to display the image and to another
> monitor-independant space for the picker and histogram. That may
> happen one day, but it's not how it is today indeed.

Hmmm, does that mean that the histogram is calculated from the
on-screen representation instead of from the image that would be
created just before export?  I was hoping for the latter, and expected
that to be also used to implement gamut checking?


-- 
http://stefan-klinger.deo/X
I prefer receiving plain text messages, not exceeding 32kB. /\/
  \

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Matthieu Moy]

> The global color picker works in monitor color space and takes
> samples after the complete pixelpipe has been processed.
> [...]
> I have no idea why this would be considered useful.

I don't think anyone claimed that this is useful, but this is easy to implement 
without breaking the way the pipeline works. dt runs the image through the 
whole pipeline, displays the result and uses it for the picker and histogram. A 
more rigorous approach would run the image through the pipeline up to the 
output color profile, and then export to monitor space to display the image and 
to another monitor-independant space for the picker and histogram. That may 
happen one day, but it's not how it is today indeed.

-- 
Matthieu Moy
https://matthieu-moy.fr/

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

I don't know, I admit I did not check what Inkscape does by default (I'm 
not completely clear on color management...). However when I open the 
png (exported from Inkscape) in Geeqie, which uses my monitor profile 
(same as the one used in DT), then the rgb values it shows correspond to 
the white numbers on the centre of patches.


Thank you also to the others who responded, I'm going to think this over 
a bit more and will post tonight.


Normand

Jim Robinson:


I get essentially the same values as you with sRGB as the input color 
profile, but if I change it to Adobe RGB I get essentially the correct 
values (sometimes +/- 1).  What colorspace was the image saved in?




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Jim Robinson]

On Wed, 23 Jan 2019 at 18:22, Normand Fortier 
wrote:

> I am creating test images in order to get a better grasp on soft
> proofing for printing. These images simply contain patches of different
> shades of gray. I created them using Inkscape and then exported to png
> (see appended image).
>
> For example, in the upper left group:
> 24 -> (29,29,28)
> 25 -> (29,30,29)
> 26 -> (30,30,29)
> 27 -> (31,31,30)
> 28 -> (31,32,31)
> 29 -> (32,33,32)
> 30 -> (33,34,33)
>

I get essentially the same values as you with sRGB as the input color
profile, but if I change it to Adobe RGB I get essentially the correct
values (sometimes +/- 1).  What colorspace was the image saved in?

Jim


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[dt-list]

Normand Fortier (2019-Jan-23, excerpt):
> For example, in the upper left group:
> 24 -> (29,29,28)
> 25 -> (29,30,29)
> 26 -> (30,30,29)
> 27 -> (31,31,30)
> 28 -> (31,32,31)
> 29 -> (32,33,32)
> 30 -> (33,34,33)

I observe this too, slightly different values though.  According to
the manual [1]

The global color picker works in monitor color space and takes
samples after the complete pixelpipe has been processed.

so I would assume that you'd see all sorts of effects, including
mapping to you monitor's color space.  The values reported by
darktable are consistent with what is reported when you take a
screenshot of darktables showing your image.

I have no idea why this would be considered useful.

When I re-export your image as PNG, I'd get the original values again,
that's quite surprising to me...

If no convincing explanation shows up on this thread, file a bug
report.



[1] https://www.darktable.org/usermanual/en/global_color_picker.html


-- 
http://stefan-klinger.deo/X
I prefer receiving plain text messages, not exceeding 32kB. /\/
  \

darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org

Re: [darktable-user] Inaccurate color display or color picker?

[Normand Fortier]

I should have mentioned: this is darktable 2:2.6.0-1 on Archlinux.

Le 19-01-23 à 13 h 11, Normand Fortier a écrit :
I am creating test images in order to get a better grasp on soft 
proofing for printing. These images simply contain patches of different 
shades of gray. I created them using Inkscape and then exported to png 
(see appended image).


If I inspect the image using Geeqie or Gimp with the same monitor color 
profile I am using in Darktable, the rgb values all match the intended 
value: each hexagonal patch has an rgb value which corresponds to its 
displayed number (e.g. "24" -> rgb 24,24,24). However in DT, the values 
provided by the global color picker (set to point and rgb) are different.


For example, in the upper left group:
24 -> (29,29,28)
25 -> (29,30,29)
26 -> (30,30,29)
27 -> (31,31,30)
28 -> (31,32,31)
29 -> (32,33,32)
30 -> (33,34,33)

I set the monitor profile explicitly in Geeqie and Gimp, as well as in 
DT using the monitor icon in lighttable mode and the soft proofing and 
gamut icons in darkroom mode.


It seems DT is not displaying the image properly, or the picker is 
reporting faulty values. Could anyone offer an explanation?

Thanks!

Normand

 


darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org




darktable user mailing list
to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org