Standard Finishing
4Over

Announcement

Collapse
No announcement yet.

Using ECI-RGBv2 instead of AdobeRGB

Collapse
Canon
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using ECI-RGBv2 instead of AdobeRGB

    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!
    www.facebook.com/digitalartstudio.es

  • #2
    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.
    Learning by teaching!

    Comment


    • #3
      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
      Comments are personal and my views may not be shared by my employer or partners.

      Comment


      • #4
        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
        www.facebook.com/digitalartstudio.es

        Comment


        • #5
          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. :/
          / Magnus

          Comment


          • #6
            Originally posted by flexmanta View Post
            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
            Comments are personal and my views may not be shared by my employer or partners.

            Comment


            • #7
              Originally posted by Stephen Marsh View Post
              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!
              www.facebook.com/digitalartstudio.es

              Comment


              • #8
                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
                Last edited by Stephen Marsh; 11-15-2011, 05:39 AM.
                Comments are personal and my views may not be shared by my employer or partners.

                Comment


                • #9
                  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.
                  Learning by teaching!

                  Comment


                  • #10
                    Originally posted by Stephen Marsh View Post
                    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.
                    www.facebook.com/digitalartstudio.es

                    Comment


                    • #11
                      The basic differences in working with ECI-rgb and AdobeRGB are in contrast and white point. Gamma sort of equates to contrast. The debate has been raging about what gamma to use forever. Personally, on the monitor I use the L* approach (ColorEyes Display) because it is reflective of the monitors' natural response.

                      White point is a more compelling argument. Matching the white point of your RGB working space to your destination color space just seems a natural idea to me. If you're gray-balancing your image you have to balance to the appropriate white point. If 5000K is where you're going, why not start there?

                      ProPhoto is useless if you're working toward output in print. Who cares what freakish, synthetic colors are available - they can't be output. If you're also outputting to some form of luminescent output (film or television) that can make use of the gamut, then you have a reason to use it. The problem with using a massive gamut is that it maps colors out into saturation levels that require greater gamut compression. Greater gamut compression is going to result in fewer discreet shades of any hue. To shove 10 pounds of potatoes into a 5-pound bag you have to squish 'em.

                      Comment


                      • #12
                        Originally posted by rich apollo View Post
                        The basic differences in working with ECI-rgb and AdobeRGB are in contrast and white point. Gamma sort of equates to contrast. The debate has been raging about what gamma to use forever. Personally, on the monitor I use the L* approach (ColorEyes Display) because it is reflective of the monitors' natural response.

                        White point is a more compelling argument. Matching the white point of your RGB working space to your destination color space just seems a natural idea to me. If you're gray-balancing your image you have to balance to the appropriate white point. If 5000K is where you're going, why not start there?

                        ProPhoto is useless if you're working toward output in print. Who cares what freakish, synthetic colors are available - they can't be output. If you're also outputting to some form of luminescent output (film or television) that can make use of the gamut, then you have a reason to use it. The problem with using a massive gamut is that it maps colors out into saturation levels that require greater gamut compression. Greater gamut compression is going to result in fewer discreet shades of any hue. To shove 10 pounds of potatoes into a 5-pound bag you have to squish 'em.
                        We do in fact calibrate all to D50. The whole studio is lit to D50 as are ourJUST viewing booths.

                        I've currently set my monitor to L*. The images in photoshop should look the same as at gamma1.8 right? Does the color engine compensate? I need to know how my monitor gamma will really affect my photoshop canvas... will I start retouching with more light than i should because my files look darker than they are? The UI looks a lot darker than when at gamma 1.8. I didn't have time today to compare 1.8 and L* on screen.

                        Now, about prophotoRGB, i don't think i've made clear why we use prophoto, how, and for how long (it's just an intermediate step between our RAW and our working PSD in ECIRGBv2 now.

                        With capture one and leaf capture this isn't a problem. We work with many RAW processors and in particular, Adobe Camera Raw cannot produce ECI-RGBv2 files. There are colors available in camera (commonly captured) that are available in Fogra39 AND ECI-RGBv2, but out of AdobeRGB gamut. The only way to go from camera raw to ECI-RGBv2 and not lose in-gamut colors, is to use the largest space available in camera raw, making sure you are working 16bits.

                        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.


                        You'd be surprised by how many colors frequently captured in fashion photography are out of gamut in adobeRGB but in gamut in ECIrgbv2 and in Fogra39 (some magazines want the Tony Kelly look lately). It's not only freakish colors that are exclusively available in prophoto. And then there's the volumes, and the use of perceptual intent. We get the volumes right, and then we bring them back to max saturation available.
                        Last edited by flexmanta; 11-16-2011, 04:03 AM.
                        www.facebook.com/digitalartstudio.es

                        Comment


                        • #13
                          Originally posted by flexmanta View Post
                          So, again: Camera Raw -> process the RAW in ProphotoRGB -> convert to ECI-RGBv2 and do the retouching work.
                          If CMYK is your final goal... Then I really think that you have to compare representative samples of a number of raw files, before you make any decisions. This would be done with the two competing workflows below, with evaluations on the final CMYK data:

                          1) ACR > ProPhoto > CMYK

                          2) ACR > ProPhoto > ECI v2 > CMYK

                          You may be damaging the file by going to the perhaps "superfluous" ECI v2 step, as this is only a relative colorimetric conversion and colour outside of the gamut of ECI v2 may be clipped. The wider gamut data may be junk - or it could be visually important when converted to CMYK. You will need to test to find this out. Even though Photoshop will let you select Perceptual as the transform from ProPhoto to ECI, the actual conversion will only be relative colorimetric and no gamut compression will take place, only gamut clipping.

                          Despite the theory of the ECI step being an extra unnecessary conversion, this space may present a more well behaved sandpit to play in, when compared to ProPhoto and the advantages of this editing space may outweigh any damage the conversion introduces. Again, you will need to test to find all this out!


                          Regards,

                          Stephen Marsh
                          Comments are personal and my views may not be shared by my employer or partners.

                          Comment


                          • #14
                            Originally posted by Stephen Marsh View Post
                            If CMYK is your final goal... Then I really think that you have to compare representative samples of a number of raw files, before you make any decisions. This would be done with the two competing workflows below, with evaluations on the final CMYK data:

                            1) ACR > ProPhoto > CMYK

                            2) ACR > ProPhoto > ECI v2 > CMYK

                            You may be damaging the file by going to the perhaps "superfluous" ECI v2 step, as this is only a relative colorimetric conversion and colour outside of the gamut of ECI v2 may be clipped. The wider gamut data may be junk - or it could be visually important when converted to CMYK. You will need to test to find this out. Even though Photoshop will let you select Perceptual as the transform from ProPhoto to ECI, the actual conversion will only be relative colorimetric and no gamut compression will take place, only gamut clipping.

                            Despite the theory of the ECI step being an extra unnecessary conversion, this space may present a more well behaved sandpit to play in, when compared to ProPhoto and the advantages of this editing space may outweigh any damage the conversion introduces. Again, you will need to test to find all this out!


                            Regards,

                            Stephen Marsh

                            Thanks, but really, the workflows i suggest are actually:

                            1) ACR -> AdobeRGB -> CMYK
                            2) ACR ->ProphotoRGB -> eciRGBv2 -> CMYK

                            I wouldn't stay in prophoto longer than I need. My job is to make images pretty and I need as much bit resolution as possible available in my working gamut.

                            I hear you on the perceptual being not possible.

                            At the moment I've set up photoshop´s working space as ECIrgbv2, and camera raw to output prophotoRGB. As soon as the file appears in photoshop, I converts and tags to ECIrgbv2. Haven't had a problem so far.

                            Thanks!
                            www.facebook.com/digitalartstudio.es

                            Comment


                            • #15
                              Originally posted by flexmanta View Post
                              Thanks, but really, the workflows i suggest are actually:

                              1) ACR -> AdobeRGB -> CMYK
                              2) ACR ->ProphotoRGB -> eciRGBv2 -> CMYK

                              I understand your reluctance to play in the ProPhoto sandpit.

                              Scenario #1 above may possibly clip critical detail in the ACR > Adobe RGB step.

                              Scenario #2 above may possibly clip critical detail in the ProPhoto > ECI v2 step.

                              If one moves from ACR > ProPhoto > CMYK (perceptual), then one can take advantage of gamut compression without any upstream clipping. The downside is of course any edits that may be performed in ProPhoto.

                              Your Scenario #2 is probably a good compromise for 95% of work. If you have images with subtle detail in saturated areas, particularly yellow hues, then you may wish to make a separate conversion from ACR > ProPhoto > CMYK (perceptual) and then mask/blend in the detail into your standard ECI workflow image...that is presuming that you have lost something due to gamut clipping.

                              ACR/ALR use a linear gamma ProPhoto RGB as the "invisible" internal editing space before the data is transformed to ProPhoto RGB, Adobe RGB or sRGB (or ColorMatch RGB). Of course, if Adobe would only let end users (customers!) select their preferred editing render/export space in the raw converter then these users would not be forced to add an extra conversion step.


                              Regards,

                              Stephen Marsh
                              Comments are personal and my views may not be shared by my employer or partners.

                              Comment

                              Unconfigured Static HTML Module

                              Collapse

                              Static HTML Module Content
                              4OverStandard FinishingDuploSmartsoft (Presswise)CanonKBAUltimateTharstern
                              4OverStandard FinishingDuploCanonKBAKBA4 PeesSmartsoft (Presswise)TharsternUltimate

                              What's Going On

                              Collapse

                              There are currently 5610 users online. 126 members and 5484 guests.

                              Most users ever online was 6,597 at 10:25 AM on 04-20-2018.

                              Working...
                              X