For printing, I decided to export a photo in 16bit prophotoRGB. However, after the print I noticed banding in the dark regions which should not occur. After creating two test files, the issue is clearly visible on my computer too when exporting in prophoto, but not in srgb.
I was under the impression that 16bit should provide ample of resolution. Is this a bug or am I missing something?
Attaching two files illustrating the issue. Both are TIFF for consistency. The banding is visible in both the gnome image viewer and geeqie: 8bit_srgb.tif (1.1 MB) 16bit_prophoto.tif (2.1 MB)
“linear ProPhoto RGB” is the name of the profile in the export module in darktable.
I think I may have omitted some important information. I don’t need to use prophoto. The print shop listed srgb, argb and prophoto as valid color spaces. Prophoto RGB looked to be the “largest” color space, so I went with it. If this banding is inherent to prophoto, I can use sRGB or aRGB, rather than enabling dithering.
I’m confused why it happens though, I thought 16bit prophoto would offer both higher resolution in color levels and more color space than 8bit srgb.
I ran into this coding the display pipeline for rawproc, my hack raw processor. It’s actually gnome viewer/geeqie doing it in the display profile conversion, using the 16-bit integer input format converting to the 8-bit integer output format. When I moved the display transform to prior to converting the image to integer format the conversion was then done floating point → floating point and it went away.
The sRGB image doesn’t show it probably because the color down-conversion is being done in floating point prior to export. The viewer color transform then doesn’t have large color distances to down-convert.
Bottom line, just a consequence of displaying an image meant for another medium, printing.
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.
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.
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.
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).
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.
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.
