Oh, thanks for the advice but I have used the Epson Semi Gloss-profile in most of my tests since I have printed with some small 15x18 papers. You can set that both in Photolab or in the printerdriver if printing with ICM instead of letting Photolab rule. This is NOT about this variable at all despite that it happens to be handled too.
Since most people never have heard of ICM they usually don’t know the difference in how it works compared letting Photolab rule. With ICM (non-hard configured in the driver by - Advanced) ICM uses the ICC in the files instead of letting the monitor config rule as in Photolab normally and it handles these profiles completely automatic That’s why the only way for me to really print in ProPhoto has been through ICM. You see if I can´t configure my monitor to support ProPhoto, the normal Print-function will not be able to print ProPhoto. Photolab can just export files with ProPhoto ICC but not print them. In order to compare what really comes out when printing I have printed both from Photolab with standard settings and by letting “Managed by Printer” + ICM in the driver rule. The last setting is the only one working that consequently prints using the embedded ICC in the files regardless of if it contains a flag for sRGB. Adobe RGB, ProPhoto or P3.
The reason I have used the files I have is that they just serve as indicators that very easy informs me of what has been printed. That’s why I have not used any real “test images” we use when analysing “HOW” these different gamuts are printed by our printers. So it´s not at all about “HOW” it´s printed or if the print is in sync with the monitor after a softproof but ONLY about how the ICC-profiles are read or not and about what really is affecting these workflows. I had to start there since I happened to see what happened when switching between my own three calibrated monitor settings for sRGB, Adobe RGB and P3. I don’t like at all how Photolab is handling this but at least I now have the knowledge to live with it. I wonder how many others that really have that.
This is a rather rich coming from someone who has himself conveniently ignored directed documentation and advice that the DxO PL print module works as advertised. Your approach is a kluge attempting to address an unspecified problem in your setup or workflow. Interesting, but unnecessary.
If this is, in fact, how PhotoLab color management behaves on Windows, it’s a serious problem. But I run on macOS and have no experience with Windows.
As others have said, output ICC profiles are meant to describe the output device’s color abilities. So sRGB might be best for a monitor, but is far from the best for a printer.
I have, as do many, ICC profiles specific to my printer (inks) and paper. When I print from PhotoLab, I have PhotoLab do the color management (ColorSync for Mac) using the proper print output ICC profile. In the world of Mac, that’s color management 101.
Hello Stenis,
You’re right, of course, that we’re actually talking about a different topic here, but as is so often the case, we’re digressing again and I just joined in.
AP is actually a classic pixel editor and the import of RAW files has always been possible. In version 2 you have the possibility to call up the raw file again in AP Develop Persona after importing it, to edit it differently and still not lose the masks, layers etc.
This apparently complicated system is how digital colors are “professionnaly” managed now.
This is the only way to get consistent colors on any possible pipeline/workflow which can imply one or several actors.
To be able to apply a profile to a body, photolab has to “decode” the raw file of this body (this needs reverse engeenering to understand the code) and then apply a profile.
If the body has not been tested (no valid DxO profile), its raw file is unknow by photolab and so it’s impossible to decode and then it’s impossible to apply a camera profile to it.
" Fortunately this is not true, or let’s say that’s not how it is supposed to be. "
Checked with PL6’s print modul
two test files (AdobeRGB + ProPhoto)
monitor was set to sRGB, 5900K
changed monitor to native, 6500K (= combined AdobeRGB + P3)
restarted PL6 to register the different colour space
exported both test files in PL6 to sRGB (w/o any colour correction to ensure full saturation)
monitor was still set to native, 6500K
the prints from 1. + 2. are absolutely identical
the print from 3. shows some clearly visible flatter colours in comparison to 1. + 2.
I cannot confirm your conclusion, that the active monitor profile would effect the embedded ICC profile when printing.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
99
@JoPoV
I have no problems with my workflows in general and have printed since 2005-2006 with Epson printers. So what I write is not at all about that I’m having any problems to get proper prints that matches very well with what I see on the screen regardless if I print in Adobe RGB or P3 or in sRGB. I know how soofproof works very well and have no problem adjusting what I see on the screen processing my images without Softproof active with the Softproof preview with the ICC for the paper I normally print on (Canson Infinity Etching Rag) and that ICC-profile is excellent. So that isn´t any part of this problem at all so just let that go.
This is really about how different applications handles ICC-profiles and in particular how Photolab seems to handle the profiles in the files in my present system.
… and we also have to be able to separate the handling of the ICC-profile info embedded in EXIF from the ICC-profiles we use to compensate for the characteristics of our printing paper. Even that is no problem regardless if Color Management is “Managed by Photolab” or Managed by printer and ICM activated.
Maybe I have to remind you that an ICC-profile aware application like XnView sees these files in the proper way using the embedded profiles to display these images and what you see here is not what comes out of Photolab when set to “Managed by DXO Photolab” in my world.
and here below is how these images looks in Epsons printing application Epson Print Layout on the screen and for me it seems identical with what I see in XnView.
So these problems I have experienced with Photolab have mostly to do with the ICC-info embedded in the files… This ICC-info has originally in my testfiles been applied when exporting these JPEG-files from Photolab and the profiles I have used are the ones available in Photolabs Export-module. It is the same image that just have been exported with different ICC and is neutral and unprocessed just exported with different profiles.
And when I print them with Photolab and “Managed by Printer” on plus ICM activated in the driver the very same images will come out almost exactly as they were displayed both in XnView and Epson Print Layout and for me they look very different to what is printed with Photolab in “Managed by Photolab” mode. From left to right: Adobe RGB, Display P3, ProPhoto and sRGB and the lower row is printed with ICM on and Photolab in “Managed by Printer” mode.
So when Windows Color Management handles the colors they look the same in both these two applications and when printing with ICM from Photolab. When I look at how the same images looks on my screen in Photolab regardless which mode I´m in they don´t look at all like they do in the other applications. The images in the lower ICM-printed row has more blue in them compared to the others. The two images to the right are affected with reflexes a little. They are more red then they are displayed with here.
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
100
No not at all because this is not at all anything about decoding bla bla…
You are talking about what DXO might do when building a profile. I´m talking about that once they have let me in with my files I am totally free to apply any Canon, Fuji or Nikon profiles made for all these cameras by DXO to any of my Sony ARW. So it is absolutely nonsens all this since I´m totally free to apply any of all these profiles to any of my Sony-files. Why don´t they just skip this nonsense blocking me from adding for example an A1 profile instead of the one lacking for A7 IV when that was new. If they had let me in without any profile I could have picked another of my liking whether that should be another Sony profile or not or if I rather would prefer a Canon R5-profile of artistic reasons or so.
Didn´t you watch the video around 7:30 minutes or so? There they say exactly what I say here. Pick a profile of your liking if you don´t like the rendering your camera profile gives you. In this case DXO looks upon all these profiles as they do on any Filmpack preset that even them affects the image rendering. This is not anything I´m interested in really but it would have been handy when I was waiting 6 months for DXO to make a profile for my then new A7 IV. Instead I had to batch update and replace the model code in my A7 IV-files with the code from the predecessor A7 III. Why shall we need to bother with that when we just could have picked the A7 III profile or the A1 profile from the Rendering-list in Photolab and use these ones as a temporary replacement. … and believe me, I just could not see any difference at all from the A7 IV-files with the proper DXO profile. So why continuing with this nonsense.
you were waiting for DxO to officially support this camera model and release the version with said support in it to the public, building a camera profile ( or several actually ) is just a part of what is done …
How a specific sensor model (including filters used) reacts to different wavelengths of light. Much in the same way different films were known for their colour reproduction, or indeed some black and white films reacted differently to others.
JPGs are saved with photolab in 4 different color spaces with embeded color profile. So those images should not contain any color out of their embeded color profile since photolab should convert them in their respective color profile when saving.
on screen those 4 jpgs with embeded color profile look the same when viewed with XnView and epson application (which are color managed) but not with photolab.
→ Do color differences happen with out of screen gamut colors or with in screen gamut colors ? (second case could mean photolab color management is a complete failure).
when printed from photolab with color managed by printer, prints look the same as when viewed in XnView and epson application.
when printed from photolab with color managed by photolab they don’t look the same as when printed with color managed by printer.
→ Do in this case they look the same as when viewed in photolab ?
So you’re talking about loading RAW files in photolab (can’t apply camera profiles on demosaiced images).
I think they need to build a camera profile to be able to read the raw file and then apply any other profile.
A little bit like changing an image color space needs a starting color space for this image to convert it in a target color space.
If the image has no color space, no way to convert it. You only can randomly apply a color space to it and hope it is the right one. But you’ll never know if the result is what was expected.
More than that, Raw format beeing manufacturer specific, and often camera specific, DxO has to do reverse engeenering to be able to read a raw file.
I think before testing camera (and so creating profile) photolab can’t read the raw file at all.
Because it would at best mean convert RAW to pixel image assigning “random” colors, and at worst being unable to read the raw file at all.
I think they need to run the testing process to know what to do with new camera raw files.
I think that to pick an other profile, photolab needs to know base camera profile first to do a conversion.
If you could apply any profile on any not profiled camera and get right result, wouldn’t that mean that every sensor provide the same raw datas (even if RAW file is written in memory with different ways of coding) ? If so why need to profile camera for color rendering ?
I think your case is specific because RAWs of both cameras are similar.
But I think DxO needs to run the testing process to be sure about that. They can’t predict what camera manufacturers will do with any new camera.
And I don’t think listening to users who pretend a hack works can lead to DxO do something without having very scientifically verified it (and so run the camera testing process).
So those 2 raws are very similar, but I think DxO can’t bet about what contains a raw format of a new camera but must scientifically test it to know.
It’s the same process as when a NEW os appears :
It takes time for this os and drivers to be really ok. Then it takes times for softwares to fully use this.
DxO makes more work than other demosaicer makers to profile cameras and lenses, so they are the last to provide new cameras integration in their software. But those tests are why you like photolab, isn’t it ?
1 Like
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
105
I would be as fine with the A7 III profile or even with a profile for the 10 year old NEX 7 if I just got in at that time but DXO will not let anyone in without a matching profile. That´s why I used to batch update my A7 IV to AIII with a Hex Editor and a macrorecorder.
The A7 IV-profile was absolutely not crucial at all for me to develop a RAW properly and as we have seen in that video above DXO themselves in this video is recommending using the profiles of other cameras to gain artistic effects!!! It sounded almost as they used them like ordinary presets. It´s not more holy than that!
It´s just another rendering bias and a slightly different starting point but it is the lens profiles that are the really important ones and not the camera profiles.
I think Photoshop was poorly named and have never understood why people compare it with the likes of ON1, PhotoLab, Capture One etc. They wouldn’t compare it with Lightroom!..
Is this a feature or a bug ?
No way to control this behavior ?
Is a color conversion done, or do colors go wrong when printing wit diffrent embeded profile than monitor set color space ?
@Stenis is using a hardware calibrated monitor and when changing the monitor profile within Windows Color System (WCS) instead from the monitor hardware (or with the dedicated profile loader) most probably leads to trouble …
The current monitor profile, which is shown in WCS, is ‘read’ by all color managed apps.
Changing the profile at the monitor side – let’s say from AdobeRGB to sRGB – sets the monitor to those new values (= stored in the monitor) and forwards the change of the ICC profile to the WCS, so that the apps then get to know, “the monitor is in sRGB mode” – in some cases on the fly, otherwise after restarting the app.
. The other way round doesn’t work. Simply changing the ICC profile in WCS does not trigger the hardware calibrated monitor. As a result the WCS communicates e.g. “sRGB” as system profile, but the monitor is still on “AdobeRGB” … then showing “wrong” colors – and easily to avoid.
As I wrote:
When I calibrated my monitor, I did it in this order: sRGB, Adobe RGB and Display P3 (Display P3 is a tweak of DCI-P3 where a few parameters are set as for sRGB.
What happens in that Benq’s own calibration program Palette Master Element always updates Windows monitor ICM-file to correspond with the gamut of the monitor and that´s fine so far.
The problems occur when I switch between these three calibrations of the monitor that are stored inside the monitor’s so called LUT (Look Up Table). So, remember, P3 was the last calibration and then the ICM in Windows is for P3 too and that doesn´t change when I switch between the monitors profiles. So as Wolfgang writes all legacy applications that relies on that Windows ICM gets the wrong info and the colors gets rendered incorrectly by this.
There is no problem now for me when I know this. In order to just have one single calibration for both monitors and prints, I have decided to stop using Adobe RGB and sRGB at all. I now use P3 for all in order to get a possibility to standardise on just one ICC-type and that will cause too saturated images on sRGB-monitors, but a lot of displays are now using P3 (Apple monitors and phones) (or any other wider gamut like in Android and some TV-monitors as well that use REC.2020 for example), so there will always be unsatisfied viewers of my images on the net anyway - I just have to choose whom. Slowly?, sRGB is on its way out and quite a few new gamuts will compete about ho the new world will look on peoples monitors and phone displays.
So finally, when it comes now to handle a configurable application like XnView, it now works as it should, since I have changed its configuration to use Windows P3-ICM instead as default using the ICC inside the image files. There are other problems though that are application related because some of them defaults to sRGB and can´t be configured, others are not color managed at all. I now also save my JPEG-files consistently with just P3 from Photolab.
In fact, my printing in P3 looks really good too when printing using Canson Infinity Etching Rag-paper and Canson’s ICC for my Epson P900. When Adobe RGB is heavy on green and blue P3 is leaning more to red and it has been created because it better resembles what humans can see with their eyes.
I have learned even from rekommendations I have read at home here that it seems to be a common idea among quite a few photographers to set their cameras to save JPEG-files with Adobe RGB-ICC and since most images will be viewed on anything else than Adobe RGB, that never have been intended for use on the monitors in general out there on the net. Just for printing Adobe RGB makes sense. So, saving images by default in Adobe RGB might not be an all that good solution. For most people it would make more sense to save in sRGB or maybe P3 is you live more of your time in the Apple-sphere.
it is an old program - if you have more or less new BenQ monitor ( SW240, SW270C, SW271C, SW272U, SW272Q, SW321C ) then you want to use PMU, not PME
Stenis
(Sten-Åke Sändh (Sony, Win 11, PL 6, CO 16, PM Plus 6, XnView))
111
I know but I can´t use the newer program. I have tried. We will see if Benq will fix that error. They ought to. Maybe this is low prio too since the monitor works fine with my converters. This is a problem for legacy applications relying on Windows ICM. Maybe they think the app developers have to adapt to the new realities - which they ought to too.
I think my modelcode was SW270B when I checked.
This is not a problem of high prio for me since it works för Photolab, XnView, Capture One and PhotoMechanic and my printing. That´s all I care about really in my everyday photo related usage of my computer. I have the knowledge now to avoid any of these problems after all the tests I have made. I have no problems now. Version 7 works fine too and I´m just about to upgrade from version 6.
