you may check http://www.gamutvision.com/ to visualize different colour spaces in windows.
Here is a very interesting article about using AdobeRGB vs sRGB: sRGB vs. Adobe RGB
Ken Rockwell knows what he is talking about and of he appears to just use sRGB for everything. Keep things simple and leave colour spaces at their default and just concentrate on your photos.
I never change colour spaces and have never had an issue with output to standard quick print labs all the way to colour accurate professional printing for my book where my fish pictures need to be colour accurate. This all using sRGB!
I have my camera set for AdobeRGB, so the ooc jpegs have largest colorspace it can have.
My export is sRGB because 99% is for screen viewing.
The only hairy thing is, editingscreen not 100% AdobeRGB capable. So i could have some blind pieces in the colors
Keep in mind he is also talking about colors on different output devices and that article is from 2006. Things have changed since then.
As often Ken Rockwell simplifies a lot – but yes, for web representation, standard printing, ordering photo books and such – better to use sRGB, but also avoid wide gamut monitors.
→ scenario D
Here’s another link with some test images. It shows how your internet browser deals with different color spaces. It’s a series of articles, also from 2006
On this page one also gets instructions how to setup an internet browser (just disregard advertisments).
I have to read it carefully to see if it’s application is up to date enough, the website looks outdated.
First impresion is that it is exactly what i am preaching as checkingtool for image vs gamut of choice. Screen, paper.
Peter, that stuff doesn’t get old.
Gamutvision 1.4 is a little application allowing you to visualize different colour spaces in 3D
– similar to the video you have been referring too.
BTW, in the video (starting at 6:42) the presenter compares the wide gamut from a certain BenQ monitor with the colour range ‘available’ from Epson Premium Luster paper / old Epson 3880.
This Epson paper (I always call it plastic paper cause it’s RC base = resin coated) has as similar colour range as the above mentioned Semigloss paper (Canson Platine Fibre Rag), while the latter one is ‘much’ brighter or to describe it differently, less grey-blueish.
The big problem I find with assumptions of sRGB, or even Adobe RGB, for editing is that most seem to only be concerned with screen presentation and less with printing. I used to regularly use ProPhotoRGB in Photoshop and still use it when finally outputting TIFF exports for printing via Apple’s ColorSync Utility.
I know it’s an auto-correct typo but that did raise a chuckle. Resign all hope of ever getting a decent colour space
Just downloaded it and installed it.
can’t find a user guide to print. (yes i am a old reader with highlightingmarker for this kind of things.)
first things just blind pressing things and hey rw2 6400iso g80 icc… versus sRGB 1996-2.1 colorspace.
(no clue how i got a g80 colorprofile at 08-01-2021 in the list. but it’s fun.)
but see here the amount out of gamut of cameracolorspace and sRGB.
(only thing i now need is a Adobe colorspace to compare.)
Thanks for pointing to this application.
now i need to start understand how to compare a tiff of jpeg image to the sRGB colorspace.
this gona eat up a lot of free time i am afraid.
Oh, this is a long and very old story. I have been asking for an update of the printing module in DPL for years, since…DxO8 or something.
We need a proper and up to date printing module, with full soft proofing feature (emulate on screen the rendering on a paper or any other medium, given you have the profile). We need to choose the rendering intent, and we need to be able to choose a larger color workspace, and a a function to project the values from a color space to another (like “convert to profile” from Photoshop"). There is a great opportunity to simplify and functionalize color workflow as it can be quite a challenge to configure. There is also some misleads as we cannot choose the color workspace, but we can choose a rendering profile when outputing to JPG or TIFF, and we can choose a display profile, both not adressing the issue and a source of mislead I think.
But I admit this is a lot of work, and today you have to consider what is the final destination and the final form of your picture. I see a come back of printing on various medias (sublimation is a hot topic amongst people in the printing business, no pun intended). If the final rendering is for printing we should have a softproofing module, with warnings of the exceeding values considering the destination gamut (paper, or sRGB profile) and maybe a selectable intent (perceptual for the blues / green, but relative or even absolute, for other colors). This would go beyond what Photoshop can do.
We need :
-ProphotoRGB workspace FROM THE START (so no clipping at all. This is what CameraRAW can do)
- SoftProofing feature
- Updated printing module to emulate the rendering intent on a paper, with black compensation etc.
And don’t event start with “buy a RIP software”, DPL should be at least on par with what lightroom can do. and a RIP can be several hundreds of $ a licence, sometime even thousands…
To address some of the questions about color science:
All image capture/reproduction device or, film, or whatever you want have a Gamut. It is the transfer function, meaning the capability to capture and reproduce colors, and its standardized.
In the beginning it was true that the home-made unique demosaicing algorithm of DxO used and custom color space for its processing, and that custom color space was mimicking AdobeRGB. But it was hard-coded and truth is, no one touched this part of the code for years.
DPL does has the feature to choose the colorspace of the JPEG or TIFF when processing. You can indeed choose to project the values of the file you are about to render in a given color space, even prophoto. but if no changes have been made to the code of DPL, those file values were clipped in the beginning because of the non selectable colorspace from the start of the deBayer processing (that was AdobeRGB previously). Let’s take an analogy. So Ok you can select the language of your file values (say german or spanish) but you sill have less vocabulary because your input device only know 2000 words, and you are recording a nobel prize writer interview each time you take a picture, with say 3000 to 4000 words. Yes you can cover the essential truth of the message with 2000 words using synonyms, and you can say that most of your readers are illiterate and 2000 words are more than enough, but what is the point if your business is selling writing classes, and teach your clients to be less and less “illiterate”. Sorry for the analogy but you get the point. You have expert features in DPL and poor printing / color management tools.
But I have the impression the team touched and updated the code, when implementing the Xtrans support. A comprehensive statement on wich colorspace is currently used and with which rendering intent could bring much needed clarifications to the community.
To be very direct, Yes sensors are all able to capture significantly more colors than AdobeRGB can contain and outspec the DPL color engine.
Yes sRGB, the most widely used colorspace (and also the smaller) is smaller than AdobeRGB and is unfortunately immensely more common than AdobeRGB.
Yes Ken Rockwell, even if he is very much “without nuance” most of the time, is right when he advises to stick and edit to sRGB because its abundant use, you have best chances to have color confidence when ordering a printing job online, or when you upload picture on instagram or social medias.
As frustrating as it may be, so far it didn’t make sense to go beyond AdobeRGB if you only upload your pictures on social medias, watch your picture on smartphones, and do not do serious print at all.
I say so far because the landscape is changing. With the advent of HDR capable screens (even on tablets/smartphones), we see more and more wide color space used for video like DCI P3 (looking like AdobeRGB but with different gamma, and sligthly different gamut) and Rec2020 for full HDR. Rec2020 is nearly as wide as ProPhotoRGB. We have more and more wide gamut screens, HDR-10 or dolby vision enabled tv and rendering devices. So even if we stick to full digital use of the picture, it makes now sense to have an updated, no-clipping workspace. And then the fine art printing people could also enjoy DPL perks without sacrificing color workspace and color confidence.
Finally, what is the point to develop expert and professional features and have a “lagging behind” amateur level printing and color management feature?
I strongly support those features.
If there’s clipping in the RAW data, then there’s clipping in any color gamut. I can’t think of it otherwise.
As far as I see it this is the sequence. First the analogue value of what the sensel caught of light. Then the AD conversion. Full sensel values get the max. value, depending on the bit depth. Then the demosaicing meaning creating the RGB pixel values out off the surrounding R,G,B values. In this process none aff the values will exceed the max. value.
However, extra clipping may become vissible when going from a wider color gamut to a smaller color gamut.
It’s about starting with the widest colour gamut (like LR) and then give the user the option(s) instead to restrict from the beginning – and DxO calls it the Elite version.
I just doubt that a first larger color gamut will produce less clipping then a smaller color gamut.
I’m not meaning changing of gamut.
I’ve also never seen a model of the input gamut. If that exists I think it’s different for every model.
I believe it’s in the pipeline for some time now.
They need to rewrite the viewer software. Same as the 4K support for user interface.
Like we wanted a more full image microcontrast and denoise viewer. A conversion like we have if we export a jpeg without writing a file.
All the sliders of all the lumination and chroma and contrast and such need a new driver.
Three steps viewing calibration.
ProphotoRGB, AdobeRGB, sRGB. And conversion workspace to viewingscreen on realtime. Cameracolorspace to viewingcolorspace (workingspace) to screencolorspace.
And there is already a preformens lagg due the realtime adjustment in demosiacing after every adjustment.
So i hope they are still buzy writing…
I think the main reason is that Adobe has patented its color engine calle ACE, and it is pretty much optimal. If DXO wants to functionalize its algorithm (meaning make it variable dependant, taking into account the selectable workspace from the start), it will require work. I also hope they are really working on it, but I doubt it (ressource allocation dictates to work on market enabling features…this could be one if we are many to ask).
Why make it selectable Workspace? Having ProPhotoRGB as working color space from the start in CameraRAW increases the memory load ( just a bit), requires a monitor calibrated for this working space (a very good Eizo screen for instance), and brings unecessary operations afterward to "convert to profile"when you output your files. Not every one need it, but if you want to challenge Adobe seriously, you have to offer it.
Hardcoded AdobeRGB has been “goodenough” for years, but now we even have 16 bit per channel data with Fuji GFX100s, instead of 14 bits for Canon and Nikon (Nikon was even 12 bit AD/quantization back in the days). Change is needed to do serious printing / Art reproduction / professional poster and fine arts/
If you want to make everyone happy => Change hardcoded color space from AdobeRGB to ProphotoRGB in the elite version forget the selectable workspace, bring softproofing and black point compensation that can simulate both the paper and the rendering intent, and I can work with that.
For sure, a larger colour space does not avoid clipping from overexposure.
But there is no need to restrict the user. And as shown in → Larger working space than adobe rgb - for not loosing colors our often very expensive sensors provide us - #13 by Wolfgang
this old LR 5.7 handles everything since 10 years or so. Why can’t DxO do the same?
In several posts I’m reading that a larger color space avoids clipping, sec. That’s what I oppose to.
If the RAW data doesn’t clip, then the RGB data doesn’t. If it does, then it’s due to other editing like adding contrast.
Personally I don’t think a larger color gamut as the output device is helpful. That might be different for each of us. AdobeRGB is 16 bit, mostly. Larger color gamuts are also 16 bit. That means that their steps in editing are larger then using AdobeRGB.