So 1 pixel is 3x16 = 48 bit. One block is addressed leaving 1 peace of 16 bit,1 word, left for other use like alpha channel.
Certainly, some interesting tools but isn´t that program moving away from being a RAW-converter (if it ever was - excuse my ignorance). AP seems to me to be more of a designer tool than a regular converter and when he talks of ânon destruktive RAW-handlingâ as something new we know the most common converters all have had that for quite some time.
This tread is more focused on âcolor managementâ, âcolor renderingâ and âsoft proofingâ and the pretty complicated system for that we now have in Photolab that we all now have to learn how to handle with the color spaces we choose to use.
Affinity Photo is a Photoshop equivalent. It can process RAW images (and has been able to since the beginning I think) but that is one of many capabilities it has.
A friend coined the term âdigital darkroomâ to describe applications like Lightroom and PhotoLab. Neither Affinity Photo nor Photoshop are digital darkrooms.
Personally, 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!
I think this video in the threads initial post is very good in many ways as it really explains how complex this Color Management System has become in version 6.8 as we now might use, even it it for sure doesn´t cover it all.
Working Color Spaces, Color Rendering adds to the complexity when developing our images but also gives some more possibilities and Soft Proofing adds more control than before for people who like to have better control than before when printing. We have for sure got a whole bunch of very useful tools to fine tune our prints BUT still I think it leaves quite a few questions I have unanswered really.
When it comes to developing images we also have more options than before to export in several more gamuts than sRGB and Adobe RGB and I have started to test even P3 as a printing gamut. Who finds it useful really to develop images in ProPhoto ⌠in Photolab when at least my new Benq-monitor just manages sRGB, Adobe RGB and P3 that can be useful for me? ⌠and DXO Wide gamut as a âworking color spaceâ is quite smaller than ProPhoto, so how can DXP Wide Gamut really âcoverâ ProPhoto when exporting images out from Photolab??
One of the most important things for me is to have sync between what my monitor displays and what I print. After quite a lot of testing I have also to my great surprise found that it is how I have configured my monitor, that determines what comes out of Photolab âPrintâ. I have found that when my monitor is set in sRGB Photolab Print will print all files in sRGB regardless of the embedded ICC in the files. In that case not just an sRGB-file will print in sRGB but even files with ProPhoto-, P3- or Adobe RGB-ICC profiles too. I have tested this extensively with cases where the monitor has been set to both Adobe RGB and P3. Is the monitor set in P3 every file will be printed in P3 regardless of their embedded ICC-profiles when Print in Photolab is set to âManaged by DXO Photolabâ and the color management is turned off in my printerdriver for Epson P900 as I use.
From what I have seen the only way to get the Print-module in Photolab to print the files in the gamut that the embedded ICC-states are to set Photolab Print-module to âManged by Pinterâ and then set the Color Management in the printer driver to ICM (âImage Color Managementâ, which is Windows color management system.
I also reacted on the video when he talked about the default renderings for Wide Gamut and Classic. When in Wide Gamut mode he said the default was âNeutral Colorâ and in Wide there was only one different possible choice in âGenericâ and that was âDxO camera profileâŚâ for the camera the image was shot in and for me, I must say that feels like my most preferable choice and that goes for both Wide och Classic. DXO puts as high importance in their profiling that they even lock us completely out of using Photolab when using any other profile than the one tailormade for our cameras RAW-file. If there is not a profile for the files from a new camera model in Photolab, PL won´t open them at all.
BUT, watching this video 7:45 into the video, the speaker also point out that you don´t need to care at all about the defaults or even about using this very important camera-profile just developed for just your type of camera. So, a Sony-user like myself might as well use the profiles for a Canon or even a Fuji-body instead!! Why then bother stopping us from opening our files that might not have a valid DXO profile yet when trying to open them when we can use any profile at all present in the application under âCathegoryâ âCamera Bodyâ or any other preset from âFilmpackâ which will also be available as a ârenderingâ?? I just can´t understand the reasons for such severe limitations of Photolabâs usability.
These are the most important things that bothers me with the color managemant for screen and print for the moment. The good thing though is that after starting to use my new monitor and testing how this really works, I have got a lot more knowledge so I know very well now how to handle these problems, but especially one thing is important to know and that is how the monitor setting affects the printing in Photolab´s Print-module. Of that reason I think even Photolab have to get a function that helps us checking the ICC of the files we are about to print in a quick and efficient way - as in Epson Print Layout-printing program, where you just need a âmouse overâ over an image to get the ICC displayed. Today, I think many users don´t have any idea of how the monitor settings might affect their printing. The time when we could expect just sRGB or Adobe RGB in the files are history now. Many people use P3 today for displays and some like me also have substituted Adobe RGB for P3 even for prints. I guess most users still expects the color management system in Photolab to use the embedded ICC-profile in the files when printing instead of the active monitor settings for the monitor.
Using Camera Body gives you a consistent rendering based on the camera.
Just wondering what makes the differences between camera bodies. The only thing I can think of now is the color filter array/sensor combination: or what I would call the input gamut.
As far as i understand a rawfile has two major categorisch which a rawdeveloper must be adapting to.
1 the image data as in âhow do i read the bitmapfile correct?â I donât know if any new camera has itâs own image coding but i suspect it does has small improvements and changes.
2 camera body specific exif/meta data which holds exposure to lightnes conversiondata, colorrenderingdata and other data which convert there rawfile into a OOC-jpeg.
Both needs to be read correctly in order to open a rawfile in the right way.
Then dxo wants to improve the manufactorers settings in optical manners (lenses) and sensors colorspace rendering.
Only then the camera body and lens is supported. Unsuported lens means ! âno optical coreections made by moduleâ but rawfile is openend.
I supose they could open any DNG which holds a demosiaced pixelfile as some applications does but that hurt there commercial update policy. (You feel less the urge to renew and update if you can use the application for not supported cameraâs.)
Then again if they donât support a camera and you bought one you could end up by a other manufactorer of rawdevelopers and they could loose you as client. Itâs a thin line they walk on.
I believe16bit tiff files are non camera limited supported right?
If you can develop/convert a rawfile in a wide colorspace and export as 16bit tiff then the only âproblemâ is no prime denoise possible.
(good old NIC denoise can help with that. Or any other pixel denoise application.)
It would be nice if the update policy of supported camera list is 2 years from buying version. (same as there discount policy.)
So every camera which is added in there list is for 2 years also for the version before available. ( i canât remember when the list update stops by the way i donât own brandnew cameratypeâs so i do not encounter those problems.)
Had already read your conclusion, that the active monitor profile would effect the embedded ICC profile when printing. â Fortunately this is not true, or letâs say thatâs not how it is supposed to be.
If things are set up correctly, the active monitor profile will be recognized by the system and will ensure that your file is displayed according to the âcapacityâ of the monitor, but does not change the print output.
â The monitor property / profile determines what is visible, but it doesnât âkindaâ convert the image.
1 Like
The way it works in my environment is exactly as I have described it. When I switch between the hardware calibrated settings in the monitor for sRGB, P3 and Adobe RGB it directly affects what gets out of my printer when Photolab is set to Managed by DXO Photolab and ICM is turned off in the printer driver.
Is it set to sRGB, all my four testimages where each one has a gamut specific ICC comes out as sRGB.
If I switch to P3 I get everything in P3 - all four of them.
There are no problems printing in Photolab as long as you have a good control over of your files ICC-profile contents but if you have not you will get results you will get surprised of. If you have your monitor set to Adobe RGB and print a file with an embedded ICC for Adobe RGB everything will be fine but if you expect a file with an embedded ProPhoto-profile to come out in ProPhoto with the same configuration of your monitor, you will get disappointed.
I don´t really understand what your comment âFortunately this is not trueâ is aiming at. I have mede the empiric tests I have and observed what I have observed. Until you falsify this with your own tests I will see this comment as just nonsense. The pattern here is that what comes out of my printer when Photolab ârulesâ is totally dependent on which setting the printer have.
I can also see that the Color Management in Windows seems to be stuck with the last profile I made for my monitor and that was for P3. If you read this closely we can see that it is based om the Gamut of DCI-P3 but has a few adjustments that makes it Display P3 and that is a few settings picked from sRGB (for example the Gammacurve).
So it is the monitors settings that seems to govern what will actually print and not the Windows Systems active monitor ICM since that one doesnât seem to get updated when I switch the monitor settings.
If you are interested to look at it can make my testfiles available from my Dropbox.
I am not at all interested to have âright opinionâ in this discussion. I really know in detail how my system works after extensiv testprinting BUT others systems might react differently depending on how their monitors interact with the whole system (Monitor, Photolab (with different setting (Managed by Photolab" or âManaged by printerâ and ICM), Testfiles, Printerdrivers, Windows ICM and the printer used).
As I also stressed above that âThe monitor property / profile determines what is visibleâ you write can actually mean at least two different things. In my case it´s just the hardware calibrated monitor that seems to totally rules when printing from Photolab and not the active system-ICM-file in Windows that many applications like XnView and others might use if these applications are set to use it instead of the default that normally reads the embedded ICC in the image files instead.
When you print you need to use a printer profile representing the ink/paper combination you are using. If PhotoLab is not able to do this I would hope DXO staff would confirm or refute the problem.
@George
Oh, there is a significant difference between for example a Canon-profile for 5D Mk IV or my Sony A IV in color renderng but there isn´t much of a difference between the profile for A7 III and A7 IV. If I changed an A7 IV-file to use the model code of an A7 III-file and then opened it in Photolab I just couldn´t see any difference at all. It just doesn´t differ at all in any significant way that should stop me from developing that file at all. These filters are just providing us with a better starting point than the one we would have started from without it.
A7 IV happens to have the same rendering characteristicss as A1 and A7rV but even A7 III worked just fine. I just could not see any differences at all between them. So what I have hard to take in is that DXO is stubborn enough to lock us out of the Photolab-service we have paid a licence for because they are reluctant to let us in without a tailor made profile for a new camera BUT once we get in having a profile like that, we are free not just to choose another earlier profile for the same brand BUT also selecting anyone we like. What is the logics behind that? From my point of view there would be no difference at all letting us all in with our new for the present unsupported files and give us the exactly same possibility to choose the rendering bias of any of these camera profiles already present in Photolab.
I just can´t understand how they are thinking. They are really in for a lot of bad will here that might make people use the manufacturerâs RAW-converters instead that also is free. I used Sony,s own Imaging Edge for a while when A7 IV was unsupported and found it surprisingly advanced in most respects. It even supported wireless tethering with A7 IV a feature not even Capture One had at that moment. In some cases it also had advantages that both Camera RAW, Lightroom and Photolab are lacking and that is support for the camerasettings used when taking the images. Imaging Edge can read the Sony-metadata written to the RAW-files and these non-proprietary converters can´t. So much for these startingpoints of non-proprietary RAW-converters.
3 Likes
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.
But now Iâm back on the right path again
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.
Well, I said
" 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.
@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.
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 âŚ