Sorry, I’m talking under the gamut checking tool not under the output color module.
My understanding is “system display profile” pulls in whatever your monitor’s profile is setup as from reading that page in the manual.
Histogram and softproof should be set to whatever you’re targeting for final display if I follow the logic here. sRGB for a website for example or profiles for your printer/paper combo, etc. This is what changes the OOG warnings right?
No that what color management is for…histogram and working profile should be in a wide space so that you can work in that wide color space and that you can show it in the histogram. As long as you are in gamut in linear rec 2020 then you let the output profile map the gamut…
When you enable soft proofing it replaces your display profile with the one selected so as to attempt to show you what the output will be. Up until recently most monitors weren’t far off sRGB so it doesnt make a difference… If you have a calibrated monitor as it seems you do then that icc shoud be used for your display profile…Preview profile is only valid if you have a second monitor.
There is a lot of discussion around the what the profiles are handled and as you can see if you go through this even some of the dev’s had to get their heads wrapped around it…
Which I do, so that only effects the “display a second darkroom window” feature as I understand it? These options only effect soft proofing and not the actual output. It’s used to say “I’m going to be looking at this printed with printer X that can only handle colorspace Y and need to check before I waste paper.” What are you meaning when you’re referring to working profile in that context? My understanding is that’s handled by color input not by these tools?
The output color profile I roughly understand as taking the RAW and baking in the selected profile by making decisions on clipping, etc. Essentially distilling the wider gamut of darktable’s working space down into what the the output profile can display. I think sRGB is default here because lots of stuff just heads to the web and that’s the most safe choice right?
It seems like what you’re saying is the histogram profile is set to sRGB as a relic of past logic or hardware limitations then?
I think I agree with the devs in that thread that state this needs to be more clearly represented. It’s not terribly complicated just kind of not easily understood from the GUI (esp the display vs preview thing).
You’d be surprised how many cheap displays are still being made that can’t even hit 100% sRGB. I do a lot of hardware work these days and there still bad monitors being cranked out.
It is a shame that I can’t afford anything above 50% sRGB. Everything is so expensive. As said elsewhere, even 8GB+ laptops are super expensive where I live. Come on: it is 2021!
I’ve got friends in Asia that say similar things but mostly about cameras. Nikon makes most of their cameras in Thailand and they’re still cheaper here in the States than they are for a couple of friends I have over there. I’m not sure if they’re quite at the level of being cheaper to fly to the US and buy one than it is to source locally but it’s fairly substantial.
Thats a very nice editing, I like your colors and contrast, could you maybe share the xmp please, or explain which general modules were used? Thank you!
Unless disabled in darktable, editing history is normally included in the exported JPG. Have you tried loading the JPG as a sidecar? darktable 4.0 user manual - history stack under ‘load sidecar file’:
Images that were exported by darktable typically contain the full history stack if the file format supports embedded metadata (see the export selected module for details of this feature and its limitations). You can load an exported image as a sidecar file in the same way as you can with an XMP file.
Open the dialog and change the default *.XMP filter to ‘All files’, select the JPG and load it.
That would be my thinking too …there is currently a problem with DT. The display profile is processed before passing data to the histogram profile ie between the working profile and the histogram profile which provides the gamut information to the clipping indicators. So the data is clipped by the display profile before being passed to the histogram profile so if you have a your working profile at rec2020 and your histogram profile at rec2020 the position of the display profile ensures that you will almost never see clipping. The only way to be sure is to temporarily set your display profile to rec2020. Your displayed image will look crappy but now the colorspace is not compressed before getting to the histogram profile…
Explained better here perhaps…
In the end its key to understand this as it affects the data in the histogram and the accuracy of the warnings…
Also Quoted from issue 3271
"This transformation goes from the display profile to the histogram profile. So it seems either the input image for histogram calculation is coming from a part of the pixelpipe where the image has already been converted to display profile, or there is a mistake in this conversion.
Maybe this is a corner case, but there’s an issue here at least in cases where the display profile doesn’t cover the whole gamut of the histogram profile (this is the case for my display profile) – some of the color information is lost during the transition
working profile -> display profile -> histogram profile
if gamut of the display profile is a subset of the histogram profile.
Reading the release notes I would have intuitively expected the pipeline to be something along the lines of
/--> display profile -> displayed image
working profile -|
\--> histogram profile -> histogram, color picker, overexposure
By branching the conversion to display profile and histogram profile, one would avoid the loss of information which is a likely root cause of the issue with the histogram and color picker values changing. What do you think?"
Yes this is what I mean, my display profile is set to my screen’s profile. That’s the one I “work” with in that context. The “working profile” setting in input color profile is set to Linear Rec2020. Sorry for the confusion.
After exchange, before taxes, electronics are on average $500 more than American prices, and it takes more to earn the $500 here. Actually, COVID-19 is doing me a service because it is moving old hardware. For under $1500, we usually pay through the nose for backward or unsupported hardware! This is true for monitors as it is for cameras. People here talk about new cameras; I see the prices of a decade old camera and shudder. But I digress.
The dt gamut issue seems a bit tricky.
In the meantime I checked out what Rawtherapee does. There is no OOG highlighted when the jpeg is loaded. But changing the saturation (in exposure tool) from zero to just 1 causes a fair bit of OOG to be shown. So that’s good for my sanity.
This image doesn’t have much blue, which makes it easier to manage. I wonder how your workflows would handle an image with more areas of blue. Would the improvements feel less impressive? E.g., problematic indoor performance scenes discussed on some of the threads. Not to take away from the advancements and @lhutton’s success on the image.
So to continue from above…your gamut clipping will not be accurate with those settings unless you change your display profile out to rec2020 when testing gamut…depending on what you set your histogram profile for you will either show clipping when there really is none or you will not show clipping when there is…because of DT’s profile processing the indicators will only truly be accurate if working = display = histogram
