Resolution vs. compression

[Livingston]

I just bought a G6. What a toy!!!

I am somewhat familiar with digital photography and image processing, but mostly the basics. The G6 has settings (still) for both resolution and compression. I think I understand resolution but the compression stuff confuses me a little.

I think I understand the resolution settings. My assumption is that this setting adjusts the pixel density on the image being stored on the card. I hesitate to use terms like "pixels per inch" but that's as close an analogy I can come up with. My assumption is that the processor in the camera is doing something like taking areas of the image and resolving them to a greater or small number of pixels based on the resolution setting. In a sense there is some compression being done based on this setting.

Now, looking at the compression settings (3 of them) I'm assuming that further compression is being done to the resultant data but that's where I lose it. Since all images are stored as JPEG (unless I use RAW) does the compression setting coorespond to different JPEG compression algorithms? Or is there something else going on here?

Also, does the processor first deal with resolution and then with compression?

Thanks

[Mannytkd]

MMmmm, i'm lost here, i set mine to RAW and have done with, unless i'm in super-macro??

[Bosman]

Resolution is the number of pixels.
Compression is the quality of the image.

[dbump]

Welcome to the board!

You raise an interesting question. The in-camera processing must be resizing the image on the fly, when it saves the file. I would hope that it would do that prior to JPEG compression, to reduce any artifacts and quality loss.

So to expand a bit, the resolution setting affects the number of pixels that are saved to the CF card. Typically you'd only change this if you know you're ONLY going to use the image at a specific resolution (web use, say), or if you're really really cheap, and are using the 32MB card that came with the camera :) Otherwise, you'd shoot at full resolution, and resize images on your computer, as needed.
The compression setting does correspond to the 'quality' option in JPEG compression. I don't know that anyone has posted a direct correlation to the normal 1-12 quality range presented in most applications, but it's roughly equal to maximum, high, and medium, I believe.

So, the first operation, resizing, is totally different from JPEG compression, even though it is reducing the amount of data. I imagine it's resampling the RAW data to the new resolution. Afterwards (we hope) the camera then applies JPEG compression, which is also discarding data, but in a very different way. There are a lot of great articles on the web about JPEG if you're curious about the nitty gritty, but it's trying to throw away data that your eye will notice the least.

Hope that was coherent...

[John from PA]

Basically you want to shoot with best resolution and minimum compression. This will insure the very best quality shot in the original, short of shooting in RAW mode. On my G2 this means that a 256 meg card can deliver about 121 pictures, roughly 2 meg per shot. If the basic quality isn't in the upfront original there isn't any way to get it later! Memory cards are cheap!-

When you work in Photoshop or whatever, always work with a copy of the original. That way no matter what you do you can revert to the original. Also, unlike working in say MS Word you do not want to do a File, Save prior to attempting something. We tend to get in this habit in MS Word or Excel because if we don't like what we get we can always go back to the last step. However, in virtually all photo editing software that works in JPEG, each "save" operation does more compression, thus losing overall quality. I once went to a Nikon Digital Photography School (1 day, highly recommended) and the instructor did a demonstration by photographing a "state" quarter with side lighting. The original was stuning! He then did succesive saves and by about the 6th to 8th save you could not tell that it was a quarter.

[Nidz]

I would shoot at highest resolution and then use the pc to compress the image. Then you have full control over everything. Time to invest in a few gigs of memory.

[Robert_Lay]

You are correct about the meaning of "resolution" (also known as "size") - it is the number of pixels in the image. The greater the resolution the more detail is captured in the image.

When you choose a resolution in the camera menu, that decides the way the camera works from then until you change the resolution. Everything that takes place from the moment you begin a shot until it is finished is already determined by the resolution setting.

You are also correct about compression. The more compression is applied, the lower is the quality of the resulting JPG. Again, once the compression is chosen in the menu, all pictures from then until it is changed are processed at that setting. Once the picture is taken all of the sizing and compression processing follows the pre-determined settings.

None of the above applies to RAW.

[Livingston]

Thanks all. Let me go back to my original question and clarify a little since, in spite of the good posts, they didn't address what I was looking for.

I'll start with my first assumption: With the exception of RAW all images are stored by the G6 as JPEG. In other words, I'm assuming that the camera never saves images as a TIFF or, for that matter, any other format. Therefore, I'm wondering if the compressions coorespond to algorithms like JPEG-1, JPEG-2 and ???

L

[dbump]

You're correct, RAW and JPEG are your only choices (except for movie mode, which saves in AVI).
The three compression settings do not correspond to different versions of JPEG, no. As far as I know, the G only supports the original JPEG spec. Instead, those settings correspond to the amount of compression applied within that original JPEG spec.
Was that more on target?

[Bryan Bedell]

I don't think the "1" or "2" JPEG-1 and JPEG-2 refer to amount of compression, but rather to updated standards. Some software assigns names or numbers to different amounts of compression, but AFAIK there aren't any standards across hardware, software, or operating systems. Photoshop has a slider from 1-12, and I've seen other programs that only give you three options, or four. There are many parameters that can be changed, and different programmers or manufacturers use different combinations of parameters to get the compression they want. So if you're asking "does Canon's "Super Fine" setting correspond to "10" in photoshop or "High Quality" on a Fuji camera?" I don't think there's any official relationship there, they use different algorithyms.

Note that Photoshop gives you far more control over how the image is compressed than any in-camera software, which is why most serious photographers prefer to shoot in RAW. I'm a hack, so "Super Fine" generally serves my needs unless I'm doing something really important. I would never use any of the other settings, there's no point (some would argue there's no point in shooting anything other than RAW), if I'm in a pinch and need to save card space, I'd shoot at a lower resolution, rather than using more compression.

[Robert_Lay]

I don't think the "1" or "2" JPEG-1 and JPEG-2 refer to amount of compression, but rather to updated standards. Some software assigns names or numbers to different amounts of compression, but AFAIK there aren't any standards across hardware, software, or operating systems. Photoshop has a slider from 1-12, and I've seen other programs that only give you three options, or four. There are many parameters that can be changed, and different programmers or manufacturers use different combinations of parameters to get the compression they want. So if you're asking "does Canon's "Super Fine" setting correspond to "10" in photoshop or "High Quality" on a Fuji camera?" I don't think there's any official relationship there, they use different algorithyms.

Note that Photoshop gives you far more control over how the image is compressed than any in-camera software, which is why most serious photographers prefer to shoot in RAW. I'm a hack, so "Super Fine" generally serves my needs unless I'm doing something really important. I would never use any of the other settings, there's no point (some would argue there's no point in shooting anything other than RAW), if I'm in a pinch and need to save card space, I'd shoot at a lower resolution, rather than using more compression.

Dear Brian

Please don't take this as criticism of your approach. Whatever is right for you is good.

However, I would like to suggest an alternative with some basis in fact. I have conducted very thorough tests on the question of whether to reduce resolution instead of using more compression or to stick with the higher resolution and use the minimum compression. All of my tests indicate that the latter is better in the long run for the reason that the compression is more successful at maintaining a quality image than reducing the number of pixels. The problem seems to be that once the number of pixels is decreased, pixellation becomes dominent very quickly, whereas with compression the algorithms are designed to first remove those aspects of the detail that are "least noticed" by the eye/brain processing. In many cases, the nature of the image itself is such that substantial reduction in file size is possible with virtually no loss. Try experimenting with it and I'm sure you will be surprised.

[dbump]

Robert,
I'm curious if you also looked at file size? I'm guessing that you'd see more space savings by increasing compression than by reducing resolution (depending on the complexity of the image, of course), but I haven't tested that guess.

[Bryan Bedell]

However, I would like to suggest an alternative with some basis in fact.

Ha! yes, i should probably stop talking out of my butt, but I'm addicted to talking about things I know nothing about on the internet.

Yes, your results surprise me, but they make sense.

Bryan

[Robert_Lay]

Robert,
I'm curious if you also looked at file size? I'm guessing that you'd see more space savings by increasing compression than by reducing resolution (depending on the complexity of the image, of course), but I haven't tested that guess.

Dear dbump,

I don't know of any fair way to make such a comparison.

My tests were designed to use two different approaches to bring the end file size to the same number of kilobytes. In those tests keeping the resolution at Superfine (largest resolution) and using whatever amount of compression was necessary to obtain that file size always gave a better looking image than the image obtained through a reduction in resolution accompanied by highest quality compression.

Remember, in the JPG output as used by Canon cameras, there is a significant amount of compression, even at the highest quality setting.

[Livingston]

To all:

Excellent! This is exactly the conversation I was hoping to get started. I know it's a little "geeky" to get into this level of technology, however, I've found, at least for myself, that understanding the details behind compression, resolution, etc. have made it easier for me to make the right decisions when actually using a digital camera particularly when linked to an understanding of the intended use of the images taken.

Bryan: Thanks for the post on comparing different compression settings in different cameras and in Photoshop. The slider there was creating the same questions for me. All the more reason to get this understood (again, at least for me). All these proprietary and/or unique techniques can be very confusing.

Ultimately, each user has to get comfortable with all the steps that will affect output quality. And each step involves different hardward and software. In my case, it's the G6, to an image processor (Photoshop and the one that comes with the G6), to the output devices (HP Photo printer or computer display for our web images).

I'm a little pressed for time right now, so I'll have to come back for my follow up questions and summaries of what's been said so far. What's been posted so far is helping me get a flow from real object through the G6 to the output media (print, display, etc.) in mind.

Thanks

L

P.S. Based on the math I'm using it looks like RAW also does some compression before storage even though the compression used is lossless.

[Robert_Lay]

To all:

Excellent! This is exactly the conversation I was hoping to get started. I know it's a little "geeky" to get into this level of technology, however, I've found, at least for myself, that understanding the details behind compression, resolution, etc. have made it easier for me to make the right decisions when actually using a digital camera particularly when linked to an understanding of the intended use of the images taken.

Bryan: Thanks for the post on comparing different compression settings in different cameras and in Photoshop. The slider there was creating the same questions for me. All the more reason to get this understood (again, at least for me). All these proprietary and/or unique techniques can be very confusing.

Ultimately, each user has to get comfortable with all the steps that will affect output quality. And each step involves different hardward and software. In my case, it's the G6, to an image processor (Photoshop and the one that comes with the G6), to the output devices (HP Photo printer or computer display for our web images).

I'm a little pressed for time right now, so I'll have to come back for my follow up questions and summaries of what's been said so far. What's been posted so far is helping me get a flow from real object through the G6 to the output media (print, display, etc.) in mind.

Thanks

L

P.S. Based on the math I'm using it looks like RAW also does some compression before storage even though the compression used is lossless.

Very observant! Yes, the compression method used is lossless - just as is a file compression progam like WinZip. Were it not for compression, an 8 MP camera would generate RAW files of 8 MP x 2 bytes per channel x 3 channels = 48 MB. Wow!

[Livingston]

Hi Bob

Thanks for continuing to monitor this thread.

Part of what I'm interested in is the math. My understanding is that the G6 is a 24 bit camera meaning that it takes 24 bits to represent each pixel. (I used to know what the bits were being used for, but... I think 3 of them were RGB but the rest escapes me. Regarless...). This means that, before comression, in the G6 an image with a resolution of 3,072 x 2,304 is 7.077MP (thus the 7MP rating for the camera). If you multiply this by 24 you get 169,869,312 bits per image. Divided by 8 (bits/byte) gives 21,233,664 bytes or (divided by 1,024) 20,736 KB. (Not sure where you got the 48 MB in your post although it's not important).

If you look in the user manual near the back (p199 in mine) the Image File Size estimate for a RAW file is 7,096 KB. If my math is right, this is a compression ratio of 2.92 or about 34.2% meaning that the file is stored in 34.2% of the uncompressed space.

Before extrapolating the calculations to the other resolution/compression settings, is this the algorithm you understand? If right, the compression technique used in the G6 will eliminate 2/3 of the data for RAW files losslessly.

Am I missing something?

Again, this is more geeky than needed but I find these "gee whiz" numbers to be helpful as a basis for understanding the end-to-end flow.

Livingston

EDIT: Ran the numbers for L Resolution and got compressions of 14.7%, 9.1%, and 4.3% respectively for superfine, fine, and normal compressions. If I have the math right, the G6 comresses out over 95% of the data for Large-Normal images and over 85% for Large-Superfine images.

[dbump]

Livingston,
Keep in mind that the JPEG compression will vary extensively based on the content of the image. Broad areas of similar color (clear sky, for example) will compress at a very high ratio. Areas of high contrast and detail will compress less well. I've noticed in the past that my pictures of the moon (taken in JPEG) are tiny compared to the rest of my files.
For a quick test, I took two sets of four pictures. Each set was Raw, and then L/Superfine, L/Fine, and L/Normal. The first set was of a somewhat detailed magazine cover. The second was the blank white face of my fridge (I said it was quick). The two RAW files were nearly identical size (6,716KB and 6,820KB), but sizes diverged quickly after that: Superfine: 3,634KB & 1,988KB; Fine: 2,098KB and 1,034KB; Normal: 1,009KB and 320KB.

[Livingston]

DBase
Good tests. I used to work (a long time ago) on compression software for large scale computers and understand that one of the keys is contiguous, duplicate data so the results you saw are not surprising. Sounds like things haven't changed much over the years.

If my calculations are right, the compression has gotten quite efficient (at least in the G6) over the years.

L

[Robert_Lay]

Hi Bob

Thanks for continuing to monitor this thread.

Part of what I'm interested in is the math. My understanding is that the G6 is a 24 bit camera meaning that it takes 24 bits to represent each pixel. (I used to know what the bits were being used for, but... I think 3 of them were RGB but the rest escapes me. Regarless...). This means that, before comression, in the G6 an image with a resolution of 3,072 x 2,304 is 7.077MP (thus the 7MP rating for the camera). If you multiply this by 24 you get 169,869,312 bits per image. Divided by 8 (bits/byte) gives 21,233,664 bytes or (divided by 1,024) 20,736 KB. (Not sure where you got the 48 MB in your post although it's not important).

If you look in the user manual near the back (p199 in mine) the Image File Size estimate for a RAW file is 7,096 KB. If my math is right, this is a compression ratio of 2.92 or about 34.2% meaning that the file is stored in 34.2% of the uncompressed space.

Before extrapolating the calculations to the other resolution/compression settings, is this the algorithm you understand? If right, the compression technique used in the G6 will eliminate 2/3 of the data for RAW files losslessly.

Am I missing something?

Again, this is more geeky than needed but I find these "gee whiz" numbers to be helpful as a basis for understanding the end-to-end flow.

Livingston

EDIT: Ran the numbers for L Resolution and got compressions of 14.7%, 9.1%, and 4.3% respectively for superfine, fine, and normal compressions. If I have the math right, the G6 comresses out over 95% of the data for Large-Normal images and over 85% for Large-Superfine images.

I think your interpretation of the G6 internals is different from mine. I don't know from where you got the idea of it being a 24 bit camera. I could believe that it is actually a 12 bit camera. You will probably never know because I have looked everywhere and never found a definitive answer. These numbers that we are talking about are the number of bits used for each of the three channels - R, G, & B.

After conversion to JPG from RAW, those 12 bits of data are scrunched down to 8 bits/channel, and since there are 3 channels, that's probably where you got the idea of 24 bits. In fact, it's 24 bits per pixel in either JPG or any 8 bit/channel format except CYMK, which is probably never provided from any camera.

I should like to further clarify that that is independent of compression. In other words compression does not change that 24 bit per pixel value - that's fixed unless you go into image processing and raise it from 8 bit mode to 16 bit mode, in which case you now have 48 bits per pixel.

So, if you now do your calculation over again using that information, you will get different numbers.

BTW, my guess as to there being 12 bits/channel in RAW is partly based on Bruce Fraser's book in which he explains that the 16 bits per channel that are used for storing RAW data actually use only 15 bits in order to keep the middle gray value unambiguous (you'll have to accept that for the moment unless you want to get into the theory of binary values). However, he then goes on, as others have done in their real world examples, to imply that there are in fact only 12 bits in the actual A/D conversion from the sensor. You could well ask why it is that in Photoshop the 16 bit mode goes from 0 to 32767, and all I can say to that is that it is displayed that way, but there really is not that number of discrete steps in the A/D converter. If someone from Canon would simply step up to the plate and disclose what it really is, it would be welcome, but don't hold your breath.

In conclusion, when you re-derive your numbers for the lossless compression I think you will have somewhat different values, and the only other thing I would leave you with is that the compression used in RAW is the LZW algorithm, which is lossless and is akin to the well known Zip compression algorithms. BTW, there is an interesting history about these algorithms and who is the actual inventor, involving Philip Kahn. You may remember that Zip was referred to as PKZip in the early days. Now you know why.

[dbump]

Livingston,
For some more geeky info, check
http://www.shortcourses.com/pixels/sensors/0-sensors.htm
I just ran across it, and it's pretty interesting.

[Livingston]

Excellent Bob.

I'm not challenging your math and logic, just want to understand.

Let's go back to basics (where I need to start to make sure I'm following). Feel free to correct my logic.

A pixel has 3 color "channels" for RGB and each color can have 256 values and stored in 1 byte. This means that there can be over 16 million different colors (256 cubed) which can be represented by 3 bytes. So an 8-bit scheme uses 3 bytes per pixel. I believe these are sometimes called 24-bit color images. My understanding is that there are also 36-bit color images (3 12-bit values) and 48-bit color images (3 16-bit values) which use 4.5 bytes and 6 bytes respectively.

If it's safe to assume that the G6 is a 24-bit camera it would use 3 bytes to store each pixel of an uncompressed image. So, at 3072 x 2304 resolution, an image has 7+ mega pixels at 24 bits each or 169+ megabits or 21+ megabytes or 20,736KBytes. Since the G6 user manual says it will store this image in RAW format in 7,096KB the image is compressed to 34.2% of it's original size which doesn't seem to bad to me for lossless.

Am I missing something in my math somewhere?

Thanks again for your responses. It is helping me get this right in my head.

Livingston

[Livingston]

Livingston,
For some more geeky info, check
http://www.shortcourses.com/pixels/sensors/0-sensors.htm
I just ran across it, and it's pretty interesting.

DBump

Excellent! I also found a good basic one here.

http://www.photo.net/equipment/digital/basics/

Thanks

My point in continuing the thread is that I have struggled to get this basic knowledge in my brief digital camera experience and obviously still need to go over it to get it down. I'm assuming others face the same challenge.

I recognize that this means nothing if you don't hold the camera still, but....

[Robert_Lay]

Excellent Bob.

I'm not challenging your math and logic, just want to understand.

Let's go back to basics (where I need to start to make sure I'm following). Feel free to correct my logic.

A pixel has 3 color "channels" for RGB and each color can have 256 values and stored in 1 byte. This means that there can be over 16 million different colors (256 cubed) which can be represented by 3 bytes. So an 8-bit scheme uses 3 bytes per pixel. I believe these are sometimes called 24-bit color images. My understanding is that there are also 36-bit color images (3 12-bit values) and 48-bit color images (3 16-bit values) which use 4.5 bytes and 6 bytes respectively.

If it's safe to assume that the G6 is a 24-bit camera it would use 3 bytes to store each pixel of an uncompressed image. So, at 3072 x 2304 resolution, an image has 7+ mega pixels at 24 bits each or 169+ megabits or 21+ megabytes or 20,736KBytes. Since the G6 user manual says it will store this image in RAW format in 7,096KB the image is compressed to 34.2% of it's original size which doesn't seem to bad to me for lossless.

Am I missing something in my math somewhere?

Thanks again for your responses. It is helping me get this right in my head.

Livingston

Dear Livingston,

I know that there are also 48 bit images, as you describe above, because my scanner can produce them and Photoshop can process them. As to the 36 bit images, I cannot say one way or the other. It could be, but I would seriously doubt that any popular software is available for generating or processing them. Anyone who can speak to that issue should chime in.

Regarding the compression of RAW and the nominal figure of 34.2% - You are quite correct that such a compression ratio is quite good for a lossless compression scheme. However, I think that the "actual" percentage is very dependent upon the nature of the scene. Actually, your user's manual for the G6 has quite a bit more to say about RAW than does my G5 manual. Your manual even claims that the compressed file can be as low as one-quarter of an uncompressed file.

[Livingston]

I think I finally have this figured out enough to move from the math to a less geeky discussion. Here's what I've concluded so far:

In a 24-bit color image, a pixel has 3 color channels, one each for Red, Green, and Blue, and each can have a value up to 256 or a total of over 16 million colors (256 cubed). This means a pixel in a 24-bit color image camera can be stored in three 8-bit bytes or 24 bits.

Technology also allows for 36 bit (3x12bits) and 48 bit (3x16 bits) equipment.

In the Canon G6:

RAW compresses about 3:1 losslessly.

640x480 compresses about 4:1, 6:1, and 11:1 lossy based on compression setting.

All other resolutions compress about 6:1, 11:1, and 21:1 lossy based on compresssion setting.

Actual compression is dependent on the specific image being stored. Generally, the more consistent the color in the image the greater the compression.

Obviously the real issue is how much data I need to store for the intended use of the images. The resolution will depend on 1) the intended output media to be used (paper, display), and 2) the amount of blow-up (or actually more importantly in my case, the amount of cropping-and-the-return-to-original-image-size I will be doing.

So, my next question is how resolution and compression are actually related to the final image. I'm assuming that blowing up an image too much will have the affet of placing the pixels too far apart. Is that right? When I zoom in on an image eventually I can see the actual square pixels. So resoluition, if I get this right, will ultimately deal with pixel density when the image is translated to an output device like a printer or display.

What's the affect of compress on the output image. I'm assuming compression, in a way over-simplifed sense, is removing actual data and, when the image is brought back for output, decompression makes some assumptions about what the pixels "should" be. When will I see the impact of compression on the final image and what will it look like? Will the affect be on color definition more than "grain" like resolution issues will create?

Thanks

Livingston

[dbump]

Livingston,
You might enjoy Vincent Brockaert's 123 of Digital Imaging (an e-book/tutorial):
www.123di.com
He goes into a lot of detail about both questions--he has specific example images at different compression ratios that make the difference plain.
I got it as a gift, and I loved it. It satisfied my geeky side.

Anyway, back to your questions:
You're right--resolution is entirely about pixel density. When you're printing, you want to ensure you have a certain number of pixels per inch (typically 300 ppi, but that varies with the size and planned viewing distance from the print). With modern cameras, you usually have more pixels than you need for on-screen display, but the same principle applies--obviously when you zoom in to 400%, your pixels per inch drops way under 100.

One area you'll notice compression as a problem is in a loss of fine detail, especially sharp contrast on edges in fine detail. JPEG compression examines the pixels in a small square (say 8x8 pixels), compares their color values to each other, and then evaluates the color values of the squares surrounding that square. Based on all that, it will replace the color values for all of those pixels with new values that will provide a smooth transition, and generally look like the original values, but can be represented by fewer bits. That's a crude, and probably hideously inaccurate summary, but I think it gives you the idea. In a way, JPEG compression is like converting lots of small pixels into larger ones. The advantage it has over simply reducing the resolution, is that it tries to only make pixels "bigger" in areas where your eye won't notice, like wide expanses of sky, or skin, etc.

A common concern with this is that any photo editing you perform can accentuate the changes that JPEG has made, to the point where those alterations are noticeable. If you're not editing, and you're not enlarging past 8x10, this is less likely to be a problem, but it's one reason for shooting in RAW, and then manipulating the image in a non-lossy format until you're completely finished, and only then converting it to JPEG. Or opening the jpeg, and not re-saving it (re compressing it) again until all changes are finished.

[Robert_Lay]

I think I finally have this figured out enough to move from the math to a less geeky discussion. Here's what I've concluded so far:

In a 24-bit color image, a pixel has 3 color channels, one each for Red, Green, and Blue, and each can have a value up to 256 or a total of over 16 million colors (256 cubed). This means a pixel in a 24-bit color image camera can be stored in three 8-bit bytes or 24 bits.

Technology also allows for 36 bit (3x12bits) and 48 bit (3x16 bits) equipment.

In the Canon G6:

RAW compresses about 3:1 losslessly.

640x480 compresses about 4:1, 6:1, and 11:1 lossy based on compression setting.

All other resolutions compress about 6:1, 11:1, and 21:1 lossy based on compresssion setting.

Actual compression is dependent on the specific image being stored. Generally, the more consistent the color in the image the greater the compression.

Obviously the real issue is how much data I need to store for the intended use of the images. The resolution will depend on 1) the intended output media to be used (paper, display), and 2) the amount of blow-up (or actually more importantly in my case, the amount of cropping-and-the-return-to-original-image-size I will be doing.

So, my next question is how resolution and compression are actually related to the final image. I'm assuming that blowing up an image too much will have the affet of placing the pixels too far apart. Is that right? When I zoom in on an image eventually I can see the actual square pixels. So resoluition, if I get this right, will ultimately deal with pixel density when the image is translated to an output device like a printer or display.

What's the affect of compress on the output image. I'm assuming compression, in a way over-simplifed sense, is removing actual data and, when the image is brought back for output, decompression makes some assumptions about what the pixels "should" be. When will I see the impact of compression on the final image and what will it look like? Will the affect be on color definition more than "grain" like resolution issues will create?

Thanks

Livingston

Dear Livingston,
Sorry that I have out of town for the last 36 hours and am just getting back to this thread.
I still cannot personally confirm any concrete example of a 12 bit per channel system, although there is no reason why they would not be possible and practical.

Yes, the G6 manual mentions as extreme as 4:1 (it says the file can be as low as 25% of the virtual image size).
I take your word for it on the compression ratios of the lossy methods, such as JPG - I've never tried to quantify them precisely, because it is so depedent upon the nature of the original image. As you said, some images contain a lot of information and some have almost none. A solid red field of the exact same tonal value has virtually no information and one could imagine the resulting file size as being quite small.

An interesting issue would be the question of why the larger size images (in terms of pixel count) can be compressed in greater ratios than small files. I think it has something to do with the way in which the algorithm clusters the pixels. and the fact that a small sized image has a small amount of information (potentially), and a large image has a large amount of information (potentially). I suspect that the more information (absolute) we have, the higher is the potential for removing the redundancies - just a guess - information theory is not my forte'.

Regarding the effect of printing or displaying an image at a size larger than its resolution can support. You describe it as pixels being too far apart. Another way of describing the exact same issue is to describe it as pixels becoming too large or blocky. When you have a small size image and you fill your screen with it, you are going to see the individual pixels. However, when you do the same thing with the printer, the printer driver tries its best to interpolate to fill in the missing data - so the effect can be quite different from just zooming in on an image on the screen. The printed image might just become more soft.

It's very difficult to describe the artifacts that can arise during decompression of a highly compressed image, because it is very dependent upon the image itself. When you run tests on this issue, you can easily identify posterization when it occurs because the finer gradations in shade or tonality of a given color are lost and the result is noticeable bands of color in the exact same shade. I am not experienced in describing other artifacts that may occur, but I have found that as compression gets too high, the posterization is the first thing that I notice.

I heartily recommend doing your own experiments by starting with an image of 1024 x 768 and then compress it to JPG as far as Photoshop will allow (0 quality), and also compress it to JPG with quality of 12. Look at the two images in any viewer at a magnification of 300% and you will be appalled at the difference.

[Livingston]

This has been a great thread to get this figured out. Thanks to all and a quick nod to bdump and Bob.

The thread has moved in the direction that's truly important: what compression and resolution do to the output image (the ultimate objective after all) which means when they are printed or displayed.

I assume everyone does final editing in some post-processing software (I happen to have PhotoShop Elements 2). The settings that seem to deal with this stuff is in the File/Save For Web command where file format, compression and resolution appear to be some of the adjustments. I think I heard somewhere that all image processing software tends to desl with compression using a scale of somekind (quality) and the resolution is actually set specifically (in Elements I can set the exact pixel count in each dimension).

So to get to something like 300ppi (I assume that's what I read here about print output) I need to know the Image Size and the number of pixels in each dimension. Do I have that right?

[Robert_Lay]

This has been a great thread to get this figured out. Thanks to all and a quick nod to bdump and Bob.

The thread has moved in the direction that's truly important: what compression and resolution do to the output image (the ultimate objective after all) which means when they are printed or displayed.

I assume everyone does final editing in some post-processing software (I happen to have PhotoShop Elements 2). The settings that seem to deal with this stuff is in the File/Save For Web command where file format, compression and resolution appear to be some of the adjustments. I think I heard somewhere that all image processing software tends to desl with compression using a scale of somekind (quality) and the resolution is actually set specifically (in Elements I can set the exact pixel count in each dimension).

So to get to something like 300ppi (I assume that's what I read here about print output) I need to know the Image Size and the number of pixels in each dimension. Do I have that right?

Sorry for the delay in responding - getting my son out of jail was more important for a couple of days - Hi!

Here's a real world example of assuring that your image resolution (size) is adequate to the purpose. Assume a virtual image of 2592 x 1944 pixels. The current settings for dpi and size in inches are irrelevant. We also decide for purposes of numeric example that our desire is to print an 8" x 10"

You decide that you want to print that image on a printer for which the consensus of opinion is that it should have enough image detail to support 300 dpi (remember, the recommendations for various types of printers vary considerably). Also, accept that the issue here is NOT that the file be tagged with any particular DPI value or printed size value in inches. The issue is whether or not the virtual image file has the necessary depth of detail to be printed at the target size.

Our first task is to reconcile the different aspect ratios (1.333:1 for the virtual image and 1.25 for the print. That requires us to either trim some whitespace from the long sides of the print or crop the image to fit the 8 x 10. For purposes of the example, we take the latter option and crop the image to 2430 x 1944 pixels.

Now we test for sufficiency of detail information by dividing 2430 by 10" and get 243 dpi. Likewise we divide 1944 by 8" and get 243. We are in trouble in both dimensions. the DPI or pixels per inch are inadequate for an 8 x 10. We have several choices - none of which will involve tagging the file with a DPI value or a dimension in inches.

All we have to do is decide which of the 3 options are acceptable:
a) Shrink our desired print size.
b) Resample upwards to artificially (through interpolation) create a higher information density in the virtual image. This would require upsampling from 2430 x 1944 to 3000 x 2400 pixels.
c) We can go ahead with the print to 8" x 10" dimensions using File->Print with Preview

Just to show how easy the worst case scenario is, we choose (c), Print with Preview.
In the dialogue for Print with Preview we note that there is nothing required about pixels or dpi - we just key in the size in inches, and the printer prints it that size. The printer does whatever upsampling is necessary.

Alternatively, if we chose (b), we could use Image-> Image Size and enable resampling and key in the desired pixel dimensions. However, the printer driver is equally capable of doing that automatically.

There is no need to consider (a) unless we are so far off the mark in terms of recommended information content that we conclude that we should shrink the print in order to guarantee high print quality. The recommended shrinking would of course be whatever is necessary to get the dpi up to the recommended value of 300.

Please note that I did not address any of this to "Save for Web". That is an entirely different issue in which the picture is arbitrarily tagged at 72 dpi when you choose the JPG format. Again, the dpi is irrelevant, but you can't fight city hall. The important thing in sizing for the Web is that the picture shown in the Web browser will be whatever size is determined from the number of pixels and the resolution of the screen it is shown on - regardless of anything else.

[Robert_Lay]

I have to add a footnote here relative to my earlier comments on RAW (CRW) files.
Fortunately, we did not discuss RAW files at length and actual numbers were only mentioned in a couple of my messages. However, I think I have made some mistakes in regard to the size of RAW files before they are compressed. One of my colleagues and I were discussing this a couple of days ago, and I suddenly realized something that I was analyzing incorrectly.

RAW files contain the RAW data for each individual sensor site (for example, each of the 5 million individual sensors of a 5 MP camera). However, each of those sensor sites is equipped with either a Red, Green or Blue filter - not all three. There are only a total of 5 million such sites in a 5 MP camera.

Contrary to what I said in an earlier post there are NOT 5 million sensor sites, each having three channels.

The amount of A/D converted data for each sensor site is probably 12 bits (that's a reasonable guess), and the internal processing that converts this data to a JPG format creates 5 million virtual pixels, each of which has 3 channels - one for each of the primary colors.

(After the RAW data is processed for demosaicing and also processed for gamma correction, the resulting JPG file has an 8 bit depth for each of those three channels. If you work on those numbers a bit, you can deduce that the amount of data seems to have almost doubled in the process.)

So, in calculating the lossless compression being applied to create the RAW file from the actual A/D converted data, I told you that there was three times as much uncrompressed data as there really is. The consequence of that error is that the compression ratios that we were calculating must be grossly in error.

In other words, we cannot quibble about the amount of compressed data in the RAW files - that is stated clearly in the user's manual, and we know from practical experience that the RAW files are of the sizes indicated in the manual. If I have the correct understanding of exactly what data is being recorded in the RAW file for each of the sensor sites, then it would be 5 million sensor sites (for a 5 MP camera) times 12 bits per sensor site, or 60 million bits, or approximately 7.5 million bytes (7.5 MB).

If that is the case, then there is really very little compression in a RAW (CRW) file, because in the case of my 5 MP camera, the CRW files are roughly 5.4 MB.

I'm sorry if I have confused you on this point, but I have to go with my best understanding of the numbers in front of us, which includes some guesses. Specifically, we are guessing about the A/D conversion being 12 bits. Second, none of us can say exactly how the various manufacturers process their RAW data in the demosaicing process and in the gamma correction process - such things are kept proprietary.

[Bryan Bedell]

Heh, I thought that was wrong, but with all the nerdery going on way over my head in this thread, i didn't dare correct you.

[lefturn99]

This is all pretty interesting. 24 bit, 48 bit.

When I process my RAW files in Elements 3, I have the ability to save the result as an 8 or 16 bit file. I've heard that professionals use the 16 bit format because it caprures more dynamic range. But I've read somewhere that the camera captures a 12 bit image, so if you save as 8 bit you are discarding information, whereas if you save as 16 bit the software must be interpolating. My poor eyes and uncalibrated monitor can't tell the difference except I can load a few 16 bit pix and slow my 1 gig 'puter down.

Apparently we are speaking apples and oranges here.

[dbump]

Definitely apples and oranges. Here's a good summary of bit depths:
http://www.luminous-landscape.com/tutorials/bit-depth.shtml

My understanding is that the most cameras capture 12 bits of data, which can be saved as RAW, or converted to an 8 bit Jpeg. Obviously you have a lot more dynamic range with the 12 bit data. Often, you end up converting your image down to 8 bits in the end, but if you work with it in 16 bit address space (the extra 4 bits are unused, not interpolated), you can preserve much of that, and choose which portions to discard/compress/stretch before the final conversion. The downside, as you noticed, is an enormous working file, which does slow processing down.

[Robert_Lay]

This is all pretty interesting. 24 bit, 48 bit.

When I process my RAW files in Elements 3, I have the ability to save the result as an 8 or 16 bit file. I've heard that professionals use the 16 bit format because it caprures more dynamic range. But I've read somewhere that the camera captures a 12 bit image, so if you save as 8 bit you are discarding information, whereas if you save as 16 bit the software must be interpolating. My poor eyes and uncalibrated monitor can't tell the difference except I can load a few 16 bit pix and slow my 1 gig 'puter down.

Apparently we are speaking apples and oranges here.

As I respond to this, I realize that dbump has a relevant response also. So, let me see if I can respond to both.

Saving the result in 16 bit mode does require proportionally greater storage space, and as you say you are actually working with only 12 bit information that has been upsampled to 15 bits. I say 15 rather than 16 because PSCS only uses the range of 0 to 32K - not the full range of 0 to 64K. I don't worry too much about disk space yet, so I try to follow the advice of professionals like Bruce Fraser and do all my processing in 16 bit mode and avoid ever making multiple saves in JPG - everyone agrees those are degrading.

[Robert_Lay]

Definitely apples and oranges. Here's a good summary of bit depths:
http://www.luminous-landscape.com/tutorials/bit-depth.shtml

My understanding is that the most cameras capture 12 bits of data, which can be saved as RAW, or converted to an 8 bit Jpeg. Obviously you have a lot more dynamic range with the 12 bit data. Often, you end up converting your image down to 8 bits in the end, but if you work with it in 16 bit address space (the extra 4 bits are unused, not interpolated), you can preserve much of that, and choose which portions to discard/compress/stretch before the final conversion. The downside, as you noticed, is an enormous working file, which does slow processing down.

I agree with everything except the part about the extra 4 bits being unused. Actually, one bit is truly unused, as I stated above. However, no one has figured out exactly how PSCS converts the 12 bits into 15 bits. In fact, the only thing that we do know is that when in 16 bit mode the Info palette is definitely displaying the values as 15 bit values. All you have to do is watch the values in the Info palette as you move your cursor around - they run the entire range of 0 to 32767.

[Robert_Lay]

Heh, I thought that was wrong, but with all the nerdery going on way over my head in this thread, i didn't dare correct you.

I hope you won't be bashful in the future.

1) I don't bite
2) We are all here to learn.

Best regards,

[dbump]

Talk about coincidence--I just checked Bruce Fraser's "Real World Camera Raw" out from the library (highly recommended, btw). After my last post, I read the section where he talks about the 15/16 bit handling in PS. Still not sure I understand the stated reasoning for only using 32,768 levels, but since it's more than the sensor captured, I suppose I won't worry.
I am very curious about the upsampling from 4K to 32K levels. I'm going to have to experiment with the info palette. I'd expect the values to be clustered around factors of 8 (4096 = 32768, 4095 = 32760 ... 1 = 8, 0 = 0) unless they're doing something more sophisticated and making up new data where non existed before?

[Robert_Lay]

Talk about coincidence--I just checked Bruce Fraser's "Real World Camera Raw" out from the library (highly recommended, btw). After my last post, I read the section where he talks about the 15/16 bit handling in PS. Still not sure I understand the stated reasoning for only using 32,768 levels, but since it's more than the sensor captured, I suppose I won't worry.
I am very curious about the upsampling from 4K to 32K levels. I'm going to have to experiment with the info palette. I'd expect the values to be clustered around factors of 8 (4096 = 32768, 4095 = 32760 ... 1 = 8, 0 = 0) unless they're doing something more sophisticated and making up new data where non existed before?

I made a major edit to this at 14:30 EDST on 22 October 2005.

I see two questions in your message.

1) Looks like my guess about PSCS and its Mode 16 bits/channel was wrong. Bruce Fraser is correct in saying that it was designed to give an unambiguous mid point value.

I went back to his book and read again how he explains the way Adobe implements Mode 16.
They actually use the 16 bit data width to implement values from 0 through 32769 discrete values. That's contrary to anything one could imagine, but you can prove it easily enough. Just create a layer of solid white (255,255,255) in Mode 8 and convert it to Mode 16. The value displayed in the Info palette will be 32768. That means that he was correct about the unambiguous mid point. There are 16384 values above the mid point value (16385 through 32768) and there are 16384 values below the mid point value (0 through 16383) and then there is the midpoint value itself, 16384. (For some reason the editor puts a smiley face instead of the 8 in my text above. It's an idiosyncrasy of this editor related to being able to implement the smiley faces).

2) In regard to conversion from the 4096 values of the 12 bit world up to the 32769 values of the pseudo 16 bit world, I initially had the same concern as you. So, I moved my cursor around and checked to see if every possible value in the range of 0 to 32767 was allowed or if there was some indication that the three low order bits were frozen at zero. As I'm sure you have already discovered, the full 32769 values are alive, which would suggest that they really are just interpolating (nice word for fudging). However, once the virtual image has been converted to Mode 16, it will not suffer the degradation that would have taken place had that processing been done in the 8 bit world - so it behooves us to do the processing in Mode 16 and only convert to Mode 8 when we are ready for delivery, printing or presentation (because those output worlds just can't deal with 15 bits of precision (except as noted below).

I can think of a few I/O devices that ARE capable of using the full precision mode:
- Most monitors operate in 16 bit color mode and many are capable of 32 bits/channel.

- Most scanners can scan in either 8 bit or 16 bit per channel modes.

- I'm not familiar with printers that can operate in 16 bit per channel modes, but I'm sure there are some.

So, why is there so little acceptance of 16 bit /channel image data?

It's the universality of the JPG and other bit mapped image formats that are still frozen in the 8 bit per channel world. As soon as the world decides to exchange all images in JPEG 2000 format or Photoshop PSD format or the TIFF 16 bit format, then all this is going to change. In the meantime we are stuck in the 8 bit world in order to accommodate the lowest common denominator.

[dbump]

Okay, I think I understand the 32768/16 bit issue. It sounds like they're bumping up just over the maximum value addressed by 15 bits. Odd way to do it, but I'm sure it makes sense for coding/processing.

Re: 4096 interpolations, I hadn't had time to check, so I'm glad you mentioned your results. I wonder if that prevents some sort of cumulative rounding-error effect.

One question: aren't monitors (or at least video cards) typically limited to 8 bits (8 per channel for 24bit color--"32 bit" being a tidy way to handle 24 bits within the confines of 32 bit architecture, and the extra 8 bits are discarded)?
That would partially explain why you can't see the difference between 8 and 16 bit images on screen (prior to manipulation--obviously afterwards is a different story). I've seen 10 bits listed as the theoretical limit of our eye's ability to distinguish color levels; if true, that would also be a limiting factor. I'd guess that the quality of the display would have to be excellent to display more than 8 bits accurately?

[Robert_Lay]

Okay, I think I understand the 32768/16 bit issue. It sounds like they're bumping up just over the maximum value addressed by 15 bits. Odd way to do it, but I'm sure it makes sense for coding/processing.

Re: 4096 interpolations, I hadn't had time to check, so I'm glad you mentioned your results. I wonder if that prevents some sort of cumulative rounding-error effect.

One question: aren't monitors (or at least video cards) typically limited to 8 bits (8 per channel for 24bit color--"32 bit" being a tidy way to handle 24 bits within the confines of 32 bit architecture, and the extra 8 bits are discarded)?
That would partially explain why you can't see the difference between 8 and 16 bit images on screen (prior to manipulation--obviously afterwards is a different story). I've seen 10 bits listed as the theoretical limit of our eye's ability to distinguish color levels; if true, that would also be a limiting factor. I'd guess that the quality of the display would have to be excellent to display more than 8 bits accurately?

Regarding monitors: Not sure of anything anymore. I understood what they meant when they started out with something called 256 colors. Then they had 16 bits with 65000 colors and finally they came up with 24 bit "True" color. However, my video system now gives me two choices for color - Medium (16 bit) and Highest (32 bit), and I cannot tell the slightest difference and have no idea what they mean.

I'm guessing, but I would say that most monitors today are capable of at least 8 bits per channel, and it would not surprise me one bit to find that my "Medium" color quality above is 16 bits per channel.

[dbump]

Here's some great info on PC video color depths, which clarifies the 8/16/24/32 confusion:
http://en.wikipedia.org/wiki/Color_depth

[Robert_Lay]

Thanks for the reference. I interpret that as meaning that on my system I would have to use the "Highest - 32 bit" setting in order to be seeing everything that is in an ordinary JPG file.

Unfortunately, it also means that we are not really seeing all of the color in our 16 bit/channel Tiff's