3

I have started to print out some of my photos, but this has lead me down a path where I do not know if I am doing things correctly, and are asked questions I do not know the answers to. Here goes:

  • I use Ubuntu (18.04), Darktable (2.6) and Gimp (2.10).
  • My photos are taken in the "Adobe RGB" colorspace. I have set this option in both my cameras.
  • I have used Agryll to color-calibrate my monitor with a Spyder 4 Elite. The profile from Agryll is installed system-wide (On my desktop, I choose settings -> Devices -> Color and see the profile installed for my monitor)
  • When I work on an image which I intend to print, I choose "Adobe RGB" under "output color profile" in Darktable.
  • When I export the image from Darktable, I choose TIFF, 16 bit and "Adobe RGB" as a profile.
  • When I import the images in Gimp, Gimp ask me if I want to convert the images to sRGB. I say no, since Adobe RGB is better.
  • After my work is done, I save the image as TIFF again, and take this to where I want to print it.
  • The reason I want to save it as TIFF, 16 bit, and in Adobe RGB, is to have more color and more info in the image, because the one(s) printing the image often does some work on the image (in cooperation with me) to get it just right.

So, my questions are:

  1. I do not need to install any profile for my monitor in Gimp or Darktable, because both Gimp and Darktable (per default) uses the system-wide profile? Without the need to configure any setting in Gimp/Darktable?
  2. Are the above workflow, with the use of 16-bit TIFF and "Adobe RGB", the correct way to get as much info as possible in the image along the way?
  3. When opening the TIFF-file in Gimp, why are Gimp asking me to convert from built-in profile to "sRGB"? My understanding is that "Adobe RGB" is better?
  4. Are there something I should be aware of, that I have not mention? Or something I am missing? Like some settings i Darktable / Gimp I should set or verify?
  • Just to confirm, it's implied, but not explicit, you're capturing and processing raw images? – xiota Jul 27 at 15:31
  • @xiota Yes, RAW from camera to Darktable, TIFF from Darktable to GIMP (if I intend to print the image) – Sitron_NO Jul 27 at 19:32
1

I'll answer your four questions in a different way that I think makes more sense, which will hopefully also answer each one.

  • Adobe RGB isn't "better" than sRGB. More specifically, it is better in some respects, but not others.
    • Its coverage of the human-visible chromaticity diagram is slightly better than sRGB. But many programs don't understand colorspace, even if the OS does, and assume sRGB. In which case, image color and contrast will seem very noticeably "off". In that regard, sRGB is "better", as it's a universal standard and often assumed.
    • Colorspace metadata can and sometimes does get lost when converting between formats and/or cloud services. Without that metadata, most programs and browsers universally assume sRGB.
    • At 8 bits per color (aka "8bpc" or "24-bit"), subtle gradients are more likely to appear banded, with Adobe RGB as opposed to sRGB. Which is seemingly a paradox until you think about it. sRGB is covers less of the chromaticity diagram, so the numerical difference between perceptibly different colors that can be displayed, is larger. (With more possible integer values in between.) Axiomatically meaning, you can display finer gradients [but narrow total range] with sRGB, than Adobe RGB. But at 16bpc, that's not the case. (It's still technically true even at 16 or 32 bpc, just not noticeable to human perception, and the advantage of a wider coverage of the chromaticity chart is usually deemed worth the tradeoff.)

But if you switch to >= 16bpc to work more accurately with Adobe RGB, you might as well go with ProPhoto RGB, which is even wider. It has even more coverage of the chromaticity diagram. (It can even encode colors humans can't see, which is arguably a drawback, since that's "wasted" values that could have instead gone into encoding better cover the visible colorspace. That whole thing is a tough nut to crack, with everything involving tradeoffs, at least without using 32bpc floating-point representation and all RGB values being absolute, not mapped to a colorspace.)

But so far, ProPhoto RGB is unsuitable for things like website images. (Even if most modern browsers should and seem to be technically and perceptibly OK with it.) For now, ProPhoto and arguably even Adobe RGB should be thought of as more appropriate for intermediate processing steps.

Once an image is converted to it's final compressed form (e.g. jpg for web), a general rule of thumb is that it should be 8bpc sRGB. That may not hold true indefinitely, but still a good tip for now. Our eyes can't really tell the difference, for the end result. It's the intermediate processing, where you may need the extra fidelity. Once you stack a half-dozen semi-transparent layers on top of each other, each with multiple transforms, the mathematical precision loss at 8bpc can start to obviously show in the final output, when compared to the same process at 16bpc or 32bit floating-point.

The reason Gimp is prompting you about Adobe RGB, is because that's the working colorspace it's set up for. (Presumably.) You can change that.

So basically we wind up with these subjective and arguable recommendations:

  • If you're doing very light transformations and/or have an underpowered computer, stick with 8bpc sRGB. It's simpler, it's more portable and universal, and less likely to cause problems.
  • If you're doing heavier transormations and/or have horsepower to spare, go with 16bpc ProPhoto RGB but only as an intermediate format. (Which personally, I also use to store my "master" edit versions in.)
  • For final presentation on a website or computer monitor, it's usually best to export to 8bpc sRGB:
    • JPG for continuous tones and/or real-world photography
    • PNG for synthetic and/or text-heavy images, especially those with fewer, more solid colors. (E.g. brand logos or non-dank text memes. Or anything that needs a transparent background, which JPG doesn't do.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.