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.
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.
Odd that a plot of these profiles in ColorThink Pro does not show this, as both ECIRGB and AdobeRGB are both encapsulating the yellow of Fogra39 (ISO_Coated_V2) at L*=86.
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!
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.
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 by Stephen Marsh; 11-29-2011 at 05:31 PM.
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.
LinkBack URL
About LinkBacks
Reply With Quote
Originally Posted by Lukas Engqvist
