Using ECI-RGBv2 instead of AdobeRGB

[flexmanta]

Hello everybody.

First of all I'd like to say it has taken a long time for me to find a place that feel adequate for the kind of questions I have regarding color. This is a very extensive topic and most of the stuff I have found online is not convincing enough for what I need... so, thanks.

I work at a fully structured photography post-production studio. We are now in the process of updating all the equipment and colour management policies, so I'm looking for understanding as much as I can, and perhaps, make some modifications for optimizing our workflow, which I will describe now.


The studio:
Carefully lit to D50, white walls and all of that. We use wide gamut monitors, hardware calibrated with spectrophotometer and set to D50 and with a TRC of gamma1.8 (native primaries/eye one pro). Our viewing booths are also D50.

Our workflow:
Our working RGB profile is currently AdobeRGB. With some particular jobs we've had to process our RAWS in prophotoRGB, and then take them down to AdobeRGB for work. We softproof in the old CMYK ISO COATED and we also produce UGRA/FOGRA certified color proofs through a RIP (Proofmaster) driving an old Epson 4800.

Today, we are upgrading to the new EPSON 4900, and we're getting a custom made printer profile which will be used by our RIP in order to lower as much as possible dE. We're also going to start using ISO COATED V2 (FOGRA39L) as our standard output profile.

Summing up: RAW -> adobeRGB -> ISO COATED V2 for soft proofing and hard-proofing.



The reason for this post is mainly the fact that something tells me eciRGBv2 would be the right working RGB profile to use during the RGB part of our workflow, instead of adobeRGB.

-What are the advantages of using eciRGBv2 rather than AdobeRGB.
-Would it go better with our D50 working environment?
-What is it about the L* TRC. Would we need to set our monitors to L* instead of gamma 1.8?
-What are the problems related to AdobeRGB being gamma2.2 and D65 when we convert to CMYK and we also softproof on D50/1.8 monitors which we also use for matching the print?

The workflow I want to suggest to my colleagues is: RAW -> Prophoto -> Perceptual to eciRGBv2 -> work -> CMYK for delivery. Is that correct? And would we need to change anything in our monitor's calibration?




I would have liked to be able to write all of this in a much shorter post, but I felt I needed to give as much information about our current way of working.

Thanks!

[Lukas Engqvist]

White walls? As I understand NCS2500, or neutral grey is better than white.

Could you explain how you process in proPhoto? I don't know of any monitor that can "see" prophoto, so it's as I understand it a bit of a shot in the dark to edit in ProPhoto.

There is a big difference between "old" ISO coated and ISO Coated v2, dot gain being the biggest change.

In my experience the biggest difference between AdobeRGB and eciRGBv2 is the ability to make clean CMYK yellows in your RGB files. AdobeRGB has a bias to bluish white, which means a greenish lemon yellow. eciRGB v2 uses an L* rather than a gamma.

I am personally sceptic to go over ProPhoto, (and going over perceptual too) and would have gone:
RAW->AdobeRGB 16 -> relative eciRGBv2 (screenproof Proof) -> (Relative with BPC when generating PDF) CMYK

Possibly would have left in AdobeRGB to avoid additional conversion, unless I needed those yellows.

[Stephen Marsh]

There is no perceptual transform available using matrix based profiles such as ProPhoto to ECIv2 (unless your profile is table based).

The only table based RGB working space that I can think of off-hand is "Photo Gamut RGB".

As Adobe do not believe in giving end users the option of selecting their own RGB editing space apart from the ones hard-wired into ACR/ALR - one is stuck with Pro Photo, Adobe RGB and sRGB (and or ColorMatch RGB in ACR).

If you use a different raw converter, then you can select a different RGB space to directly render into.


Regards,

Stephen Marsh

[flexmanta]

Thanks for your replies.

A color guy came to tune our studios equipment today. We don't really do pre-press or printing as a main business, as, as i said, we're a post-production studio and we do retouching and CGI for editorial and advertising. Our colour proofs are acually more of a defense for us, in case someone screws up after we deliver the file. Also, some of the clients we work with, like to know that what we send them, is closer to what they'll see printed. From today we output fogra39 as main offset, and we've also set up a couple other queues. All ISO 12647-7 compliant. According to this guy, it's not common to find such a small studio that takes colour so seriously without it being its main business.

I'm surprised by how low the dE and dH got after this guy finished working.

If interested: Digital Art Studio | Facebook


Anyway. He strongly recommended that we use ECI-RGBv2 as our working profile.
Going prophotoRGB first makes sense when knowing that there are colors available in the RAW file that are also available in our output profiles, but that would be thrown away when converted to AdobeRGB.

I don't care that our monitors won't be able to display all the colors in prophotoRGB. We'll just use it as an intermediate step between RAW and ECIRGBv2. The main reason being that Camera Raw doesn't allow the use of profiles not contained in its default list. We also work with Capture One sometimes, and with it, prophotoRGB would not be necessary as it allows you to use whatever ICC you want.

Thanks

[Magnus]

And then again, whats the benefit of using ECIRGBv2 instead of AdobeRGB?

Better yellows when you convert to CMYK? Better softproofing? Better similarity between display/print?

We have a very similar setup as flexmanta at our firm, so it would be really helpful if someone could explain this to me as well.. Still doesn't get it. :/

[Stephen Marsh]

I don't care that our monitors won't be able to display all the colors in prophotoRGB. We'll just use it as an intermediate step between RAW and ECIRGBv2.

Scenario 1: Raw Camera Data > ProPhoto RGB > CMYK (Perceptual) = A no brainer, all should be "OK" (as far ask things go with RGB to CMYK conversions).

Scenario 2: Raw Camera Data > ProPhoto RGB > ECI RGB v2* > CMYK (Perceptual) = *AFAIK the ProPhoto RGB to ECI RGB v2 transform will be Relative Colorimetric only, which may clip for example saturated yellows, then whatever colour has been clipped would be perceptually mapped into CMYK.

Scenario 2 is not going to help and may cause "damage". The options seem to be to stick with Scenario 1 or to use a different raw camera data rendering engine than Adobe Offers.


Stephen Marsh

[flexmanta]

Scenario 1: Raw Camera Data > ProPhoto RGB > CMYK (Perceptual) = A no brainer, all should be "OK" (as far ask things go with RGB to CMYK conversions).

Scenario 2: Raw Camera Data > ProPhoto RGB > ECI RGB v2* > CMYK (Perceptual) = *AFAIK the ProPhoto RGB to ECI RGB v2 transform will be Relative Colorimetric only, which may clip for example saturated yellows, then whatever colour has been clipped would be perceptually mapped into CMYK.

Scenario 2 is not going to help and may cause "damage". The options seem to be to stick with Scenario 1 or to use a different raw camera data rendering engine than Adobe Offers.


Stephen Marsh

What you say makes a lot of sense. The prophotoRGB approach i suggested was only intended to bring thes out of gamut colors to the PSD just because Camera Raw didn´t allow for anything other the profiles we all know... I'll have to do some tests with different images to see how much damage a conversion from ProphotoRGB to ECI-RGBv2 will cause in 16bpc.

We've tested many RAW converters. WE use Leaf Capture, since it's the tethering software we use during the shoots. It's not bad. We've also used Capture One, and we even got Capture One people to come to our studio to give us training since we also bought a couple digital backs from them. It only suits a certain type of images. Some others react better to Camera Raw.

The main advantage we see in camera raw is the ability to use RAW files as smart objects in photoshop. That is retoucher's talk but trust me it's a huge advantage because, for every image, we might need more than one conversion per RAW, especially when compositing CGI with photograhy.


I'll continue my research on ECI-RGBv2 and how to work with it in a 100% adobe workflow.

Could anyone give me some advice on calibration regarding a TRC of gamma1.8 or L*? Doesn't really make a difference in photoshop, does it?

I'm at your disposal if anyone has any questions from my side of the industry.

THANKS!

[Stephen Marsh]

The main advantage we see in camera raw is the ability to use RAW files as smart objects in photoshop. That is retoucher's talk but trust me it's a huge advantage because, for every image, we might need more than one conversion per RAW, especially when compositing CGI with photograhy.

Yes, I have been there as a dedicated retoucher/colour operator - before digital cams though, when drum scans still ruled the day. Ah, the joy of dealing with film grain and unflattering lighting on models before the healing tools came along!

The thing with raw camera file smart objects, is that once the raw file is a smart object in Photoshop - it is divorced from the original raw file. Any edits to the original raw file are not reflected in the raw file embedded in the Photoshop document. That being said, one can of course tweak and re-render the raw data as required and that will update in the Photoshop file (just not reflected in the original raw image). In effect there are two separate raw camera files, which are not "synced" with each other. This is because Photoshop smart objects are not a single "linked image" as found in say InDesign - they are duplicate embedded placed images (there are of course pros and cons with each approach).


Stephen Marsh

[Lukas Engqvist]

Screen shot 2011-11-15 at 13.55.13.jpg@Stephen Your Scenario 1, ProPhoto to CMYK with perceptual yes it will be Ok if you want to maintain all the image you have captured but then you will not get the full dynamic range of the CMYK.

I personally don't like the ProphotoRGB beacuse the gamut is totally warped... yes it has Echtachrome nostalgia... but just study the Gamut... in 3D and you will see it is skewed so that it centres differently in highlights and shadows. Attatched is a comparison between AdobeRGB and Prophoto along the b axis. Prophoto gives you some extreeme colours at the expense of loosing some more common ones.

[flexmanta]

Yes, I have been there as a dedicated retoucher/colour operator - before digital cams though, when drum scans still ruled the day. Ah, the joy of dealing with film grain and unflattering lighting on models before the healing tools came along!

The thing with raw camera file smart objects, is that once the raw file is a smart object in Photoshop - it is divorced from the original raw file. Any edits to the original raw file are not reflected in the raw file embedded in the Photoshop document. That being said, one can of course tweak and re-render the raw data as required and that will update in the Photoshop file (just not reflected in the original raw image). In effect there are two separate raw camera files, which are not "synced" with each other. This is because Photoshop smart objects are not a single "linked image" as found in say InDesign - they are duplicate embedded placed images (there are of course pros and cons with each approach).


Stephen Marsh

We, as a studio, are familiar with all those approaches. We don't need all the changes to appear in the original RAW. We just use smart objects to use as much as we can from a RAW file without having to create a TIFF for every adjustment.

We do also work exporting TIFFs and stacking them in photoshop for comp and work when we use a non-Adobe RAW processor.

Interesting what you say about scanners. In most of the high-end fashion productions that we work on, everything starts with the scanning of a large format negative. We have a beautiful Hasselblad Flextight FT646 scanner for that.

As a digital retoucher, I enjoy working with analogue captures the most.