Destruction by jpeg

[george013]

According to Eric Chan of Adobe in this thread here, conversion from 12 or 14 bit to 16 bit in ACR/LR is done by scaling. ie multiplying the pixel values by a simple multiplier. eg if the 14 bit white level was set at say 16,000, then this is mapped to the maximum value possible with 16 bits, 65,534. So in this case, the scaling factor would be 65534/16000.

I believe dcRAW works the same, can't say for other raw converters.

Dave

If you replace the actual bit value as a percentage of the max bit value, then you work bitdepth independant. Some interfaces of edit programs do use the percentage value. Neutral middle gray is (50%,50%,50%) in any bit depth.

In general (x-bit value/x-bit max. value)=(y-bit value/y-bit max. value)

George

[Manfred M]

George - you are splitting hairs here. Both what you and I have written is technically correct, the only difference is the language used. When one goes from a word (16-bits) to a byte (8-bits) one has indeed reduced the storage requirements by half. My purpose when I write these is to be understandable to the non-technical readers, rather than the engineers or programmers that are members.

For instance a binary value of 127 is 100000000100110111111111 (mid-point of 8-bit channel)
whereas 2048 is 100000000100110111111111100000000000100000000000 (mid-point of 12-bit channel). Half of the data is gone in going from one to the other.

The raw file is never saved and remains as either a 12-bit or 14-bit data string, but the output file structure, for instance a 16-bit tiff would have two packed zeros. I know that one can't directly compare the file structure and size of a tiff, bmp, jpeg, etc, but again, I am trying to have the non-engineers that are reading this understand what is happening. If we were looking at a number of the medium format cameras, these do output 16-bit raw files which are actually just packed 14-bit data.

The explanation of the no changes to the jpeg file size was an experiment that I (and a former moderator at this site) did with a recent version of Photoshop, which would be the most common platform used by users here and we saw NO change in file size over repeated re-saves of the file. Different jpeg converters could act slightly differently; regardless, the important part of the message is that we saw (and it appears you got the same result) of NO changes in image quality. The big change comes the initial conversion from raw to jpeg.

[mrinmoyvk]

Now a days, memory cards and hard disks are cheap, computers with basic configuration are also enough fast to copy huge raw files.

I mean have a coffee break after you start copying the files from memory card to computer.

So one gets all the advantages of RAW + a refreshing coffee before a long editing session.

[xpatUSA]

This is just for fun.

With other discussions of raw vs. jpeg I thought I would try to work on an image to destruction and see what happens working in jpeg only. This is pretty extreme in the look of the changes but I only used contrast as a variable.

Working in raw, I could quickly have eliminated all of these effects.

That was most interesting. I use FastStone Viewer too - a fine program for the price of a small donation.

You didn't mention which of the many available JPEG settings you used - and there are a great many options!

For example, I could have saved it as JPEG RGB (not Y'CbCr) at 100% quality and not suffered much degradation at all

Noticeable in FastStone is that edits are cumulative and successive drastic edits can bring on artifactitis pretty quick!

[Manfred M]

Now a days, memory cards and hard disks are cheap, computers with basic configuration are also enough fast to copy huge raw files.

I mean have a coffee break after you start copying the files from memory card to computer.

So one gets all the advantages of RAW + a refreshing coffee before a long editing session.

If this is your work flow, I suspect that you are not getting the best results out of raw and are working under the premise that raw is going to get you better results all the time.

If you are shooting the same subjects under the same conditions, I would have no issues at all with your workflow. That being said, these conditions happen so rarely that I suspect this is not what is happening in for you. Examples of this type of "ideal" conditions would be shooting portraits in a studio; your lighting and subject material will be consistent from shot to shot.

If you are a real world photographer, then this is not what you are doing and the shooting parameters, lighting (quality, quantity and direction), exposure, subject matter will change from shot to shot. This means the tweaks required to the raw data will also vary from shot to shot.

When I shoot raw (and frankly I do so more often than I need to), I will manually adjust a lot of parameters, from lighting, to lens correction, to white balance, contrast, sharpness, etc. If I have a series of images shot under near identical conditions, then small batch processing will work fine. Frankly, I can't say I've ever done more than 40 or 50 shots under similar enough conditions to use this process.

Normally, my individual raw shots are hand tuned, especially for contrast, white balance and sharpness, while many of the other parameters could be automated. The jpegs coming out of the camera, especially for the run of the mill shots are often as good as I would get out of a raw file.

So, please continue to shoot and process the way you are, but I'm willing to bet your end results are likely suboptimal and may not meet the quality expected out of a SOOC jpeg.

[george013]

Manfred.
I don't understand this.

For instance a binary value of 127 is 100000000100110111111111 (mid-point of 8-bit channel)
whereas 2048 is 100000000100110111111111100000000000100000000000 (mid-point of 12-bit channel). Half of the data is gone in going from one to the other.

In a 8-bit notation 127 is 01111111. A neutral middle gray would be 3 times repeating for each channel. If 127 represents 50%, then in a 12-bit notation this will be 2048 being 0111111111111.
I don't know what data is gone. All the data is still there. Only the portions in which it's divided differs.

George

[Manfred M]

In Photoshop I have the option to edit in 8-bit, 16-bit and 32-bit mode.

The midpoint value of an 8-bit integer (range 0 - 255) is 128; the midpoint value of a 16-bit integer is (range 0 - 65535) is 32767.

So while the shade of the midpoint is identical, for a given colour space, the actual value assigned to that value will have a different discrete value, i.e. (128,128,128) may be the value of middle gray for 8-bit RGB, that integer value will represent a far darker gray for 12-bit, 14-bit, 16- bit, and so on.

The reason I showed the binary representation of the numbers was to illustrate the number of bits that are NOT stored when converting from a higher bit count to 8-bit; i.e. reduction in the file size.

[rpcrowe]

Now a days, memory cards and hard disks are cheap, computers with basic configuration are also enough fast to copy huge raw files.

I mean have a coffee break after you start copying the files from memory card to computer.

So one gets all the advantages of RAW + a refreshing coffee before a long editing session.

I have found that the speed of transfer between camera memory card and computer can be influenced by three different parameters:

Smaller files transfer more quickly

HOWEVER

The quality of the memory card has a lot to do with speed of download. My Lexar Professional 800x 16gb UDMA 7 CD cards are faster than slower cards in the transfer.

If I use a UDMA capable card reader such as my Lexar USB 3.0 Reader, the speed really increases at a noticeable rate - even when I am plugged into a USB 2.0 port (I don't have a USB 3.0 port) in my computer.

I am only guessing that a 3.0 port would make the download even faster...

[george013]

In Photoshop I have the option to edit in 8-bit, 16-bit and 32-bit mode.

The midpoint value of an 8-bit integer (range 0 - 255) is 128; the midpoint value of a 16-bit integer is (range 0 - 65535) is 32767.

So while the shade of the midpoint is identical, for a given colour space, the actual value assigned to that value will have a different discrete value, i.e. (128,128,128) may be the value of middle gray for 8-bit RGB, that integer value will represent a far darker gray for 12-bit, 14-bit, 16- bit, and so on.

The reason I showed the binary representation of the numbers was to illustrate the number of bits that are NOT stored when converting from a higher bit count to 8-bit; i.e. reduction in the file size.

I'm still not sure I understood you. If you try to explain that 3x8 is less than 3x12 and the difference is 12, then I think that's a rather difficult way.

George

[Manfred M]

I'm still not sure I understood you. If you try to explain that 3x8 is less than 3x12 and the difference is 12, then I think that's a rather difficult way.

George

I'm not trying to do that at all George, I'm trying to explain to people who are unfamiliar with computers as to how going from a higher bit count to a lower bit count reduces the amount of storage space required. The last time I checked a byte takes up half the storage as a word.

[MrB]

Although I am of average height, much of the mathematical/technical stuff here still goes over my head. But thanks to Manfred and others here and elsewhere, I have gained some understanding of the gist of the raw/JPEG discussions. However, they actually matter little to my reality, and I am happy attempting to make use of the camera's controls, features and firmware to capture and produce high quality JPEGs, happy knowing that it is certainly possible to edit those files to my desired image result, and happy to be able to store all my archived files (originals and edits) in about one third of the space and time needed for the equivalent raw files.

At the local camera club of which I am a member, the reality is that my photographs are usually comparable for image quality with those of other members, and there are many experienced photographers there. As Manfred has suggested in another thread, it is often not possible to tell who started with a raw file and who with a JPEG and, in my experience, that is certainly true at least up to the projected and printed photo sizes allowed in UK clubs. When a photo is judged not competitive, it is usually with regard to some artistic-vision and/or compositional aspects due to my limited creative ability, for which the raw-JPEG relativities seem to me largely irrelevant.

But to each his own.

Cheers.
Philip

[jcuknz]

The only way to do such a test properly is to use the 'undo' button following the save-as for display .. complete waste of time IMO. [ else reload the master file for each play ]

But it seems from what I read few people appreciate the value of the 'original negative/file' these days.

[george013]

I toke a raw in Capture and saved that several times. Capture allows me to choice a max quality of 100. I post them here in full size so you can compare them on your pc if you want. I only hope Picasa doesn't change things. I didn't check that yet.

So straight from a raw rasterfile, compression, size in pixels 4256x2832. The compression factor is added in the filename.

Compression factor 100, filesize 9.796.533



Compressionfactor 50, filesize 2.222.698


compressionfactor 10, filesize 1.480.027



I'm surpised myself, but here on the screen viewed at 100% I can't see a difference.

George

[Saorsa]

Until compression takes the resolution below that of your screen, it is going to be interpolated for display by your system.

For example, there are 1920x1200 displays. Lets round that to 2000x1500 and consider what happens with an image from a 4000x3000 sensor.

Unless you are going to pan around on the image, you need to eliminate some of those pixels to show the entire image on the display. So, you need to cut out half the pixels on the X-axis and half the pixels on the Y-axis. This is dynamically resizing the image without making any change to the original file.

That's really different from compression. A good compression algorithm should be able to recreate an image very accurately.

Try a right click on one of your images and save it with a new filename to your disk and then compare it to the file you uploaded. I'm pretty sure you will see a difference in IQ if you examine them side by side. I just did it with my first LBH image which was resized from 1024x1024 to 700x700 for the forum here expanding that back to 1024x1024 produces a lower quality image.

[george013]

Until compression takes the resolution below that of your screen, it is going to be interpolated for display by your system.

For example, there are 1920x1200 displays. Lets round that to 2000x1500 and consider what happens with an image from a 4000x3000 sensor.

Unless you are going to pan around on the image, you need to eliminate some of those pixels to show the entire image on the display. So, you need to cut out half the pixels on the X-axis and half the pixels on the Y-axis. This is dynamically resizing the image without making any change to the original file.

That's really different from compression. A good compression algorithm should be able to recreate an image very accurately.

Try a right click on one of your images and save it with a new filename to your disk and then compare it to the file you uploaded. I'm pretty sure you will see a difference in IQ if you examine them side by side. I just did it with my first LBH image which was resized from 1024x1024 to 700x700 for the forum here expanding that back to 1024x1024 produces a lower quality image.

You can download the full resolution but you have to do some tricks.
Click on the image, then right click on the image again, select "view image". In the adress-bar just before the image name, you see a s-code. In my case s1152. Change that in s0, zero, and click. Now the original image is viewed. First at window-size, than at 100%.
Don't blame me.. It's Picasa.

George

[Manfred M]

Brian - interpolation goes both ways; upsampling and downsampling, which is just a fact of life as what our camera takes and what our screen (or print) displays will almost never match exactly. So we are either temporarily "throwing away" pixels when we downsample, which tends to "sharpen" our images. When we upsample we are adding new pixels which which tends to soften the image. This is of course the reason that the "experts" tell us to perform certain operations like sharpening at a 100% view, as this eliminates the up / down sampling of the image we are viewing from impacting our decision.

Your example shows the downside of destructive editing; once the pixel has been thrown away, it can never be recovered and even sophisticated software is going to result in a marginal image when you try to upscale again.

George: Your results are similar to what I got and I went a step or two further. I did around 25 saves of the image and then in Photoshop took the original image and the multiple save image and put them in separate layers. I inverted one of the images and used the difference blending mode to pull out the differences between two full size jpeg images. I then expanded to 100% and then 400% looking for differences between the two images. I found no artifacts at all. The images were identical at a pixel level, so far as I could tell. To be frank, this surprised me too.

I think it may come down to the compression algorithms; some are simply better than others and using the one built into Photoshop, I saw NO changes across many generations of resaved jpeg images.

[Saorsa]

Yes, I was just using that as an example of resizing.

[xpatUSA]

This is just for fun.

With other discussions of raw vs. JPEG I thought I would try to work on an image to destruction and see what happens working in JPEG only.

What JPEG settings did you use in FastStone Viewer?

EXIF in one of your OP images says YCbCr 4:2:0 (2 2) but that doesn't tell us the %quality selected, etc. Which means that we don't how much theoretical "destruction" was applied.

[Saorsa]

What JPEG settings did you use in FastStone Viewer?

EXIF in one of your OP images says YCbCr 4:2:0 (2 2) but that doesn't tell us the %quality selected, etc. Which means that we don't how much theoretical "destruction" was applied.

I don't often change that. It was at 98% Modified Huffman

[xpatUSA]

I don't often change that. It was at 98% Modified Huffman

Thanks. It looks like you also had the "worst" color sub-sampling method selected (high).

I usually use 'disabled', being a purist