Color correction with XRITE Passport

[SergioDJ]

Hi,

I've been trying to use the XRITE Color Checker Passport and I'd like to ask for help. I'm not sure if I'm doing this correctly. I saw in another message in this forum the steps to generate the ICC file. So, to verify if the ICC was correct, in my understanding, I can use it in the original picture and I would expect NO changes in the color or anything. It actually squeezed the colors towards the black and the image became darker.

The original image, only with WB corrected is the Pic 1

Then, after the ICC was succesfully generated and loaded in Affinity from that image, when I apply the profile, see the Histogram:

Pic 2

If I develop the picture, it will be darker.

BUT...

if I load the image, after the WB correction, and develop the picture, from Document -> Assign ICC profile, the picture is corrected, but the contrast decreases and it looks washed (picture Pic 3).

So, is it a bug with Affinity? How could I verify the colors are truly corrected? Can I use the RGB values in Info panel to double check the color palete values?

The ICC profile I generated I called it TODELETE.

Thanks!

Sergio

PIC 1:

 

PIC 2:

PIC 3:

Edited July 3, 2020 by SergioDJ

[Dan C]

Hi @SergioDJ,

My apologies for the delayed response here! I can confirm we're currently working to implement X-rite colour management into the Affinity apps, however in the meantime you will need to use the ICC profile route.

Can you please read the below article regarding colour management in Affinity and ensure you have set up your app in this manner?

https://affinityspotlight.com/article/display-colour-management-in-the-affinity-apps/

If you're still having trouble after following this, please do let me know!

[Dan C]

I'm not 100% certain what the devs intentions are, I've forwarded this question to them and will respond here with any information I can

[Dazmondo77]

On 7/10/2020 at 3:34 PM, BofG said:

Dan C are you going the whole hog and giving us CMYK print output with proper support for ICC profiles?

*crosses fingers* please say yes, please say yes, please say yes..

CMYK print output with proper support for ICC profiles?

CMYK end to end NEEEEEEEEEEEEEED!

[Dan C]

My sincerest apologies!

The below is an adapted answer from one of our devs:

Unfortunately this isn't something we plan on changing currently, as it's an OS / printer driver issue.
Affinity apps send profiled data to the macOS printing subsystem - and we have very little control what happens after this point.

We believe Adobe effectively replace the entire printing stack with their own code - however the Apple Developer spec recommends against this and implies that the OS / printer driver will do it all for you.
This means that some users already are able to do this within Affinity, but it relies on the printer & printer driver supporting it.

I hope this clears things up

[Dan C]

11 minutes ago, BofG said:

One further question if I may, when I  have a CMYK document, and in the print dialogue I set a CMYK print profile, what RGB profile does Designer use to convert that prior to sending to the printer? (On Windows btw).

Unfortunately I'm not sure what you mean by this - If you have a CMYK document and print using a CMYK profile then Affinity doesn't convert anything or use an RGB profile at any point, however your printer/driver may be intercepting the document, this I cannot be sure of as it differs from printer to printer.

11 minutes ago, BofG said:

Oh, and a sneaky extra question - do you think it's correct to advertise Designer as having "end to end CMYK" on the sales page when it's not really the case?

Unfortunately I can't provide my opinion here, however this has been raised with our documentation team and they're reviewing this currently.

[Dan C]

@BofG, Just a quick update here - I'm awaiting further response from our developers and QA team as this has sparked a wider investigation into Affinitys printing mechanics.

Once I have some further information, I'll be sure to post it here - rest assured I haven't forgotten to reply here and my apologies for the delay! 

[Dan C]

I've had a response from Adam, one of our Publisher devs, who confirmed the below;

"All of our Windows printing goes through Windows GDI to the driver which only supports RGB. Whether or not the driver can send CMYK data to the printer is irrelevant."

Windows GDI only supports RGB, and I've found an article from Corel where this is explained in further detail - https://www.corel.com/content/pdf/cdgsx5/Color_Management_Guide.pdf

Patrick (Head QA) is also correct. To get true CMYK printing you need to use a Postscript printer/driver but we don't currently support Postscript Passthrough on Windows.

The link provided by the user in the other thread (https://docs.microsoft.com/en-us/windows-hardware/drivers/print/supporting-cmyk-color-space) is related to drivers. So, Adam is saying that if the driver supported CMYK the data it would receive from our app through Windows GDI would still be RGB.

If you export to PDF, a pro printer will be able to print to CMYK. This works by default on macOS because Apple use Postscript for printing and we simply use the OS printing API.

You might also find our Affinity Spotlight article on this interesting - https://affinityspotlight.com/article/designing-for-professional-printing/

I hope this clears things up - as someone relatively uninitiated in printers & drivers this has been an interesting learning experience for me

[DKRooms]

A further ICC profile question:  I have read Mr. Ritson's article and follow it as far as it goes. My remaining question regards printer profiles and where they should be applied. I have profiles (X-Rite Color Checker generated) for the camera, the display and the printer. I am not sure at which point in image processing which profile should be applied. I thought that the camera profile should be applied to the raw file before development, and the printer profile applied as the output profile when the image is printed. This has not produced good results. What have I missed?

Thanks & Best Regards to all.

DK

[Dan C]

Hi @DKRooms,

From the sounds of your setup, you need to have the calibrated x-rite profile set for your monitor, then you would use the printer profile as the ICC profile set within Affinity.

For more information on Colour Management in Affinity apps, please see the below link

https://affinityspotlight.com/article/display-colour-management-in-the-affinity-apps/

[sfriedberg]

I'm going to simplifiy and generalize just a little bit.  ICC profiles are conversions between color spaces.  Mathematically, you can think of a profile as a matrix, and color conversion as matrix multiplication of a point (a 3D or 4D color) by a matrix.  Every camera, every scanner, every printer, every monitor potentially has its own color space.  And generally, an application has an internal color space (possibly configurable!) in which it does all its image processing.  So you need to set up your app with ICC profiles that map from every input device color space to the app internal color space, and ICC profiles that map from the app internal color space to every output device color space.

In a comprehensive color-management system, you don't set one profile. You set specific profiles for each input and each output, and sometimes you can even specify the order in which the conversions are applied.  This matters because the color conversions are "lossy", and you don't always get the same results applying A, then B as when applying B, then A.  Specific example:  In CorelDRAW, you can configure color management so input files are first converted to monitor color space, and then to printer color space.  Or you can convert them first to printer color space, then to monitor color space.  The first situation is when you are primarily targeting RGB output like images for the web, but want the best printer approximation you can get.  The second situation is when you are primarily targeting CMYK output to send to a professional printer, but want the most accurate monitor representation of the printed output.

The input device profiles are always applied when bringing data into the app internal color space.  (Early Adobe apps did some quiet but unexpected "convenience" conversions at this stage, which were the cause of much user hair-shredding and wailing.)  But in a robust color-management system, you can be offered the explicit choice of whether the monitor output converts directly from the app internal space, or the targeted print device color space.

My experience is that trying to make this "automatic" and "user-friendly" just makes the process harder to understand and therefore harder to control.  Apps should make all the profiles and all the color space conversion flows explicit, so the (experienced) user can see precisely what the app is doing.

One issue with Windows GDI is that there is not just one RGB color space.  Wikipedia lists twenty different RGB color spaces.  The ones we are more likely to encounter in non-video, non-laboratory computer apps are sRGB, Adobe RGB, and Apple RGB.  The app internal color space needs to match the GDI input color space correctly, if the GDI's internal CMYK conversion is to end up with the correct results.  The Windows GDI documentation talks about 3 different RGB color spaces, but the docs actually mean three different per-pixel RGB bit widths, which is not at all the same thing as a color space definition!

[DKRooms]

Thanks to all for your input. I am using a windows 10. I have considerable experience using ICC profiles in color proofing set ups for commercial printing.  Most of these proofing software systems use two profiles, 1) that of the proofing device (Inkjet or digital device) and 2) that of the printing press; making the proofing device match the press' color space.

My question here is more to do with Affinity and where which profiles should be applied. My aim is to produce inkjet prints and not digital files. So far, this is what I think I understand from Mr. Friedberg; 1) the camera / lens profile should be applied in Affinity prior to developing the image. 2) the monitor profile is set internally at the OS or graphic board level, so the monitor will display according to its calibration (to match the printer, presumably). 3) The output profile (the printer's) is applied in the when the file is printed, the camera profile being the document profile and the printer profile, the output profile. Is that right?  Could the output profile (the printer's) be applied to the raw file prior to development in Affinity? My thought is that then the monitor would display the color space of the printing device. Make sense?

Once again, thank you all - DK Rooms

[sfriedberg]

2 hours ago, DKRooms said:

Could the output profile (the printer's) be applied to the raw file prior to development in Affinity?

No.  You must apply the camera profile before the printer profile.

The printer profile converts from "standard" color space to the printer-specific CMYK color space.  The undeveloped raw file is not in "standard" color space.  It is in camera-specific color space.  You must do the conversions in this order:  camera => standard => printer.  If you apply the printer color space conversion directly to the undeveloped raw file, you will not get the correct results.  Color space conversions, considered as mathematical operations, are not commutative.  Applying A, then B, does not give the same results as applying B, then A.

[R C-R]

2 hours ago, BofG said:

You've not said what colour space your printer profile is - the reason I asked is because Affinity DOES NOT WORK with CMYK profiles.

From what @Dan C said earlier in this topic, it works only in the Mac Affinity apps, & only if the installed printer-specific software supports it ... which I think basically means a Postscript driver & the related support files (PPD's & such) must be present on the Mac.

The sales copy definitely should indicate this in some way.

[R C-R]

39 minutes ago, BofG said:

@R C-R it's not worded too clearly, but unfortunately it's the same on MacOS as Windows - you have to go via a PDF and print from elsewhere (albeit on MacOS you seemingly don't need any further software installed).

As I understand it, that is not true on Macs. All that is required is that the appropriate printer-specific software is properly installed (typically in /Library/Printers) & that it is a Postscript printer. So basically what happens is the Affinity app sends the print job to the macOS printing API, & since that is Postscript based to begin with, the OS does the rest, the same as if it was converted to PDF & printed via another method.

I believe this is what Dan meant when he wrote that some users already are able to do this within Affinity, those being Mac users who have a printer that supports Postscript printing (typically much more expensive than those that don't) & the correct software installed.

I do not have such a printer so I cannot test this but perhaps another Mac user does & will let us know if that works....

[Dan C]

4 minutes ago, BofG said:

It's funny how the marketing department see how end-to-end CMYK and proper ICC support is important, but the software doesn't have it (on Windows at least) and maybe has it on MacOS but no one really knows

As far as I understand it, the marketing material is written in this way as producing a PDF that's ready for professional printing is counted as the 'end' of editing the file, therefore 'end-to-end CMYK support' is something that all apps can handle, regardless of OS, printer, driver support etc.

As previously mentioned, I have raised this directly with our marketing departments, and our developers, and they are happy with this wording in the above context - without wanting to 'override' that decision, I do personally feel as though this could be a little clearer in the marketing copy, as many users expect printing directly from the app to be the 'end' of the process and this is something that I have noted with these teams.

[v_kyr]

On Win systems in order to get good results for printing images etc., with taking into account own custom profiles, QImage always did a pleasing job.

[R C-R]

5 hours ago, BofG said:

@R C-R I've seen people with MacOS say both that they can get CMYK and the opposite. Problem is that drivers are good at mapping cmyk primaries, so just printing those four blocks usually works out. More complex mixes are where it falls apart, and people testing it are trying to judge by eye.

Since on Macs the Affinity apps hand off printing to the built-in OS level, Postscript-based print service, it is really all about how that service works.

Postscript is a programming language; a Postscript document is a program that runs on a system capable of executing that language.

So as I understand it, the printing service first determines if the printer itself can run the program, I think by searching for an appropriate PPD installed on the system but there may be considerably more to it than that. If the service determines that the printer can do that then the document is sent to the printer as a program & the printer handles the mapping internally. If not, then the print service runs the program, does the mapping, & the output of that is sent to the printer.

Obviously, this is just a hugely oversimplified version of a very complex process that I understand very little of, but I think I got the basic idea right, if not the details or the correct terminology.