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.de o/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
