Changing Resolution ...

[JohnKoerner]

I have received some information from the manufacturer of a software program, who tells me that a 5184 x 3256 "pixel dimension" image (@ 300 dpi) is "the same" as a 5184 x 3456 "pixel dimension" image ... (@ only 72 dpi)  ... it's just that the "print sizes" are different.

* The former produces a 17.28" x 11.52" high-quality print;
* The latter produces a 72" x 48" low-quality print.

This is relevant because I am exporting from raw to 300 dpi .tiff files, and stacking them through this program, and yet my "stack" comes back to me @ a 72 dpi image, not in 300 dpi resolution that my images originally started out as, though the dimensions of 5184 x 3456 have remained the same. This developer says all I have to do is put his "result" back into Photoshop and resample the new 72 dpi image back to 300 dpi, and this will be "the same" as if the image were never resampled at all.

This flies in the face of some of what I have learned here, in that "resampling" always involves mathematical recalculations that are subject to err, and that it is considered "best practice" to keep any resampling to a minimum. This man also said, "The pixel counts and actual resolution of raw and JPEG images are identical," and that raw images have 240 dpi resolution.

It was always my understanding that raw images have no assigned dpi yet, and that "dpi" only gets assigned by us as photographers when we export our images to conventional formats. Since this guy is a software creator, I feel I am in over my head in a discussion with him; however, I distintly remember Jeff Schewe stating you want to keep any re-samplings you do to an absolute minimum ... and I know for a fact there is more to image quality than mere "pixel count" ... for example, my exported 16-bit, 300 dpi, ProPhoto, .tiff files are 102.54 MB each ... and yet (without re-sizing) if I merely convert any of these .tiff images into 8-bit .jpg images, in the sRGB color space, the size of these files gets reduced to only 12.2 MB, even though the resolution and pixel count remain the same (and that is at the "highest quality" it is possible to make a .jpg!). That is over 90 MB of lost information in the conversion!

So could somebody please help me understand ... am I lost in left field here ... or is this man trying to cover up an inherent flaw in his "stacking" program, namely a conversion of its outputted .tiff files to 72 dpi (when I inputted them @ 300 dpi)? I would like to know if this "bad" or not? In other words, is re-sampling them back and forth to 300 dpi okay, or are elements being lost with every "shuffle," due to the reality of miscalculations between software programs?

Thanks!

Jack


.

[michael]

A number of different issues are being mixed up here. Let's get the JPG vs TIFF issue out of the way first. Your TIFF files from raw are in 16 bit mode. When you export to a JPG it becomes 8 bit and that explains the huge size discrepancy.

Secondly, a file may have a certain number of pixels in each direction but this doesn't relate to a print size until you decide how many pixels per inch (PPI) to print at.

If you have a file in Photoshop and leave the Resample check box unchecked you can change its PPI without actually altering anything about the file. So the software developer is right in one area. Your file at 300ppi and at 72ppi is the same file, just expressed for a different output size.

He is wrong though about raw files being 240ppi. A raw file has pixels, it doesn't have print size.

So long as his program isn't resampling the file, stating its size one way or the other is irrelevant.

Michael

[JohnKoerner]

Thank you for taking the time, Michael.

I understand what you say about number of pixels = number of pixels, and the "print size" determines the "dpi" that gets assigned. Okay, so that part is resolved, thank you.

I also thank you for clarifying that raw files have no print size, which thereby means they have no "dpi" assigned to them. So far, so good.

What I remain unclear on is the loss of information that happens when transferring from .tiff to .jpg. I mentioned in my opening post that my 16-bit .tiff ProPhoto color space output files are typically 102.54 MB in size ... whereas the 8-bit sRGB .jpg files are only 12.2 MB in size ... and you said this was because of the reduction of bit depth.

Here's where I am confused: I understand and appreciate the reduction in bit-depth plays a major factor in the reduction of file size, but there has to be more to it than that. Mathematically-speaking, if dividing the bit depth in two were all that was to it, then I should come up with a 51.25 MB file (which, it so happens, is exactly what I come up with when I re-save into another .tiff file @ 8-bit). Yet this exact same 8-bit .tiff file drops all the way down to 12.21 MB when I convert it to an 8-bit .jpg file ... so clearly alot more is being "lost" when converted to .jpg than mere bit depth. And I am just curious as to what that is.

For if, when an 8-bit .tiff file gets converted to an 8-bit .jpg file, it shrinks to less than ¼ its original size due to this .jpg conversion ... a person has to wonder just how much information was lost when converting from .tiff to .jpg

Thanks again,

Jack

.

[francois]

…
For if, when an 8-bit .tiff file gets converted to an 8-bit .jpg file, it shrinks to less than ¼ its original size due to this .jpg conversion ... a person has to wonder just how much information was lost when converting from .tiff to .jpg
…

Jack,
It's because your TIFF files probably don't use compression (or a lossless compression) and JPEG use lossy compression. If you use a high degree of JPEG compression, you'll get a small file size but will likely also see IQ degradation.

[JohnKoerner]

Jack,
It's because your TIFF files probably don't use compression (or a lossless compression) and JPEG use lossy compression. If you use a high degree of JPEG compression, you'll get a small file size but will likely also see IQ degradation.

Hi Francois;

True. I use lossless compression in my .tiff files, precisely so that they retain the greatest possible amount of information. By the very name "lossless" (and by the very name "lossy," with .jpg), something is being kept in the .tiff files that is being lost when they're converted to .jpg files, and it has to be more than just bit depth.

Yet the direct words from this fellow were, "The pixel counts and actual resolution of raw and JPEG images are identical," which flies in the face of everything I have learned. I was always taught that RAW files contain the most data information, and that we should transfer our raw images to .tiffs (.dngs, .psds, etc.) so as to retain the most information possible ... and that .jpg conversions are essentially a downgrade of the above, for posting on the internet and such.

And because my 8-bit 300 dpi .tiff files have more than 4x the file size than my 8-bit 300 dpi .jpg files, there is clearly alot that is being "lost" with a lossy compression the exact same image from a .tiff to a .jpg ... and I am just curious what is being "lost" exactly.

Thank you,

Jack


.

[SeptimusFry]

John,

the big difference is that JPG uses lossy compression. Take one thing at a time. Compression: if the image involves large spaces of all the same colour, then we can write some jpg code which can recreate exactly that without any loss. However, if we want to get further compression then we might say large spaces of ALMOST the same colour and code them as if they were the same, but when we view the image, it will have LOST accuracy (NOT PIXELS!!) in those pixels which were not exactly the same as the others in the aforesaid 'large space'.

So, compression and loss are different things. No pixels are lost in the process, but we are able to recreate the image - to a greater or lesser extent - down to every pixel, the only question is what colour is assigned to those pixels.

[francois]

I'm typing on my iPhone so I'll keep it short...

With the lossy aspect of JPEGs, pixel count is not changed, IOW a 3000 x 2000 pixels TIFF will be transformed into a 3000 x 2000 pixels JPEG file.  The compression is done by reducing the number of colors (very simplified explanation).
Have a look at the Wikipedia article on lossy compression, there's a image example that should be clear enough!

Link: http://en.wikipedia.org/wiki/Lossy_data_compression

[JohnKoerner]

Thank you both for the explanations.

[Waeshael]

You need to look at the bits/pixel for each file. The Tiff will have either 8 bits/pixel or 16 bits per pixel. At 8 bits per pixel the color variations between pixels can be as high as 8 bits (256 colors). A 10MP 8 bit TIFF file will require 30MB of storage space (3 x the MP.) The JPEG file throws away much of the color data of pixels that are similar in color to one another and lumps groups of pixels together (8x8 array) and makes them the same color. So if for instance a blue sky has very little color variation in it, JPEG will remove that color variation and make it a uniform color. If you increase the gamma of the image, or the contrast in the sky you will see these rectangular groups of color - sometimes 1/4 inch long or so. The further you compress the file from its native 30MB the more this artifact becomes visible. In the EXIF specs for a JPEG image it will state the compression which can be as high as 8bits/pixel (leica) to as low as 2 bits/pixel (Fuji some models). At 2 bits per pixel there can be no more than a 4 color step between adjacent pixels.
JPEG is not a format for anything but the transmission of images over the web. It isn't meant for photographic editing. The JPEG images from some cameras are so fragile that you will do severe damage to a picture which comes from a scene which had a wide dynamic range and full colors (like say Kodachrome colors) by changing the saturation/contrast/brightness - creating burnt out skies and muddy shadows.
So we always work with TIFF files. Most of our cameras convert to TIFF in the camera or a RAW capture is converted to TIFF in the conversion routine. We mostly save as 8 bit TIFF files because the 16 bit TIFFS are typically over 120 MB each which makes for slow processing. We always preserve as much color data as possible by using a large profile - either Adobe 1998, or Joe Holmes "Ektaspace PS 5.0" profile which captures more of the deep blues. After editing  the picture we convert it to sRGB color space for the web, and if we are concerned that the viewer might not have a recent browser, we embed the profile into the image and do not include an icc profile in the file. When we save to JPEG we use 100% quality level which makes the file a few MB, but does the least damage to our pictures.
Friends usually get the TIFF image with the icc profile in the header of the file for our discussions - but this is usually at a lower MP count (usually 2MP or so) so the file is under 10MB. Bigger files are sent to the .Mac cloud for pickup.

If you can only shoot JPEGS - not RAW nor TIFF - then choose the highest quality capture and convert immediately after transferring them safely - even before rotating them - Convert to 8 bit TIFF. Only at the very end of editing, save a copy in JPEG sRGB high quality format for the web. Keep the original JPEG, The TIFF and the final JPEG in one aptly named folder.

cheers

Waeshael

[cats_five]

...
He is wrong though about raw files being 240ppi. A raw file has pixels, it doesn't have print size.
...

I think that's simply the default DPI that Adobe Camera Raw assigns.  I wondered for some time why my JPGs were 300dpi and the PSDs from the RAW 240dpi until I noticed the box at the bottom of the ACR window.  I altered it to 300, now my PSDs are 300dpi as well and ACR has remembered the setting.  I had a hunt through the settings and either it's not there or I missed it - this is the ACR that comes with PS4.

Google shows that other people have had the same problem, for example:

http://www.istockphoto.com/forum_messages.php?threadid=53764

And, of course, although we are gaily calling it DPI it's really PPI - when the image is printed there are far more than 300 dots of ink per inch, but the printing process renders the pixels 300 per inch.

[milt]

I think a good mental model for this business is to think of image files as holding the pixels (the important thing), and separately holding a small unimportant piece of metadata that associates a physical size with the pixels.  For some uses (like all usage on the web) this metadata is completely ignored.  For some uses, (like printer drivers) this metadata supplies a default setting, but can always be overridden.  Its really only Photoshop that associates any importance with this metadata (by letting you do things like resize an image in terms of inches, etc.).

--Milt--