Yeah, that’s the other thing: ProPhoto colorspace is a lot bigger than any printing medium of which I’m aware. You really need to export to a colorspace more aligned with the destination printer.
There is one more, subtle and counterintuitive thing to consider here:
The larger the gamut you choose, the less efficient (and therefore more risky) the coding is when not using floats. The larger the gamut, the less of the 0-1.0 range your real data actually occupies in it, so when you quantize it, the full range is being unused by the available levels, i.e. you have less quantization levels than you think covering your data.
Since ProPhoto is extremely large, you’re actually wasting bits and are not benefiting from 16b as much as you would hope (only ACES AP0 being “worse” in this regard). This is partly because of the imaginary primaries it uses, so a lot of this gamut (and ACES AP0) is unfortunately wasted space as a side effect.
As others have concluded, don’t use ProPhoto (and certainly not linear) w/ integer coding, and don’t use it for delivery. Choose a gamut that just about envelops your data, and/or best matches your delivery medium.
7 Likes
Very interesting. I can confirm that when re-importing the 16bit prophotoRGB image into darktable, it doesn’t have banding, so the information is not lost. 8bit prophotoRGB has banding in both geeqie and darktable.
Unfortunately, the printing shop appears to have used a similarly inadequate conversion pipeline. The print has the same banding.
Good advice.
1 Like
Can I ask the contributors here what they would recommend for exporting tiff files from DT as archival storage that can later be used to edit in programs like GIMP and Photoshop if required? I currently use 16 bit tiff in Adobe RGB profile. Would there be an advantage in 32 bit floating point?
And for my two cents worth to the original OP’s question is that most consumer digital photo processing labs are setup for sRGB color space as this is the most common image format brought in. If using a professional printing lab you should ask their advice and they may even provide a color profile to use that will match their equipment and materials.
If you were planning on doing more editing then I wouldn’t restrict it. I would save it in Linear Prophoto or Rec2020 and I would just do that from my raw when I intended to use it rather than adopt that as an archival format. I guess I am saying that in that workflow I would keep as much data as I can for as long as I can… for me a 16bit Adobergb is not the best editing source I could generate from a raw edit to be further processed and not very efficient for basic archival… but that would just be how I look at it…
You’re not going to get a good result unless you send to the printer a rendition with a gamut close to the printer’s capabilities. Then, you have control over the destination gamut. A good print shop will be able to provide you with color profiles for their printers, use them in the same way you’d use sRGB for web export.
1 Like
A linear color space is darker (really bad explanation but go with it :)). So the darks become more crushed together.
Also, how are you viewing the banding ? In different tools I notice that for viewing a quick ICC convert is done that isn’t as precise. Actually converting back to sRGB or something else makes it look better than the preview . (True for irfanview, affinity photo and Photoshop for instance).
1 Like
The issue still is that filmic behaves differently depending on the output profile being used . So whatever you export to. It might be different then what’s on your screen .
Of this wasn’t the case, I would say use linear rec2020 kust to keep it in the profile Darktable uses while editing , skipping a conversion.
And for me 16bit tiff seems fine . 32bit floating point also has compatibility issues between different software sometimes . Exr with its compression is interesting but is a weird format as far as colourspace compatibility (and support or that, lots of software just assumes it to be linear sRGB /709).
So for me it’s 16bit tiff. These days saved as lossless compressed jpeg xl or jpeg-xl in a good visually-lossless setting if the material can handle it .
(Cjxl -d 0.001 --intensity_target 500 or something like that).
I find this comment interesting. Can you elaborate please? This seems a big problem since we surely all depend upon what we see on the screen and seek to have an output faithful to that.
filmic rgb contains gamut compression that targets the selected output profile. There would be no point in using e.g. Rec2020 or AdobeRGB as output profile if filmic always compressed everything to say sRGB.
1 Like
Do you mean that a good print shop would offer an ICC for each print-type, and then accept an exported image using exactly those ICCs, and print it without any additional color conversion on their part?
While the print shops I’ve tried offer ICCs, this seems to only be meant for softproofing, and they still want the images in sRGB, aRGB or prophoto.
Are you sure?
From what I see from your files it is not an issue of the color space but it is in the image…
Hermann-Josef
For gnome image viewer and geeqie, the banding looks similar to the physical print. It’s fine when re-importing the 16bit image to darktable.
Yes.
If I export to 16-bit integer non-linear ProPhotoRGB profile RTv4_Large from RawTherapee then Geeqie and Gnome image viewer render without bands.
I use 16 bit integer linear ProPhotoRGB files as input to HDR stacking and focus stacking with enfuse from Hugin package. For these linear ProPhoto Files I get the same banding as @Tethys in Geeqie and Gnome image viewer. However Darktable and GIMP render linear ProPhotoRGB without issues.
RT output profiles are here: https://github.com/Beep6581/RawTherapee/tree/dev/rtdata/iccprofiles/output
EDIT: The printing company I use state that they convert from any embedded working profile, but they recommend not to send ProPhotoRGB. I send AdobeRGB files. That is fine for my Lambda C-print on Fuji Chrystal Archive.
Am I allowed to say this here 
?
I opened your 16bit_prophoto in PhotoShop with the embedded profile and I do not see the banding:
Hermann-Josef
PS: Sorry, I was wrong with my previous post in misinterpreting the banding you are talking about. Your image above made this clear to me.
What kofa said . Filmic has code that looks at the gamut , and compresses it while trying to maintain perceptual information.
It always uses the output profile, which is your monitor (or probably sRGB or similar) when viewing , and the output profile selected for the image when exporting.
If both a sRGB or similar , there will be no difference.
Exporting (linear) rec2020 and converting that to sRGB in another tool can sometimes fix issues with bright yellow/orange/reds changing (to magenta for instance).
But converting it in another program will most likely crush the gamut , so it’s clipping color information, OR doing something similar to filmic.
But those clipped colors can sometimes be what you want (instead of things turning bright white , or turning magenta , or…).
I made an argument for this here somewhere and in a GitHub issue that the soft proofing mode should be in play here so there is some way to see on your monitor what will be in the file (even if its crushed colors ).
Did a few lines of demo code that seems to work for me at least, but the GitHub issue remained silent.
So, i can set linear rec2020 as my soft proof profile , and then toggle soft proof on and off to see what effect is has And if I like one more to the other.
Others use filmic v5 in ‘no’ mode that has no gamut mapping , or sigmoid .
I think it’s a real world issue if you have a wide gamut monitor like a good studio monitor with (near) adobergb capabilities. What you then see on screen is less gamut mapping compared to what is in a sRGB export for the web. So your reds could suddenly turn magenta-ish on export but not on your screen.
The other way around (sRGB alike monitor but soft proof with something wider like rec2020) is less ‘practical’, but is essentially a way to turn the gamut mapping on or off .
Further discussion is for another thread or DMs , not this topic :).
1 Like
Thanks for your detailed response. I didn’t want to hijack the thread, but the OP’s original question led me down this path and the OP want to get a print that looks like the screen (as we all do) so it felt my question was relevant even if off on a tangent.
I found this information very useful too.