Which color space is passed on to the printer

I organize the printout from Photolab managed by the printer. I can specify the desired color space in the printer driver. Does Photolab convert the RAW from wide gamut to the desired color space and then pass it on to the printer management? That would be correct. However, I have not found a specific reference in the documentation.

As usual with printing you have 2 options,

color management done by the application
(the application / your input concerning the paper profile … takes care for cm)
Screen Shot 05-31-24 at 05.10 PM


by the printer
(your printer driver setting is responible for cm)
Screen Shot 05-31-24 at 05.11 PM
PhotoLab delivers the colors as they were determined by you, but does NOT convert them.
I’d recommend to convert the file in PL (and use Soft Proofing), before you send it to the printer.

1 Like

OK, there are this two options. I meant something else.
When a photo with the color space of the camera is read into Photolab, the photo is imported into the internal color space Wide Gamut and further processed in this color space within Photolab. As soon as the photo needs to be exported, a color space must be assigned to the exported file (sRGB, AdobeRGB, etc.). Photolab then maps the wide gamut range to the color space to be exported. That’s how I understood it.
My question is how the whole thing works with printing if the printer driver takes over the management, i.e. the second case in your post. The printer drivers do not understand what a wide gamut is. So there has to be a mapping to a color space supported by the printer, which only Photolab can do. I would like to know how this works. I use PrintFab as a printer driver - highly recommended, by the way - with Epson printers. Here I can set the desired (required) color space for the printer. I imagine that Photolab receives this setting from the printer driver and adjusts the color space for transfer to the printer driver accordingly.

As I said, there are 2 options

  • either color management in the app (and you need to disable color management in the printer driver to avoid double profiling!!)

  • or color management in the printer driver (and your app is NOT involved).

So let’s talk about the 2nd case.

When you send a tiff-file, say in Display P3 color space, from PL to your printer and let the printer handle the color management, the app PL is NO MORE involved. The printer driver provides the necessary tone mapping. In order for this to work properly, you have various settings to choose from … input profile, rendering intent, printer profile … easily susceptible to application errors.

Screen Shot 06-01-24 at 08.48 PM

Then, when the printer driver doesn’t have a decent preview / soft proof, you’re literally “flying blind” (well, relying on autopilot). However, you will need to print your image to see if the colors look as desired.
What works for snapshots, where you don’t invest any time and on smaller paper sizes, will most likely not satisfy you when printing at a reasonable size. Then it’s better to at least use soft proofing in PL, but also convert your image accordingly before sending it to the printer.

Now, let’s say you don’t bother exporting your image as a TIF file, but you want to send a raw PL file to your printer. – If you haven’t done any soft proofing yet, then too, you don’t know whether the colors of your image fit into the target color space of your print.
As the raw file has no color space (the AdobeRGB or sRGB camera setting is primarily intended for an OOC JPG file), I’m assuming PL passes on the “DxO Wide Gamut” designation to the printer …

I don’t know PrintFab and can’t say anything about it. According to their website, it should act as a RIP.

Personally, I leave the color management to the application and use PS in combination with the printer driver (softproof, custom paper profiles / presets), to create an image version specifically for the respective printing paper.

The raw file isn’t send to the printer. It’s the in-memory RGB file with all its edits done or the embedded JPG file if you uses just an image browser.
I can’t answer the question in what profile that image is send: wide gamut, the monitors or the soft proof when used.


Yes, that sounds to be a good explanation.

I can’t answer the question in what profile that image is send: wide gamut, the monitors or the soft proof when used.

I lean towards wide gamut. – The color space of the monitor determines what the user sees, while the soft proof is just a screen simulation, a preview of the later printed output.

It’s slowly becoming clearer. I also read through Wolf Hauser’s article on wide gamut again. That also makes things clearer. RAW files are supplied by the camera with 12, 14, 16 bits (perhaps even more in the future). Photolab processes optical corrections and noise reduction in this environment. In the past, further (color) processing was done in AdobeRGB gamut. With the introduction of DXO Wide Gamut, this color space has been expanded or redefined. If I have understood this correctly, it is about the best display compromise for the professional image editing process. This data must then be mapped to the desired printer. There are probably very expensive printing machines that can print the DXO Wide Gamut directly, for affordable printers this information must be mapped to the printer’s capabilities. The mapping is done by the RIP software, whether it is built into the driver and/or firmware of the printer or printing machine. In this case, the RIP software alone is decisive for the quality of the printout. A necessary ICC profile can be read in directly for option 1 via Photolab, in option 2 with external printer management from the configurable RIP driver. In this respect, this is now consistent for me. For now, thank you for your thoughts and further suggestions.

The best working gamut is the output gamut. No conversion has to be done. But for the program doesn’t know what your output will be, a wide gamut is used. One can convert that to a smaller gamut, but not the other way. There’s no quality issue involved.

Every output device has its own gamut. So has a printer. When the program sends the image to an output device it’s using a “Profile Connection Space” to convert it to the output gamut. So also to the printer. I don’t know what happens when it is said let the printer driver do the conversion. If I’ve softproof on and use a ICC profile that only prints B/W it doesn’t matter whether I choose PL or the printer to do the conversion.
See https://www.color.org/profile.xalter for the Profile Color Space.


I didn’t know what RIP software meant so I looked up. It does a conversion from a vector based image to a raster based image. PL is raster based.


My assumptions regarding RIP software are based on this information Raster image processor.


I took a couple of screenshots with my Eizo CG2730 and set it up to sRGB, so they are easily to follow on a sRGB capable screen. The red overlay shows the affected colors, when choosing a target with a small(er) color space.

For better comparison the paper & ink simulation is not activated, while in reality

  • #3 looks a bit dark and cold blueish due to optical brigtheners (OBA). I use it for quick and easy prints.
  • #4 (kind of semigloss surface) looks neutral and vivid with high contrast. With this paper I actually hardly need a soft proof (screen then set to Native or AdobeRGB).
  • #5, which is a matte paper, cannot reproduce deep black. Even if there seems to be a bit of a lack of contrast at first glance, it makes up for it with great colors and no annoying reflections. It is my favorite for black and white reproduction due to its natural warm paper tone.
  1. reference image – color corrected with DxO’s calibration tool

  2. softproof for sRGB IEC61966-2.1

  3. softproof for my Epson printer SC P800
    with Epson’s canned profile for Epson Premium Luster paper

  4. softproof with custom profile for Canson Platine Fibre Rag (PFR 310)

  5. softproof with custom profile for Tecco Premium Cotton Rag (PCR 310)

So that happens with the output (color space).

It’s creating a raster image from a vector image. No color gamut involved.


I think he asks when using the printer driver.


I just found out that the color space in the soft proof is used, irrelevant if SP is on or off. Same result for SP is on or off and with managed by PL or printer. I think the only difference is that when you select managed by PL you can overrule the output color device in SP.
I doubt if the printer driver is doing any color management.


This discussion has nicely illuminated the uncertainties and user-unfriendly aspects of allowing printers to manage colors. Why choose this option? I see in the PrintFab manual the recommendation is to allow applications to manage colors. PS and PE are named as photo editing examples and the general message is clear. That would be my recommendation for PL as well.

The current PL print module is anemic, but it does work as advertised. If you choose to print directly from PL, allow PL to manage colors. Assuming you are starting with a RAW file, I would take the extra step of exporting (to the original image folder) a full-size 16 bit TIFF with an embedded actual ICC color profile. Send the exported TIFF to the printer. This extra step will reduce or eliminate any color mismatches or ambiguities that may exist in the file metadata. After printing, you can always delete the TIFF if storage is an issue.

I’ve only ever tried to print from PL once. The print was rubbish. This was in stark contrast to the print of the same image I’d done moments before using an ancient version of Photoshop, it was fine.

Everyone I know who prints follows a simple rule:

If you are printing a colour image, let the application manage the colours BUT if you are printing B&W, let the printer manage the colours.

In my experience there’s a reason this rule exists. It works.

to quickly reiterate … one has 2 possibilities,

  1. color management in the application, e.g. PL
    – and in this case PL’s “print modul” is noticing you to switch OFF color management in the print driver (very important to avoid double profiling with unpredictable colors) –
    while the print job itself is passed over to the print driver
  2. color management in the print driver
    – the application , e.g.PL, is NO more involved in color management –
    and passes the whole job to the printer driver (color management and printing).
    [ as @eriepa explained … not recommended ! ]

about Soft Proofing
SP itself is nothing more than a simulation/preview of what you will see, well, most likely. Of course, SP is not able to simulate the texture of the paper such as glossy, matte or in between, but it does indicate whether and what colors the printer/ink/media combination will produce (if the monitor is capable of it) together with the color of the paper (cool, neutral, warm).

That information is stored in a specific ICC profile,

  • which is contained in the print driver and automatically used, when the customer chooses the printer’s own brand paper
  • the customer uses a canned (prefabricated) paper profile from a third party paper manufacturer and chooses the relevant media settings, that third party paper profile is built on
  • the customer uses an individual paper profile … …

But SP does NOT change the image. This is what you do yourself, if you want / need to adjust something – while there is an “exception” …

IF you SP

  • with a matrix profile (sRGB, … ) incl. Preserve color details → Intensity
  • with a paper profile (no paper tone & ink)

and select to export like
Screen Shot 06-03-24 at 06.30 PM
the above settings are applied during export. → Suppose that’s what you noticed. ←

Still, I don’t like exporting while applying a printer profile. – I leave color management to the application (where I choose the paper profile and rendering intent) and print from the printer driver (with custom presets to reduce errors).

I did the same test again and now I get different results. I don’t know why.
I still wonder who is responsible for color management during printing when selecting printer driver. From what I understood now it’s the operating system. It’s an extra layer between the program and the printer. The printer driver is taking care that the input is translated in a way that the printer can print. Color management is changing that input first and send it then to the printer driver.

With SP on the image shown in the printing windows of PL is the image converted to the used icc profile when using “managed by PL”, when using “managed by the printerdriver” I don’t know what is used.

I don’t print. I’ve it printed.


Oh dear, I didn’t think I would do so much research at first. I had completely ignored the concept of the Profile Connection Spache, but then I started searching. I currently imagine the following:

The Profile Connection Space (PCS) is the superordinate reference that contains all colors that can be perceived by humans. It is standardized as CIE (LAB (Lab*) or XYZ).

The ICC profile describes the mapping from a color space to the PCS (source mapping) or from the PCS to a color space (target mapping). Tables for an interpolation and/or parameter series for a transformation can be used for the description.

If image information is to leave Photolab (saving an image file or printing the image), the Photolab wide gamut and the required/desired target color space must be calculated via the PCS.

Photolab provides an “internal” ICC for this purpose, which describes the mapping from the wide gamut to the PCS.

In addition, the printer interface is provided with the ICC that describes the mapping from the PCS to the printer. This ICC is determined with appropriate measurements for each output device and depends on various properties - paper type, ink, printer series, signs of ageing, etc. and is registered in the user interface by the Photolab user.

The software that processes the print output then does the following: Analyzing the source and target color spaces using the mapping information from both ICC profiles and then (in the vast majority of cases) calculating one defined mapping table(s). This mapping table(s) then allow both color spaces to be mapped to each other without multiple rounding errors.

This means that no conversion of image information from the source to the PCS and from there to the target is carried out, but the PCS is only used as a reference for the calculation algorithms from the source to the target.

This brings me back to my initial question: Who performs the conversion for the printout and what happens when files are saved?

I still assume that the corresponding printer driver of the printer manufacturer or another RIP software takes over this conversion task before printing. Photolab only provides the image information and the “internal” ICC at this interface.

Photolab performs the conversion when a file is saved. This is where two ICC profiles come into play: the “internal” one for mapping from wide gamut to PCS and the device-independent ICC profile from PCS to TIFF and JPG.
I’ll leave DNG out of the equation here, that’s certainly a topic in its own right.

The device-specific ICC profile, which is embedded to the target file, is then needed again when printing out the file to the target device.

I don’t think the printer driver itself is doing any color management. It let the OS do it.