What are the essential adjustments that SHOULD be done in the raw processor?

[Robert Ardill]

In Capture One all "camera profiles" are table based.

I've created a matrix-based camera profile using ArgyllCMS and used this in Capture One.  I then exported the image using Embedded Camera Profile and the file was rendered as a 16-bit TIFF with this profile correctly.  So it would appear that you are mistaken.

Cheers

Robert

[Robert Ardill]

Hi,

Using Capture One 9.0.2 I try to export a TIFF with embedded camera profile, so I can check it out in ColorThink but it embeds Adobe RGB.

Any way to embed the Camera ICC? I am working with an IQQ file from my P45+

Best regards
Erik

Yes, you created a new process recipe and for the ICC Profile you select Embed Camera Profile.

Cheers

Robert

[Robert Ardill]

""Quote from: ErikKaffehr on Today at 06:34:10 PM
Colours outside that gamut will not be correctly rendered on screen.""

to be more precise: colors outside of the monitor's gamut will not be displayed at all ...

No, colors outside the monitor's gamut will be mapped to the monitor gamut.  So they are displayed but shifted.  To say that they are not displayed at all implies that they are simply chopped (leaving black). How it gets mapped depends on the monitor profile, but it will in general be a relative colorimetric mapping, in which case the color is mapped to the closest displayable color (which is why you get banding or flat areas).

Robert

Robert

[tho_mas]

In Capture One all "camera profiles" are table based.

I've created a matrix-based camera profile using ArgyllCMS and used this in Capture One.  I then exported the image using Embedded Camera Profile and the file was rendered as a 16-bit TIFF with this profile correctly.  So it would appear that you are mistaken.

all camera profiles included in / provided by Capture One are table based ...

On Mac...: go to application -> right click on application -> show package content -> Contents -> Framworks -> AppCore.framework -> Versions -> A -> Resources -> Profiles -> Input

... of course you can also select matrix based input profiles as long as the profile class is tagged correctly in the profile header ("scnr").
You can't use the Color Editor with those profiles, though ...

[tho_mas]

No, colors outside the monitor's gamut will be mapped to the monitor gamut.

Colors that a certain hardware can't display... can't be displayed.
"Mapping" is what the "perceptual" rendering intend does.
In rel.col colors that are higher saturated in the source than in the target profile get clipped. While the colors that do fit within the target gamut appear to be the same as in the source ... so RGB values change, but Lab values stay the same (again, the Lab values of the colors that fit into the target color space stay the same ... everything outside of the target gamut is simply non-existent in the target).
Hmh ...

to double check reversed: make an image in Photoshop in ProPhotoRGB containing squares with the highest saturated RGB patches (so R 255/0/0 - G 255/0/0 - B 255/0/0).
Now convert to your monitor profile using rel.col & BPC. If everything is parameterized accurately you will not see the least bit of a change in the resulting image ...

[Robert Ardill]

Colors that a certain hardware can't display... can't be displayed.
"Mapping" is what the "perceptual" rendering intend does.
In rel.col colors that are higher saturated in the source than in the target profile get clipped. While the colors that do fit within the target gamut appear to be the same as in the source ... so RGB values change, but Lab values stay the same (again, the Lab values of the colors that fit into the target color space stay the same ... everything outside of the target gamut is simply non-existent in the target).
Hmh ...

to double check reversed: make an image in Photoshop in ProPhotoRGB containing squares with the highest saturated RGB patches (so R 255/0/0 - G 255/0/0 - B 255/0/0).
Now convert to your monitor profile using rel.col & BPC. If everything is parameterized accurately you will not see the least bit of a change in the resulting image ...

We're probably saying the same thing.  The image data is not changed but the colors are mapped to the destination using the monitor profile (in the case that the destination is the monitor).  If a color is outside of the display gamut then it will be mapped to the nearest displayable color, assuming that the mapping is colorimetric.  So the reality is that you cannot see the out-of-gamut color, but what you do see is the nearest color to it which is in gamut.

Of course, if you convert your image to your monitor color space then the image data is mapped and the information is now burnt in to the image. As far as you can see there will be no difference between this converted image and the one that is mapped on the fly, because the displayed data will be the same.  However in one case the image data is not changed, whereas in the other case it is.

I guess your point was that if you stay in the camera color space then you avoid any further change to the image data, which is valid.  But on the other hand, there are advantages to using matrix-based working spaces and if all C1-supplied camera profiles are table-based this would certainly imply that the camera responses are not linear.  So there may be a benefit in converting from the camera profile to a working space in terms of smoothness of interpolation for post-raw editing.

But I'm certainly open to being convinced otherwise.  Have you done any tests to show that there is a benefit in staying in the camera profile compared to converting to ProPhoto, say?

Cheers

Robert

[tho_mas]

We're probably saying the same thing.

okay, now I’ve got it - yes, we agree!

I guess your point was that if you stay in the camera color space then you avoid any further change to the image data, which is valid.

exactly. I also do store unedited 16bit TIFs of my "originals" along with the respective RAW files; and here I definitely want to keep a 1:1 copy of my adjusted RAW (in the respective "camera profile").

But on the other hand, there are advantages to using matrix-based working spaces and if all C1-supplied camera profiles are table-based this would certainly imply that the camera responses are not linear.  So there may be a benefit in converting from the camera profile to a working space in terms of smoothness of interpolation for post-raw editing.

As in any other RAW converter in Capture One the non-linearity of the camera's sensor gets linearized by correction tables "under the hood". The "camera profiles" - that get assigned later in the processing pipeline - provide a neutral grey axis (reproducing Gamma 1.8 ). Therefore you can use them as "working spaces" for further editing. Only downside is you can't use them for compositings containing image content from different color spaces as you can't convert into an input profile (at least not into table based input profiles only containing an A2B0 table).

But I'm certainly open to being convinced otherwise.  Have you done any tests to show that there is a benefit in staying in the camera profile compared to converting to ProPhoto, say?

ProPhoto RGB does not really encompass all colors the camera profiles may contain. See attachment - these are 4 of the profiles I use regularly (2x P45, P21+ and Sony A7R2) compared to ProPhoto (Red profile). While overall smaller than ProPhoto there are certain colors that fall outside of ProPhoto. Since I don't want to think about color conversions when working with RAW files I simply embed the camera profile and check the colors actually utilized in the respective image later in Photoshop (with regard to a specific target) or in Chromix Color Think. Mostly (certainly 90% of the time) I do post-raw-editing in the camera profile. When there is a reason to convert to a matrix based working space I select an appropriate profile. Mostly that has been ECI-RGB or Hasselblad-RGB in my case (and Rec2020 recently).
As a side note: I don't think that I ever shot / created an image that would need ProPhotoRGB to avoid clipping... the colors actually contained in most of my photos fit in much smaller color spaces. If there is any clipping it's mostly in the middle or the lower section of the luminance scale as matrix based color spaces - by the "triangle" design - get pretty small towards the blacks.

[bjanes]

In Capture One all "camera profiles" are table based. And the RAW data gets not converted into these color spaces - the color spaces get assigned to RAW-data! Therefore - by design - it is technically impossible to get clipping in C1 as long as you don't exhaust the color space by unleashed editing (but you would see it in the histogram) and as long as you embed the "camera profile" on export. The design-idea of C1 is very different to Lightroom/ACR... however, the relation of "internal color space" and output color space is basically the same in all RAW converters...

Some users prefer to use the smallest space that will cover the gamut of the image so as to decrease the spacing between adjacent levels and avoid banding. With a 16 bit matrix file, there are 2^16 or 65536 levels. I don't know the size of the C1 tables, but many table based profiles contain around 2^10 or 1024 levels. People who worry about banding in a 16 bit ProPhoto file (gamut volume 2,897,221 ΔE^3) readily accept 1024 levels in an sRGB table based sRGB profile (gamut volume 832,870 ΔE^3).

The real question regarding the necessary precision is the resolution of the human visual system. If a combed histogram has gaps that are not resolved by the eye, there will be no banding. The Digitaldog's ΔE calculations show no significant difference between 16 bit sRGB and 16 bit ProPhotoRGB. With 16 bit gamma encoded files, precision is not a significant factor except for HDR files, where precision does limit the DR of the space. For details on HDR precision see Greg Ward.

Bill

[bjanes]

profiles may contain. See attachment - these are 4 of the profiles I use regularly (2x P45, P21+ and Sony A7R2) compared to
As a side note: I don't think that I ever shot / created an image that would need ProPhotoRGB to avoid clipping... the colors actually contained in most of my photos fit in much smaller color spaces. If there is any clipping it's mostly in the middle or the lower section of the luminance scale as matrix based color spaces - by the "triangle" design - get pretty small towards the blacks.

As Bruce Fraser and Jeff Schewe (both proponents of ProPhotoRGB) point out there are many real world scenes that exceed the gamut of AdobeRGB. Although digital cameras do not have a gamut, the gamut of their recorded images is quite wide. Spectral response studies show that current digital sensors are sensitive to the wavelengths of the human visual response, so their "gamut" likely is near that of CIE L*a*b.

Here is an image of come colorful tulips taken with the Nikon D800e and rendered with Adobe Camera raw using the Adobe Standard profile and default parameters with no saturation adjustments. The image is shown in sRGB for web display.



Now, let's look at how ACR renders the image into ProPhotoRGB, AdobeRGB, and sRGB.

The image fits well in ProPhotoRGB


However, saturation clipping is present both in highlights and shadows of the sRGB and AdobeRGB renderings.






Colorthink plots of the gamuts are informative. The image extends very near the gamut limits of ProPhotoRGB in the reds, oranges, yellows, and some mid-luminance greens.



These colors exhibit severe clipping in AdobeRGB and sRGB.





This image should be rendered into ProPhotoRGB. Although some of the colors are out of the gamut of even a wide gamut monitor and can not be properly shown on the screen, some of the colors will fit into the gamut of a wide gamut inkjet printer. If some of the printed colors are blocked up, one could perform some saturation editing. However, with this image, I get the best results with no further editing of saturation when printed with my Epson 3880 on glossy paper.

Regards,

Bill

ps: edited 10:37 a.m. cst on 3/23/2016 to correct duplicate images.

[Robert Ardill]

Some users prefer to use the smallest space that will cover the gamut of the image so as to decrease the spacing between adjacent levels and avoid banding. With a 16 bit matrix file, there are 2^16 or 65536 levels. I don't know the size of the C1 tables, but many table based profiles contain around 2^10 or 1024 levels. People who worry about banding in a 16 bit ProPhoto file (gamut volume 2,897,221 ΔE^3) readily accept 1024 levels in an sRGB table based sRGB profile (gamut volume 832,870 ΔE^3).

The real question regarding the necessary precision is the resolution of the human visual system. If a combed histogram has gaps that are not resolved by the eye, there will be no banding. The Digitaldog's ΔE calculations show no significant difference between 16 bit sRGB and 16 bit ProPhotoRGB. With 16 bit gamma encoded files, precision is not a significant factor except for HDR files, where precision does limit the DR of the space. For details on HDR precision see Greg Ward.

Bill

I'm not sure that the volume of a color space is particularly useful in calculating the required resolution. 

But using a very crude approach, if you have 8 bit then it can resolve 256/256 = 1 (on the a* axis say).  This is a dE which is not noticeable to most of us, but there is the potential that this could grow with repeated adjustments to something that is, so 8 bits is really not enough.

With 16 bits you would have 256/65535 = .004 which is absolutely not noticeable and even with multiple adjustments is unlikely to ever cause a problem even when using the full Lab space.

For HDR images 32 bits are normally used so I don't see why there should be a resolution problem there either.

So I think it's entirely fair to say that with a matrix-based profile that the color space is irrelevant as far as resolution is concerned.  Use ProPhoto with impunity, if you wish.

With a table-based profile we have a different problem because it is not continuous.  A translation from one space to another then requires interpolation and this will inevitably introduce errors - more with 8 bits than 16 bits, but errors nevertheless.  So we need to make sure that we have a very large table if we want reasonable accuracy.  But, at any rate, this is why it is generally better to use a matrix-based profile as a working space, especially if the destination is also going to be matrix-based.

So the issue, if there is one, with using large-gamut matrix-based working spaces is not one of resolution really, providing we work in 16 bits.  It has much more to do with the fact that we will not be able to see the whole of our image if some of it is beyond what our monitor can display or printer print.

If we are happy to work with this situation (using soft-proofing to see where there are potential problems, if we are wise) then that's fine. Personally I am not fine with that as I want to be able to see what I am doing and not just have a warning that these bits of the image are not displayable, or printable.  As my monitor is 100% Adobe RGB, Adobe RGB is the natural choice for any image that is going to print (unless I know that there are particular colors that I absolutely want printed and I know that my printer can print them, in which case I will probably use ProPhoto ... but this is a very rare situation for me). For the same reason, if I am preparing an image for the web I prefer to work in sRGB and set my monitor to sRGB at 6500K because then I am working in my target color space.

But at any rate, it seems to me that if you know what you are doing then one color space isn't better than another: it may be more suitable for a particular image and workflow, but that is all.  If you don't know what you are doing then the advice really has to be sRGB because that is the color space least likely to cause problems at the destination, whether this is the web or a home-printer.

Cheers,

Robert

[Robert Ardill]

This image should be rendered into ProPhotoRGB. Although some of the colors are out of the gamut of even a wide gamut monitor and can not be properly shown on the screen, some of the colors will fit into the gamut of a wide gamut inkjet printer. If some of the printed colors are blocked up, one could perform some saturation editing. However, with this image, I get the best results with no further editing of saturation when printed with my Epson 3880 on glossy paper.

Excellent!  So you've checked the image and you've found that it doesn't fit into sRGB or Adobe RGB and sensibly you have decided to go for a larger color space because you want to print it with the most saturated colors that you can (and you are happy to do a print, knowing that there could possibly be color shifts if you use a perceptual intent, or banding if you use a relative colorimetric intent, which might then lead you to having to correct the image and reprint if you are fussy about such things).  However, if you only wanted to display it to us, knowing as you do that you cannot guarantee that our browsers will have anything but sRGB support, well then you would have made the sensible choice of using sRGB (I hope).

[bjanes]

Excellent!  So you've checked the image and you've found that it doesn't fit into sRGB or Adobe RGB and sensibly you have decided to go for a larger color space because you want to print it with the most saturated colors that you can (and you are happy to do a print, knowing that there could possibly be color shifts if you use a perceptual intent, or banding if you use a relative colorimetric intent, which might then lead you to having to correct the image and reprint if you are fussy about such things).  However, if you only wanted to display it to us, knowing as you do that you cannot guarantee that our browsers will have anything but sRGB support, well then you would have made the sensible choice of using sRGB (I hope).

No, I rendered the image into 16 bit ProPhotoRGB, since that is my default workflow. The argument that one should use the smallest space that covers the image and obtain greater precision is bogus, since ProPhoto 16 bit has plenty of precision and banding is not an issue. This is what the Digitaldog's 30 minute video demonstrated.

For this particular image, no complex editing is needed, but if I am going to spend considerable time working with an image in PhotoShop I won't limit my options by using sRGB and I don't want to take the time to use multiple color spaces according to the gamut of the image. If sRGB is needed, one may convert using one of the profiles for that purpose. For this particular image I merely converted to sRGB using relative colorimetric.

Rrgards,

Bill

[tho_mas]

As Bruce Fraser and Jeff Schewe (both proponents of ProPhotoRGB) point out there are many real world scenes that exceed the gamut of AdobeRGB.

there are also colors captured by digital cameras that are outside of ProPhoto-RGB (real world blues & violet blues and some high saturated yellow tones) so even ProPhoto is not a panacea for everything...

[ErikKaffehr]

Hi,

Are you sure? There is something called "pointer's gamut" that it said to contain all nonspecular reflective colours, and those colours are well contained within Adobe Prophoto RGB.

On the other hand, there may be natural colours that are shifted outside a given RGB containing pointers gamut in processing.

But I may be wrong on that, of course.

Best regards
Erik

there are also colors captured by digital cameras that are outside of ProPhoto-RGB (real world blues & violet blues and some high saturated yellow tones) so even ProPhoto is not a panacea for everything...

[tho_mas]

Are you sure? There is something called "pointer's gamut" that it said to contain all nonspecular reflective colours, and those colours are well contained within Adobe RGB.

first: no, I am not sure. I am not a scientist and don't do colormetric measurments of digital sensors. So I have to trust the findings of experts. Albeit I can't remember where I've read about captured real world colors outside of ProPhoto... I do know, however, that also many Capture One camera profiles exceed ProPhotoRGB in these very colors...

"AdobeRGB" in your quote is a typo, isn't it? AdobeRGB doesn't encompass the Pointer's Gamut...

Back to ProPhoto: it is a dated colorspace and back then was primarly developped with regard to analog film based workflows. It has no real relevance for digital capture (other than being pretty large and being the internal color space of Adobe's RAW processors). Iridient Developer moved from ProPhotoRGB to ACES as the internal color space last year for that very reason.

re ACES: http://www.tftcentral.co.uk/articles/content/pointers_gamut.htm#_Toc380197974

[Robert Ardill]

Getting back to the topic question, more or less, has anyone experience and knowledge of creating camera profiles?

I came across this useful article Steve Huff Camera Profiling and made a profile for a Sony A7RII which I then used in Capture One.  I didn't attempt to optimize the profile and it was based on the colorchecker 24-patch target.

I am particularly interested to find out if a really well prepared profile based on a suitable target can in fact give better results than the DNG Profiler in Lightroom/ACR.  If so, how did you verify your results?

Thanks

Robert

[ErikKaffehr]

Hi,

Thanks for pointing out my error! Corrected!

The Aces stuff is interesting, thanks a lot!

Best regards
Erik

first: no, I am not sure. I am not a scientist and don't do colormetric measurments of digital sensors. So I have to trust the findings of experts. Albeit I can't remember where I've read about captured real world colors outside of ProPhoto... I do know, however, that also many Capture One camera profiles exceed ProPhotoRGB in these very colors...

"AdobeRGB" in your quote is a typo, isn't it? AdobeRGB doesn't encompass the Pointer's Gamut...

Back to ProPhoto: it is a dated colorspace and back then was primarly developped with regard to analog film based workflows. It has no real relevance for digital capture (other than being pretty large and being the internal color space of Adobe's RAW processors). Iridient Developer moved from ProPhotoRGB to ACES (with a sRGB-TRC) as the internal color space last year for that very reason.

re ACES: http://www.tftcentral.co.uk/articles/content/pointers_gamut.htm#_Toc380197974

[ErikKaffehr]

Hi,

Here is a raw file from P45+ back. In all conversions I make yellows in the blade go to the extreme limit of the RGB used:
http://echophoto.dnsalias.net/ekr/Articles/ColourSpaces/20150502-CF046583.iiq

Would be interesting what you find.

Enclosed screen dump:

• ProPhoto RGB (wireframe)
• Capture One camera profile (P45+ flash) (transparent solid)
• Capture One conversion at default settings (dots)

Best regards
Erik

[digitaldog]

Digital cameras don't have a colorimetric color gamut. ICC profiles do. The targets used to build the profile play a role in this resulting gamut too!

[AlterEgo]

Getting back to the topic question, more or less, has anyone experience and knowledge of creating camera profiles?

I came across this useful article Steve Huff Camera Profiling and made a profile for a Sony A7RII which I then used in Capture One.  I didn't attempt to optimize the profile and it was based on the colorchecker 24-patch target.

I am particularly interested to find out if a really well prepared profile based on a suitable target can in fact give better results than the DNG Profiler in Lightroom/ACR.  If so, how did you verify your results?

Thanks

Robert

there is a topic about dcamprof here ... forum.luminous-landscape.com/index.php?topic=100015