0

Photoshop has now given the facility to open and edit JPEGs and other non-RAW file formats using Adobe Camera Raw. One doesn't have to shoot RAWs to do some heavy edits. So is there still any benefit that shooting in RAW makes when editing it in ACR? When a RAW file is opened in ACR why do some menu items (sliders, etc.) color up and they don't do so when a JPEG is opened in ACR?

Michael C
  • 175,039
  • 10
  • 209
  • 561
user152435
  • 1,515
  • 1
  • 12
  • 31
  • @PhilipKendall Okay, It's basically "RAW's advantages over JPEG", isn't it? But here I'm asking what are the benefits of a RAW opened in ACR has over a JPG opened in ACR? – user152435 Jan 01 '17 at 14:58
  • 5
    The app you use makes little difference; the advantages are due to the extra data present in the RAW file. – Philip Kendall Jan 01 '17 at 15:01
  • What are those advantages? And do they come with all RAW formats? – user152435 Jan 01 '17 at 15:33
  • 6
    The advantages are those detailed in the duplicate question... that's why it's a duplicate! – Philip Kendall Jan 01 '17 at 16:13
  • Please ask only one question per post - if you have a new question, start a new post. – Philip Kendall Jan 02 '17 at 07:49
  • Have I asked more than one question, what? – user152435 Jan 02 '17 at 09:31
  • That last sentence is a part of this question, I'm asking 'what are the benefits of a RAW opened in ACR we have over a JPG opened in ACR'.. and that part is needed for the question asking for benefits.. – user152435 Jan 02 '17 at 09:36
  • 1
    Doesn't your new last sentence just logically follow from the advantages listed in the other question, and sort of answer itself? The things that remain grayed-out when you open a JPEG are things you can't adjust. – mattdm Jan 02 '17 at 15:04
  • I think the gist of the question is, "Has ACR added any new ability when processing JPEG files that hasn't existed in other JPEG processing apps because it appears to let you use the same tools it once reserved for only raw files?" Just because the answer is "No" doesn't mean the question is a duplicate. – Michael C Jan 02 '17 at 17:15
  • @MichaelClark kind of. But, not 'added any new ability'... I want to know the abilities that were there AnD the abilities that are there now.. – user152435 Jan 02 '17 at 17:37
  • If there is a difference between what was there before and what is there now then something has either been added or subtracted. – Michael C Jan 02 '17 at 17:47
  • 2
    If you're not looking for any new ability then the question is a duplicate of all of the other existing "Raw vs. JPEG" questions. – Michael C Jan 02 '17 at 17:49
  • Didn't you see the 'AnD'? – user152435 Jan 03 '17 at 04:32

2 Answers2

9

The raw image is 12 (or maybe 14) bits, and JPG is 8 bits (less range). JPG does not handle changes of extreme range well.

The JPG image already has white balance and color profile in it, likely our bad guessed try that has to be corrected first (which is the reason we are looking at it).

Not even speaking of JPG artifacts, the Raw always is the pristine sensor image. Raw is what the camera started with, before JPG applied our bad guesses about what it might need. And then after we can actually see what we're doing, then raw then can provide actual white balance and profile menus (and more), but JPG can only handle plus and minus corrections to what is already there. Raw does Not have to Undo first.

WayneF
  • 12,879
  • 1
  • 16
  • 30
  • Comparing bits is incorrect because of gamma. – Euri Pinhollow Jan 01 '17 at 22:50
  • Think again. Gamma is in a sense a no op . Encoded, and then reversed by decoding, precisely by LCD (a reversible math formula), and planned so as to be reversible by CRT and printers. Our eye hopes to see an exact and accurate linear reproduction, same as if still standing at the scene the first time. – WayneF Jan 02 '17 at 01:58
  • Gamma is an issue because changing the slope of a curve with only 256 discrete steps (8-bit) will introduce banding and other artifacts much faster than changing the slope of a curve with 16,384 discrete steps (14-bit) between pure black and full saturation in each color channel. – Michael C Jan 02 '17 at 07:51
  • @WayneF: I do not need to think again about something I know very well. Comparing bits is incorrect because of three reasons: >>>lossy 8bits are not actually 8bits (you are comparing lossy JPEG, not lossless 8bits), >>>there is much noise in shadows, >>>the majority of tones of linear gamma is wasted because of highlight noise which is numerically bigger than in shadows (even if it wasn't the benefits would not be perceptible). – Euri Pinhollow Jan 02 '17 at 12:42
  • @WayneF: I can also upload examples. – Euri Pinhollow Jan 02 '17 at 12:46
  • Michael - 8 bits can cause gamma decode to be "Off by One", but which is totally trivial, not a problem. Questionable if our monitors response can resolve banding due that 1-bit anyway (Many LCD have been 6 bits). We can argue that 10 bit video could be more perfect, but we don't use 10 bits, and don't care, since we obviously find 8-bits very adequate. See the calculator at http://www.scantips.com/lights/gamma2.html , Option 7, for specifics of this Off by One "issue" in 8 bit video. – WayneF Jan 02 '17 at 15:29
  • 2
    Gamma is not a no-op. Not hardly. The raw file is the linear data from the sensor. Mapping a raw file to a color profile applies a gamma curve that compresses some parts of the image data and expands others. Compressing image data leads to a loss of information. If you then try to manipulate the image, you can get banding and other artifacts. – Duncan C Jan 03 '17 at 02:39
  • It's sort of relative. The CRT of course needed gamma for several decades. The printer uses it (not same amount, but must expect same standard amount). Not a no op for them. But todays LCD monitor simply has a chip to decode it back to linear to make the data usable (and which does need to use the correct profile value to reverse it). Encode it, and then decode it. No other action, that is a no op. The necessary use for gamma is of course to maintain compatibility with all of the worlds images which are already gamma encoded, which is the really big deal. So a useful no op. :) – WayneF Jan 03 '17 at 03:07
  • @WayneF: " Encode it, and then decode it. No other action, that is a no op. " - except that image requires fewer bits after encoding. You cannot make a tonal transformation from 14 bit range to 14 bit range, you are always loosing some part of the values. What makes it possible to use lower bit depths for an image. – Euri Pinhollow Jan 03 '17 at 12:18
  • @WayneF: "But todays LCD monitor simply has a chip to decode it back to linear to make the data usable" - why not send the linear data to LCD then? – Euri Pinhollow Jan 03 '17 at 19:33
  • We could, it would work (for LCD), and it would directly eliminate the "Off by One" error caused by gamma math. But instead, we obviously continue for compatibility with all the worlds (RGB) digital images, which already have gamma in them. And of course, for compatibility with CRT too. LCD must expect that, it is all that exists. It's trivial to keep doing it, gamma is just a simple chip today (lookup table in ROM, samples on that calculator page). – WayneF Jan 03 '17 at 20:27
  • People do imagine many wrong things, the funniest is that since they don't know what it is for, then gamma must be for the human eye somehow? But no human eye ever sees any gamma data, it's always decoded first (either by CRT or by LCD), but always hopefully back to a reproduction of the same linear that the eye and lens first saw when standing in front of the original scene. Our histogram data does contain the gamma values, however it is always necessarily decoded before our eye ever sees it. – WayneF Jan 03 '17 at 20:27
  • @EuriPinhollow Sure, sounds like it needs to be discussed. Go ahead, let me know where. – WayneF Jan 04 '17 at 23:00
  • @WayneF You're totally mixing gamma correction in raw developing with display gamma. They're two totally different things - just like a printer profile applied within an application to soft proof an image and a monitor profile used by a display adapter to correct the color output of a monitor. Using the printer profile inside the application to soft proof does not also replace the monitor profile used by the GPU. They're both applied at different points in the chain. – Michael C Jan 07 '17 at 00:20
  • I know what you said and don't disagree but it seems not about anything gamma that's been said. No, I'm not mixing anything. It's simple. CRT needs 2.2, so we universally do it, always had to. Printers need much of it (dot gain), and they know how to use the 2.2 we give them. LCD are linear, and need nothing, but conventions (standards for compatibly) cause us to just give them the same 2.2. They simply remove it. But we do have to give them exactly the same 2.2 so their LUT applies the same math to decode it. The human eye needs NOTHING, except to see the decoded linear reproduction. – WayneF Jan 07 '17 at 00:53
  • The decoded linear reproduction includes gamma adjustments that are not removed before the signal is sent to the GPU, which also applies another gamma curve which is then decoded by the monitor. But the gamma curves applied in the decoding of the raw file are not reversed in a later step in the pipeline. – Michael C Mar 03 '21 at 02:18
5

The limitations when working with JPEG image files, as compared to working with raw data, isn't so much in the application used (unless it is a poorly written application - which could be the case for either raw or jpeg processing). The limitations are self-imposed by choosing to edit a JPEG image instead of a raw file and by the way previously converting to JPEG preserves only the information needed to display the image in that one single interpretation of all the information that was collected by the sensor and included in the raw data. Even if Adobe Camera Raw is allowing you to use the same sliders as you use when editing a raw file, the same information is not available to the app with a JPEG image.

Raw files contain the information captured by the sensor before most processing is applied to that information to make it an image that we would consider viewable. If that information were converted to a 16-bit 3-color raster image (such as a 16-bit TIFF) the file size of a 25-30MB raw file from a 24MP camera would be around 100MB. Typical color JPEG images, even using very little compression, from a 24MP camera are around 5-10MB depending on image content.

When a raw file is converted to JPEG only the information in the raw file that is needed to display the JPEG with a specific set of settings (WB, contrast, etc.) is preserved in the conversion. The data not needed is discarded. If you are saving your files in camera as JPEGs the camera's processor is making those decision for you and converting the raw data coming off the sensor into the smaller JPEG format. The information in the raw data is then discarded.

Once processing steps such as gamma correction, black and white points (which determine the darkest and lightest things in the scene that will be between pure black and pure white), white balance, etc. have been applied they are irreversible. The additional information in the raw file needed to change the values used when doing that process is thrown away in the interest of making the files smaller. When editing a JPEG image one can only choose to alter the information that is still present in the jpeg file by increasing or decreasing the amplification of the color values of each pixel. But the information that was thrown away can not be recovered.

Keep in mind that what you see on the screen when you open a raw file is not all of the information in the raw file. It is an 8-bit conversion of that data very similar to a jpeg. It is only a slice of the entire data set. When you move the sliders with a raw file you actually are drawing on the raw data to display information that wasn't being displayed before but was present in the raw file. When you move sliders with a JPEG file you can only apply a multiplier/divider to the data already displayed in the image, and that data is much coarser than the data in a raw file.

For more, please see: Why is my camera so forgiving for overblown exposure when shooting in RAW? and RAW files store 3 colors per pixel, or only one?
This answer to Why does an X megapixel sensor produce X MB of data (in image files)? discusses what information is contained in a raw file. So does this answer to Which file format is recommended for black and white photographs?
You may also find this question and its answers helpful: Does a RAW file in Photoshop contains all the data only while in Camera RAW or at all times in Photoshop?

From the comments:

So, with a RAW opened in ACR, one can adjust the gamma correction, black & white points, white balance etc. easier than a JPG opened in ACR, is it?; one can arise details hidden in shadows more easily than with a JPG? With a RAW opened in ACR, more details will emerge when the exposure slider is slid?

It's not just easier with raw. You need raw to do it at all with regard to expanding the white and black points. If the shadows in the jpeg are pure black or the highlights are pure white you can't increase the detail in those areas at all. Black and white points are totally baked into the jpeg. You can reduce pure white to a shade of grey, but everything that was pure white will be a uniform shade of grey with no details showing. Same thing with pure black. You can bring it up, but it will just be a uniform blob of the same shade of grey.

And the other parameters?

You have much less latitude with jpeg than raw before you start seeing artifacts such as banding when altering brightness, contrast, color/white balance, or gamma curves because you have much more limited information from which to work. The difference between 256 discrete brightness levels (8-bits) and 16,384 (14-bits) discrete brightness levels between black and white is immense and allows for much smoother transitions when the shape of the light response curves are altered.

It doesn't take long playing around with an image or two to see the difference. Take a photo of a reasonably high contrast scene. Intentionally select a wrong color balance. For example, tell your camera you are shooting under tungsten lights when you are outdoors. Just for fun, overexpose by a stop and a half. Save the image as RAW+JPEG in camera. Then edit the raw file, correcting the WB and bringing exposure down to reveal the detail in the blown highlights. Now try to do the same thing with the JPEG!

The data present in a raw file also makes it possible to do things to images shot under poor, limited spectrum lighting that would not be possible to do to a JPEG shot under the same conditions, even if the in-camera settings were heavily adjusted before the shot to compensate for the biases in the lighting.

Michael C
  • 175,039
  • 10
  • 209
  • 561
  • So, with a RAW opened in ACR, one can adjust the gamma correction, black & white points, white balance etc. easier than a JPG opened in ACR, is it?; one can arise details hidden in shadows more easily than with a JPG? With a RAW opened in ACR, more details will emerge when the exposure slider is slid? – user152435 Jan 02 '17 at 03:26
  • 1
    Not just easier with raw. You need raw to do it at all with regard to white and black points. If the shadows in the jpeg are pure black or the highlights are pure white it is at all. Black and white points are totally baked in in the jpeg. You can reduce pure white to a shade of grey, but everything that was pure white will be uniform grey with no details showing. Same thing with pure black. You can bring it up, but it will just be a uniform blob of the same shade of grey. – Michael C Jan 02 '17 at 07:31
  • helpful.. And the other parameters? – user152435 Jan 02 '17 at 07:41
  • @user152435 Have you looked at any of the other highly voted questions/answers here with the [raw] tag? It's all here already. – Michael C Jan 02 '17 at 07:45
  • @user152435 Answer expanded to address your comments and links added to other relevant information here at photography.stack exchange. – Michael C Jan 02 '17 at 18:08
  • If one can upvote an answer more than once... – user152435 Jan 03 '17 at 04:50