Pages: 1 [2]   Go Down

Author Topic: Color space/bit depth in ACR  (Read 20651 times)

ErikKaffehr

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 11311
    • Echophoto
Color space/bit depth in ACR
« Reply #20 on: February 26, 2010, 01:04:42 am »

Hi,

Monitors may improve with time. Now we essentially have monitors covering Adobe RGB, and future monitors may cover even wider gamuts. Wider gamuts would probably require higher resolution of color tones like 10-bit or 12 bit. According to Karl Lang it is already an issue with Adobe RGB that one bit change can cause a significant change in tonality. For that reason some experts advocate using sRGB if the colors in the image don't fall outside sRGB.

Essentially, use sRGB for weddings and Adobe RGB for flower shots ;-)

Cameras have a pretty wide gamut (although gamut may not be the correct term) so the raw image contains a lot of colors falling outside sRGB and Adobe RGB. So once you truncate the colors in the raw image to a smaller RGB the colors falling outside are gone (If you use a parametric workflow you would always use the original image, so this doesn't apply). Printers can yield colors outside Adobe RGB, but cannot handle all colors in sRGB. Think of this as a screen having a gamut like a cube, and a printer having a gamut like a potato. A potato can be smaller (have a smaller volume)  than the cube but still would not inside the cube.

Unfortunately, sRGB is established as a replacement for color managed workflow. Most people have uncalibrated screens somewhat similar to sRGB, most pictures don't have embedded profiles and most viewers do neither handle screen calibration data nor embedded profiles. So using a wide gamut image is not very feasible unless both sender and receiver know what they are doing.

If we have images in a wide color space we also need high bit file formats. The wide gamut spaces are not very efficient, much of the "binary space" is wasted on non existing or non visible colors. Converting between spaces introduces some round off errors, having more bits can help with that.

One advantage with using ProPhoto RGB is that it is quite obvious if color management is missing. With Adobe RGB you can loose profile and think it's sRGB and still get away with it.

Best regards
Erik




Quote from: fredjeang
sorry for my ignorance, but I do not understand one point.
We have a super and safe space color to work with in 16bits, but then, wich monitor is able to
reproduce al this spectrum?  
So we work in a great color space but we can not see all of it, and hardly reproduce them either.    

If I understand something, the reason would be that working the file in ProPhoto RGB space, some colors that have been captured
by the camera may possibly be visible on screen, if for example onces wants to push a red.
Is that correct? Then, after pushing where you wanted, onces export in a color space that is compatible by the printer, or the web?

I do not get it.

Fred.
Logged
Erik Kaffehr
 

AFairley

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1486
Color space/bit depth in ACR
« Reply #21 on: February 26, 2010, 12:07:11 pm »

Quote from: Schewe
Lightroom for parametric editing, Photoshop for pixel editing...use the right tool for the job at hand.

Jeff, if I can drift OT for a moment....  Why would you use Lightroom instead of ACR for parametric editing if you are going pixel edit in PS anyway.  LR always has seemed redundant to Bridge/ACR/PS to me (unless one wants the image management and printng engine available in LR, nether of which justify the expense to me).  Is there an advantage to parametric editing in LR vs ACR?
Logged

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Color space/bit depth in ACR
« Reply #22 on: February 26, 2010, 12:28:04 pm »

Quote from: AFairley
Is there an advantage to parametric editing in LR vs ACR?

In terms of the actual editing, no difference at all (other than the fact that Lightroom is a "bit" more usable due to having as many panels open at once as you like).

There is a big difference in terms of being able to FIND my raw files however and after any final Lightroom edits followed by Photoshop edits I keep all my master print files in Lightroom because I greatly prefer to print from Lightroom instead of Photoshop.

I don't have any problems however, using either Lightroom or ACR/Bridge...it all depends on what I'm doing at the moment. If all I want to do is open a raw image and look at it, I would prolly simply point Bridge to the folder it's in and use Camera Raw...

What I don't do much of however is try to alternate back and forth between Camera Raw and Lightroom for edits...it can be done as long as you remember to save out the .xmp from Lightroom after an edit and then read the .xmp from the file after a Camera Raw edit...but that quickly becomes a problem keeping track of the last edit.
Logged

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 544
Color space/bit depth in ACR
« Reply #23 on: February 28, 2010, 06:42:31 am »

Quote
... Camera Raw/Lightroom use it's own internal color space based on Pro Photo RGB color coordinates in a linear (1.0) gamma.
Another question is, if such rigid editing space i.e. 1.0 pRGB ("linear gamma" ProPhoto RGB)
was really a good choice.

I tend to conclude that the editing space should be limited and change to the gamut primaries of the selected output space, even down to sRGB if needed (while keeping it at "linear gamma" in ACR). Thus, avoiding to have too much Oog colors created in the course of image editing.  Out-of-gamut colors often enough don’t come from the scene itself, but are created unintentionally when we work from "linear Raw" to a pleasing rendition.

Peter

--
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Color space/bit depth in ACR
« Reply #24 on: February 28, 2010, 12:48:12 pm »

Quote from: DPL
Another question is, if such rigid editing space i.e. 1.0 pRGB ("linear gamma" ProPhoto RGB)
was really a good choice.

Considering that the raw data is a linear encoding, yes. You can take that up with Thomas Knoll however.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Color space/bit depth in ACR
« Reply #25 on: February 28, 2010, 01:56:22 pm »

Quote from: DPL
I tend to conclude that the editing space should be limited and change to the gamut primaries of the selected output space, even down to sRGB if needed (while keeping it at "linear gamma" in ACR).


And this based on what research?

Maybe you should apply for a job on the Camera Raw team...so far they have guys from MIT, Carnegie Mellon and the University of Michigan. One of the guys was even smart enough to co-author Photoshop.

You are welcome to question what Thomas Knoll does (and why he does it) but it's really not a fruitful endeavor. Thomas is right more often than just about anybody else I know.

An "editing space" needs to be able to contain both the original capture data as well as any potential output space. That will requires wasting some gamut. So far as I know, that's NEVER caused a problem for Camera Raw (or Lightroom).
« Last Edit: February 28, 2010, 02:18:12 pm by Schewe »
Logged

bjanes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 3387
Color space/bit depth in ACR
« Reply #26 on: February 28, 2010, 02:07:21 pm »

Quote from: DPL
Another question is, if such rigid editing space i.e. 1.0 pRGB ("linear gamma" ProPhoto RGB)
was really a good choice.

I tend to conclude that the editing space should be limited and change to the gamut primaries of the selected output space, even down to sRGB if needed (while keeping it at "linear gamma" in ACR). Thus, avoiding to have too much Oog colors created in the course of image editing.  Out-of-gamut colors often enough don’t come from the scene itself, but are created unintentionally when we work from "linear Raw" to a pleasing rendition.
--
Peter's comment is a good one, but ACR allows you to select 1 of 4 output spaces and the preview and histogram are for that space.  If you are rendering into sRGB, saturation clipping can be previewed if your monitor's gamut is sufficiently high and it is shown on the histogram. In Lightroom, clipping can go undetected.
Logged

Eyeball

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Color space/bit depth in ACR
« Reply #27 on: February 28, 2010, 02:35:00 pm »

If I read Peter's comments correctly, he is referring to "early-binding" of the colorspace as opposed to "late-binding".  It's nice to have a choice as ACR currently provides, albeit in a somewhat limited fashion.  After reading all of the clarifications here, the colorspace in the ACR workflow options is basically a limited form of soft-proofing - something that LR currently doesn't provide and is handy if you are going directly to final image from the raw developer.  Going directly to output from the raw developer is becoming more and more common as the functionality of the developer increases.

On the other hand, it is also nice to have the late-binding alternative and doing everything in 16-bit ProPhoto, so that you can create intermediate images that can be adapted easily to a variety of output media in the future.

I am sure there is tons of expertise on the Adobe team but it is rather interesting that ACR has this pseudo soft-proofing capability built-in and LR doesn't since I suspect it is more common to go direct to output with LR than with ACR.   There probably was some historical baggage involved and maybe we'll see some changes on this in the new versions of PS and LR anyway.
« Last Edit: February 28, 2010, 02:35:46 pm by Eyeball »
Logged

nrennie

  • Newbie
  • *
  • Offline Offline
  • Posts: 3
Color space/bit depth in ACR
« Reply #28 on: April 19, 2010, 08:54:35 am »

Quote from: Schewe
In terms of the actual editing, no difference at all (other than the fact that Lightroom is a "bit" more usable due to having as many panels open at once as you like).

There is a big difference in terms of being able to FIND my raw files however and after any final Lightroom edits followed by Photoshop edits I keep all my master print files in Lightroom because I greatly prefer to print from Lightroom instead of Photoshop.

I don't have any problems however, using either Lightroom or ACR/Bridge...it all depends on what I'm doing at the moment. If all I want to do is open a raw image and look at it, I would prolly simply point Bridge to the folder it's in and use Camera Raw...

What I don't do much of however is try to alternate back and forth between Camera Raw and Lightroom for edits...it can be done as long as you remember to save out the .xmp from Lightroom after an edit and then read the .xmp from the file after a Camera Raw edit...but that quickly becomes a problem keeping track of the last edit.

Since I have to teach much more with ACR, I am more used to its workflow than LR, But like you, I always ingest into LR since it creates that database which is so useful.  However, my parallel need for LR comes in the form of a non-disappearing history for the parametric editing.  Am I missing something in ACR?
Neil
Logged

madmanchan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2115
    • Web
Color space/bit depth in ACR
« Reply #29 on: April 19, 2010, 09:15:10 am »

Hi folks, the internal reference scene-referred space in Camera Raw & LR is indeed RIMM (ProPhoto linear). However, that does not mean that all internal image processing operations are performed directly in that space. The actual color space used for an operation depends on the routine (e.g., noise reduction, clarity, fill light, HSL adjustments, etc.). The important thing is that the entire process is color-managed so that we can always get to & from the reference space. All of this is done automatically, starting from the source raw image data.
Logged
Eric Chan
Pages: 1 [2]   Go Up