Why is this the default working profile? Would not “linear ProPhoto RGB” which has a larger color space be more suited for RAW file editing? Wouldn’t you want to have as much RAW data as possible available when doing edits?
I read this discussion a while back which does not, as far as I can see, answer my question.
I am using “linear ProPhoto RGB” in my workflow. I export to ProPhoto 16 bit TIFF’s for further work in PS. Why wouldn’t I want to have as much data as possible in that TIFF for editing?
Maybe someone could clarify why working in any other color profile would be preferred.
Why don’t you just change it by creating an auto-applied preset for input color profile, if it bothers you so much?
For what it’s worth, I’ve tried some even wider spaces. In darktable, some module (I think it was color calibration) produced artefacts. That could probably be fixed, though.
If all modules in your pipeline can handle negative values (not all of them can, e.g. filmic takes a log, and you can’t do that with negative numbers), even a smaller space can handle all colours.
Surface colours, the so-called Pointer’s gamut, is much smaller than Rec 2020. It’s the narrow-spectrum light sources that cause issues.
@kofa, it’s not that it bothers me. It doesn’t. I have created the input color profile.
I just want to understand the reasoning behind it. Can someone show, not theorize, where ProPhoto would not be most beneficial in darktable and exported as a 16 bit TIFF for both archiving and raster editing for further enhancements which darktable is not suited for?
For export, you want an efficient space: one where most code values represent real colours (especially if you use integer encoding). Many values in ProPhoto encode colours outside the human gamut. That means there is a portion of code values lost to us, leaving a smaller subset that needs to cover the visible spectrum, leading to lower resolution. With floating-point output, that’s not an issue, though.
In Rec. 2020, all the “data” is color information because it is inside the CIE x,y locus: not so for ProPhoto which includes larg-ish areas that are outside of the CIE x,y locus and therefore are useless data. Any data lying outside the CIE x,y locus is out of gamut for humans … we can’t see 'em.
Part of ProPhoto represents colours that we don’t see. In that sense, ProPhoto is not efficient.
16-bit-per-channel RGB encoding means you have 65536 different levels for each of red, green and blue. In Rec 2020, all of those are real colours. In ProPhoto, there are quite a few combinations that do not encode anything we could see. Look at its chromaticity diagram at ProPhoto RGB color space - Wikipedia : its green and blue are outside the visible gamut.
Yes, I understand what @kofa and @cedric are referring to. Still, in order to better form an opinion for myself, I would like to hear from someone who disagrees.
Prophoto also has a wp of D50 I think and rec2020 is d65. . I recall something related to display output and preferring d65…I forget what though…I think it was just to be better aligned to the HDR standard…
I once worked with prophoto in LR but abandoned it as none of my displays or my eyes could see all the colors it worked with. It seemed to me that I was working with imaginary colors. I defer to the software’s default color profile and when I export my 16 bit tiffs for archival edit storage I use adobe rgb, but when I export for JPG I use sRGB. I am happy for a knowledgeable person to call me a moron and explain a better strategy because I like many get confused about this topic.
When you render an image for display or export, ideally the gamut should be the one that the destination display/print can accommodate. For your monitor it should be the monitor’s measured gamut captured in a display profile, same for a destination printer. For export JPEG or somesuch for display on others’ browsers or other software, you’re at a disadvantage not knowing what those may be. If the others’ are color-managing, all you need is to embed a ICC profile that corresponds to the exported image gamut, and the viewer software will transform it using that information. If not, sRGB is still the best bet, although high-gamut displays are vexing that assumption.
Really, this is the only transform absolutely needed, camera → display/export. Working profiles are an interruption, to provide a better-behaved colorspace than the camera spectral response for editing. I must be lucky, rawproc’s operators don’t seem to need a working-space input, so my workflow is all against camera data, with the only color transform occurring at display/export. My camera profiles are all “well-behaved”, according to Elle Stone’s definition, which apparently facilitates this.
The key thing to know is that the camera’s spectral response produces colors greater than what most all rendition media can handle, so somewhere in the workflow a color transform has to take place to compress the gamut to what the destination medium can handle.
Mike, the only solace I can offer is that any intermediate transform to a working space is going to a gamut that’s still larger than the destination display/export gamut, so that final transform will still be well-informed. Transforming from a smaller to a larger gamut is just making stuff up, as the original hues were lost in the transform to the smaller gamut.
Then the photos not in ProPhoto RGB are not being future proofed for the wider gamut screens and printers coming in the future. At least that’s the way I see it.
When it comes to the colorspace you use I guess it depends how you look at it and analyse it, and also as Elle notes what you will use your images for as there can be some color trade-offs…
So, you could say oh colorspace X has a bigger gamut so it must be better with more data/space for colors…
Another perspective and some discussion around choosng colorspaces is is found here…
Especially section C… Elle cites a set of tests designed to compare math done using certain profiles vs spectral data I believe…some profiles are guaged better than others…
Also under section C12 she points out her opinion and assessment of Prophoto… and also refers to this blog post and testing
I believe her preferred choice is either rec2020 or ACEScg.
She comments on several profiles…its a little older now but I think shows there is a bit more to think about. Also there is a section where she shows how to assess a profile to determine if it is well behaved… she tested 30 of them and of that she judged 9 or so well behaved…
She has a set of profiles…it might be interesting to try her linear prophoto ACEScg and rec2020 and see if there is any difference with the ones used by default in DT…
I think ACES2065-1 is a better future-proofer, it’s a bit bigger than ProPhoto has has the benefit of residing in a configuration-managed workflow with software to support it.
Studying the ACES workflow is instructive with regard to intermediate representations. They’re concerned with having masters that both are “future-proof” as well as provide common ground for the integration of disparate media.
