Using ECI-RGBv2 instead of AdobeRGB

Assign profile would be same as preserve numbers. In theory the perceptual should honour the shape of the gamut, which can differ quite a bit. I guess using assign profile and then use convert profile and compare the difference would show if it is the same.
 
RGB to another RGB space Perceptual, wouldn't that be the same result as Assign Profile. Perceptual aims to keep the differences at the expense of the colour or am I having a doh! moment.

Fascinating discussion by the way.

As I have mentioned more than once in this topic thread - for the most common (matrix based) RGB working/editing space profiles there is no perceptual intent! Off the top of my head the only common freely available table/perceptual mapping profile is PhotoGamutRGB - which has a number of issues in and of itself which tend to limit it's use (in my opinion).

URL - http://photogamut.org/E_Index.html

It has caused no end of confusion that software developers allow end users to select one of four rendering intents - even if the destination profile in question does not actually contain the selected rendering intent option (as is the case with say Adobe RGB 1988).


Regards,

Stephen Marsh
 
Last edited:
RGB to another RGB space Perceptual, wouldn't that be the same result as Assign Profile. Perceptual aims to keep the differences at the expense of the colour or am I having a doh! moment.

Fascinating discussion by the way.

Perceptual would be the rendering intent that would dictate what would happen to all those colours available in the original colour space but not in the destination colour space. It doesn't matter how those colors are described (xyz, LAB, RGB, CMYK)...
 
I thought Perceptual moved ALL the colours (the whole space) not just "those colours available in the original colour space but not in the destination colour space".

I also had no idea that the rendering intent had to be included in the destination profile so am hoping to learn more.
 
I thought Perceptual moved ALL the colours (the whole space) not just "those colours available in the original colour space but not in the destination colour space".

I also had no idea that the rendering intent had to be included in the destination profile so am hoping to learn more.


And you are right about that.
 
RGB to another RGB space Perceptual, wouldn't that be the same result as Assign Profile. Perceptual aims to keep the differences at the expense of the colour or am I having a doh! moment.

No. Any conversion changes the color numbers in every single pixel by whatever parameters are defined in the conversion, for good or ill.

Any assign does not change the color numbers in any pixels at all. However all the colors change because those color values map to a different place in the new color space.


Mike Adams
Correct Color
 
@Stephen, to be editing in CMYK makes comping problematic in my opinion since blend modes in CMYK can produce strange results (Especially if you have any amount of GCR in an image). It is so much easier to work in ECI RGB than in CMYK. Even if CMYK may be the output I am sure any retouch should be easily adaptable to other media than print.

Lukas, what you say makes a lot of sense, and yes, Lab mode and RGB mode are often better retouching/compositing modes than CMYK, even more so when one has to do a lot of "heavy lifting". For simple stuff, staying in CMYK is not a problem.

That being said, my suggestion of going from raw camera data, to ProPhoto RGB and then perceptually to CMYK was to preserve any possible important visual details that may possibly be clipped if the discussed workflow of using ECI RGB before the final CMYK conversion. If ProPhoto to CMYK detail was preserved without going to ECI RGB, one could blend the data into the ECI RGB image. This could be done by converting the CMYK data to ECI RGB - or one could use Apply Image to directly move single channel data from the CMYK file into the RGB file. This would be done using layers, layer masks etc.

Also, one could simply blend in the ProPhoto to CMYK data directly into a final ECI to CMYK conversion, as the blending would be very simple and one should not need special effects blending modes.

With a raw camera data workflow, one can simply setup their preferred rendering instructions in ACR, then render out to ProPhoto - then perceptually map to CMYK. One can then render to ECI and then perceptually map to CMYK. These "conversions" may simply happen on the fly as a softproof. One can then compare the two files to see if anything critical is going to be lost in the ECI RGB conversion. This should be pretty fast and easy to do upstream early in the workflow, before any retouching or other work is done in Photoshop. At least one knows what is happening with subtle gradations or detail which may be clipped in ECI RGB without the user ever knowing it was there. Remember, the detail may never appear in the monitor or editing colour space and may only show if it was preserved when going from ProPhoto RGB to perceptual CMYK. If one converts to ECI RGB upon receiving the ProPhoto image from ACR - then the data may be clipped and one may never know what one is missing out on! Seems safer to me to open the ACR render as ProPhoto, softproof to CMYK and then make important decisions. Obviously this takes time and the payback for this workflow may be too small for the investment... which is why it is good to test this on a wide range of images before making concrete decisions on a workflow.

Best,

Stephen Marsh
 
Last edited:
There are colors available in camera (commonly captured) that are available in Fogra39 AND ECI-RGBv2, but out of AdobeRGB gamut.

So, again: Camera Raw -> process the RAW in ProphotoRGB -> convert to ECI-RGBv2 and do the retouching work. It is the only way to go work with camera raw and not lose any of the captured colors that were available in camera that are also available in Fogra39.

I'v always thought that AdobeRGB covered the whole Fogra39 gamut. Can you give any examples of CMYK-colors (Fogra39) that isn't 'available' in AdobeRGB?
 
The problem areas are Yellows

The problem areas are Yellows

Yellows (L 66-90) in picture L=86. (If yellow industrial machines are what you have this can be important)
There is also a touch of magenta range that ECI RGB can access. The subtle differences between the two also means that there are more "skintones" and bright (non-printable) reds available in ECI, where Adobe puts it's money on the (non-printable) bright blues.
Red curve ECI
Blue curve Adobe
Green FOGRA 39
 

Attachments

  • Screen shot 2011-11-24 at 07.38.25.jpg
    Screen shot 2011-11-24 at 07.38.25.jpg
    8.2 KB · Views: 216
Last edited:
Exactly. And it is not gamut what I care about the most. We are used to making less saturated colors assume the same weight that they had in their more saturated versions. As i said before, we do retouching and that is what we do every day. Currently, one of the retouching styles that client's ask the most, is Tony Kelly's and Richardson's... very colorful. A pain to make pretty in CMYK.


Now, I've already done 2 jobs in ECI-RGBv2. Worked great. There's one thing we're still figuring out how to solve.

We used to deliver the jobs in a DVD containing both the Fogra39 CMYK and the AdobeRGB versions. We'd also include a Ugra/Fogra color proof certified up to ISO 12647-7 tolerances. Now, when emailing the progress versions, we'd also send AdobeRGB files which the clients were ok with.

Now, since we're working in ECIRGBv2 in it's ICCv4 flavour, we're not really sure that the designers are confortable, assuming their Indesigns have AdobeRGB set as working color space. Also, we're not sure that the way they review the progress reports involve an ICCv4 compatible program.

So: We're sure we are going to still working in ECI-RGBv2. Now we need to define whether we'll also deliver the finished files in ECI or in AdobeRGB, and also how we'll send them the emails with the progress reports.
 
Lukas,

I used Monaco to check them too, and got exactly what you got at exactly the same place: L=86 being the only area where Adobe1998 does not completely encapsulate Fogra39. So as far as Fogra39 goes, there aren't any bright reds or skin tones available in ECI that are not available in Adobe1998, because to Fogra39, they're just as unprintable as the blues.


Mike Adams
Correct Color
 
Now, since we're working in ECIRGBv2 in it's ICCv4 flavour, we're not really sure that the designers are confortable, assuming their Indesigns have AdobeRGB set as working color space. Also, we're not sure that the way they review the progress reports involve an ICCv4 compatible program.

ECIRGBv2 comes in both ICCv2 & ICCv4 versions does it not?
 
Would be so much simpler if we were allowed to choose ICC in ACR. It's tempting to try and hack it :p

I devoted some time to that idea yesterday. So far I haven't been able to figure out where ACR is looking for profiles.

Found some strange behavior with ProPhotoRGB. Take a look at the attached screen grabs. The hexagon is the file I used - simple RGB image. The other image is the pixels of the hexagon (in the ProPhoto colorspace) plotted in ColorThink. Look at the hue-shift occurring in the greens and blues!
 

Attachments

  • HexScreenGrab.jpg
    HexScreenGrab.jpg
    499.5 KB · Views: 218
  • ProPhoto.jpg
    ProPhoto.jpg
    294 KB · Views: 201
I devoted some time to that idea yesterday. So far I haven't been able to figure out where ACR is looking for profiles.

It is my understanding that these profiles are hardwired into ACR/ALR. One could test this by removing all ICC profiles from the various system locations and then trying ACR/ALR for a conversion.

Attached is an image of what I believe is the Adobe Camera Raw processing pipeline. I can't vouch for the accuracy of this info, as it is proprietary info and Adobe do not explain in great detail what happens under the hood.


Stephen Marsh
 

Attachments

  • acr-processing-pipeline-approx.jpg
    acr-processing-pipeline-approx.jpg
    155.7 KB · Views: 229
Are you sure that internal ACR data is RGB and not Lab?

Yes Lukas, I am sure that it is RGB, despite some ACR controls appearing to be Lab based. If you search the internet fora/forums hard enough you will find this stated by both Adobe employees and pro photographer evangelists/product specialists/alpha testers. The ACR/ALR internal editing space uses Pro Photo RGB primaries with a linear 1.0 gamma (to match the linear capture of digital camera sensors). Knowing how these guys feel about Lab mode/conversion/edits, and that the Bayer CFA lends itself to RGB channels, it makes sense.

In ACR, the histogram is converted on the fly from the internal editing space to one of the four hard wired output spaces. In ALR, the histogram is based on an sRGB tone curve with the primaries still being Pro Photo RGB, as a linear histogram would confuse most users. Unlike ACR, the ALR histogram is not mapped to an output space, which means that the histogram that one views in ALR is not the same as the rendered/exported image histogram - even for sRGB.


Regards,

Stephen Marsh
 
Last edited:
This makes it even more alarming that the ProPhoto gamut is as it is :S Well with that in mind maybe it's not so bad then to use the ProPhoto as an intermediate…even if it does mean going 16-bit. But there are also other camera raw developers? Is there a better developer (knowing this is subjective) if one intends to use ECI RGB as working space?
 
This makes it even more alarming that the ProPhoto gamut is as it is :S Well with that in mind maybe it's not so bad then to use the ProPhoto as an intermediate…even if it does mean going 16-bit. But there are also other camera raw developers? Is there a better developer (knowing this is subjective) if one intends to use ECI RGB as working space?

I am not experienced with all the different raw camera data processors out there, however from my limited experience it would appear that Adobe Camera Raw and Adobe Lightroom are the exceptions in not allowing end users to select any installed profile as the rendering/export/output space.

Adobe products have great workflow, speed and features. Other raw processors (and there are many of them) offer other features, which may not compare to Adobe in speed or workflow - however they may offer great quality and more flexibility for say the demosaic process, which can have a critical affect on quality for some camera models, shooting conditions or scene content.

Stephen Marsh
 

PressWise

A 30-day Fix for Managed Chaos

As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line.

“We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month.


Learn how…….

   
Back
Top