print: allow for exporting to linear Rec2020

[dtorop]

Chances are that Rec.2020 is the working profile, and hence this is a reasonable gamut into which to export, compared to the extant choices of sRGB and Adobe RGB.

As colorout currently uses Lab as its input colorspace, there will still be an unneeded colorspace hop (working profile -> Lab -> Rec2020) during the colorout iop in export.

Some questions about the efficacy of this:

1. Would it be better (or an addition improvement) to allow for export to "working profile"?
2. So long as colorspace conversions to sRGB and Adobe RGB are unbounded and the conversion isn't perceptual, does the gamut of the export colorspace matter?
3. Why not just export directly to the printer profile, so that the ensuing conversion to printer profile is a no-op (assuming that conversion is relative colorimetric)?
4. Would exporting to Lab (the current input colorspace of colorout) be sensible, if colorout is the last iop in the pixelpipe? Or is the ideal that eventually colorout will take input in the working profile?

FWIW, I've ran test prints with a range of export profiles (sRGB, Adobe RGB, internal linear Rec2020, Rec2020 from Argyll, and a custom made printer profile) with conversion either perceptual or relative colorimetric. There are subtle differences, but it's hard to pin down which one is most "correct". (Though doing a perceptual intent in export and print conversions is most clearly not correct.)

[TurboGit]

I'm not sure it makes any sense to export a picture using a printer profile. As far as I know this is not a standard profile like work profile and sRGB... A screen profile or printer profile is only indented to be used to render the picture on the media not for a image file.

[dtorop]

I'm not sure it makes any sense to export a picture using a printer profile. As far as I know this is not a standard profile like work profile and sRGB... A screen profile or printer profile is only indented to be used to render the picture on the media not for a image file.

Yes, this makes sense. In which case, shouldn't we remove the printer profiles from the output profile dropdown (the one in the "print settings" section at the bottom)? That way we always export to a sane device-independent profile, then convert to the hardware-specific printer profile.

And then the question becomes what working profile do we actually want to export to. Ideally one which matches or exceeds the gamut of the working profile, and has the same or similar tonal response curve.

Right now we have two choices hardcoded:

• sRGB -- but nowadays most working and printer colorspaces exceed sRGB gamut, so this isn't ideal
• Adobe RGB -- good enough for most purposes

This PR is to add a 3rd choice, Rec 2020 linear, which is the default working profile (between colorin and colorout).

One downside I can see of using a linear colorspace: The export step brings each pixel from float to a 16-bit representation. As we next will convert to a non-linear printer profile, perhaps this risks posterization, and we really want to export to a colorspace whose tonal response curve is close to well-known inkjet printers? Or is this an argument for exporting using a float representation?

[TurboGit]

Yes, this makes sense. In which case, shouldn't we remove the printer profiles from the output profile dropdown (the one in the "print settings" section at the bottom)?

No, because the image is mapped into a profile like sRGB or AdobeRGB and the printer profile is attached to it before sending the image to the printer. This is needed for the printer to know which profile to use for this print (based on the paper kind loaded for example).

[TurboGit]

This PR is to add a 3rd choice, Rec 2020 linear, which is the default working profile (between colorin and colorout).

Again I may be wrong, but as far as I know it is better to export the picture to a profile for with the printer profile has been created. Most (all?) printer profile are done based on AdobeRGB and so that's the best choice when printing. I don't know what Rec2020 could do here. That's tricky stuff and I'm really not sure of the whole implication of this.

[dtorop]

In which case, shouldn't we remove the printer profiles from the output profile dropdown (the one in the "print settings" section at the bottom)?

No, because the image is mapped into a profile like sRGB or AdobeRGB and the printer profile is attached to it before sending the image to the printer. This is needed for the printer to know which profile to use for this print (based on the paper kind loaded for example).

There's two profiles, though.

1. There's the one in the "print settings" section at the bottom of the right panel, which is used as a parameter to dt_imageio_export_with_flags() and then used as the input profile for dt_apply_printer_profile(). This is stored in conf keys plugins/print/print/icc{type,profile,intent}
2. The one in the "printer" section at the top of the right panel, which is used as the output profile to dt_apply_printer_profile(). This one is stored in conf keys plugins/print/printer/icc{type,profile,intent}

The profile from "print settings" is passed to the colorout iop during the export, and it makes sense that it is a well-known intermediate profile such as Adobe RGB. The profile from "printer" should be the hardware specific profile of the printer.

A few thoughts:

1. The distinction between "print settings" and "printer" profiles is confusing! Maybe it makes sense to rename the "print settings" section to something else, like "export" or "intermediary"? And similarly the conf keys?
2. As the "print settings" profile should be a well-behaved intermediary profile (preferably one with a matrix, not a CLUT), there is an argument for removing printer profiles from this list. Though how do we distinguish? DT_COLORSPACES_PROFILE_TYPE_WORK and DT_COLORSPACES_PROFILE_TYPE_EXPORT could both be vailid, and the printer profiles are in the latter group.
3. I haven't looked at the Turboprint path -- it may be totally different!
4. One more thing, perhaps, which alas just slipped my mind...

This PR is to add a 3rd choice, Rec 2020 linear, which is the default working profile (between colorin and colorout).

Again I may be wrong, but as far as I know it is better to export the picture to a profile for with the printer profile has been created. Most (all?) printer profile are done based on AdobeRGB and so that's the best choice when printing. I don't know what Rec2020 could do here. That's tricky stuff and I'm really not sure of the whole implication of this.

I think you're right -- I hadn't thought of this. Or at least: If the printer profile allows perceptual intent, I think that the perceptual transformation is predicated on the input profile being either sRGB or Adobe RGB (maybe sRGB?). I'm getting this from the Argyll docs:

When you intend to create a "general use" profile, it can be a good technique to specify the source gamut as the opposite type of profile to that being created, i.e. if a printer profile is being created, specify a display profile (e.g. sRGB) as the source gamut. ... Note that specifying a very large gamut colorspace as the source gamut (i.e. ProPhoto etc.) is probably NOT what you want to do, since unless the source images have a similar very large gamut to that of the colorspace, they will end up getting over compressed and come out looking dull. Instead use a source profile that has a gamut more representative of the images gamut, or you should provide a gamut using the the -g parameter.

(see https://www.argyllcms.com/doc/Scenarios.html#PP5)

So if the user is using relative colorimetric intent from their printer profile, the "print settings" profile can be any sensible profile, such as the working profile. But if the user sets perceptual intent, the "print settings" profile should be a smaller gamut profile such as sRGB (or Adobe RGB?).

Furthermore -- as the export is in 16 bit color and not float, out-of-gamut colors will be clipped. Hence the user should probably either:

• use a sufficiently wide gamut "print settings" profile, a relative colorimetric intent for both export and transformation to print profile, and make sure that the image is in the printer gamut
• use a smaller gamut "print settings" profile such as sRGB with perceptual intent, and perceptual intent for the printer profile, and rely on LCMS to fudge the color numbers

So I think it's OK to offer a wider gamut profile such as Rec.2020 for "print settings", (but ideally one with a non-linear tonal response curve) but only in the case that the user uses relative colorimetric the whole way through and takes responsibility for not clipping colors -- but gains the benefit of more control of how the colors will be printed.

[github-actions[bot]]

This pull request did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[aurelienpierre]

Would it be better (or an addition improvement) to allow for export to "working profile"?

You can't output to linear RGB in integer-encoded files, so this will need to be limited to float exports. Then I don't follow what the benefit is supposed to be for printing. Inkjet printers have a gamut smaller than sRGB, and only photochemical laser prints slightly exceed Adobe RGB in some parts.

So long as colorspace conversions to sRGB and Adobe RGB are unbounded and the conversion isn't perceptual, does the gamut of the export colorspace matter?

The ICC pipeline expects bounded signals because it deals with bounded media in and out. Unbounded stuff is meant as a working material to be further processed in another software.

Why not just export directly to the printer profile, so that the ensuing conversion to printer profile is a no-op (assuming that conversion is relative colorimetric)?

That's complicated. Printers drivers may have black magic in their ICC profiles, like perceptual LUTs in the A_to_B and B_to_A tags that may do a better job at gamut mapping from sRGB or Adobe RGB to printer RGB. But since that's black magic, it may also be a good idea to do everything at export for the sake of predictability.

I think both options should be offered. Filmic v6 does the gamut mapping to export space at constant hue and luminance. It got a preference since v4 or v5 to perform the black point compensation, which is read from ICC profile and translated to the display black point of the filmic curve. Only the ICC reading part is not coded yet. (Side note : this is the number 1 reason to not merge the sigmoid thing, no black point compensation can be inserted there since there is no display black point in the algo).

Would exporting to Lab (the current input colorspace of colorout) be sensible, if colorout is the last iop in the pixelpipe? Or is the ideal that eventually colorout will take input in the working profile?

The Lab export is an hidden feature for debugging purposes only. Most CMS don't know how to read Lab.

[HSUfineprint]

I don't get the point of the request either, because I didn't use darktable to print. But some points of view could be complemented.

Inkjet printers have a gamut smaller than sRGB, and only photochemical laser prints slightly exceed Adobe RGB in some parts.

Many fine art or photo printers have much wider gamut than RA-4 prints, such as Epson SC-P and Canon iPF PRO printers. Printing on a good quality paper, you can get a color gamut bigger than sRGB. For example, Canson Infinity Baryta Prestige printed by Epson P9000, the gamut volume would be around 1,000,000. That's definitely lager than sRGB. The gamut expends beyond AdobeRGB in light yellow/orange and dark blue/green.

The Lab export is an hidden feature for debugging purposes only. Most CMS don't know how to read Lab.

We are talking about output profile. Most of them use Lab PCS, so most CMS for printing can read Lab data.

[TurboGit]

@dtorop : Looks like it could be closed at this stage, ok by you?

[github-actions[bot]]

This pull request did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please verify it has no conflicts with the master branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

[dtorop]

@dtorop : Looks like it could be closed at this stage, ok by you?

Yes, closing! But I appreciate the discussion.

Apologies for being slow on this -- was overwhelmed by day job work.

I do think there's still some more work to do on print profile settings, to clarify how to use them, and maybe to avoid clipping. If I can come up with an example of the latter, I'll use that as an incentive for more work.