RAW/TIFF Printing

[jfh]

Hi all,
First post here but I should like to say what a gem of a site this looks like. The tutorials and the information already available is truly impressive and I'm looking forward to reading it all!

I'm relatively new to photography, perhaps 18 months or so behind the lens. As such I have some beautiful images but I've yet to investigate the printing and much of the post processing steps beyond conversion from camera raw files.

This question is entirely theoretical as although I've looked into lab based photo printing I haven't actually attempted anything yet.

After starting of shooting JPG's I progressed into RAW, not only for the additional control and potential for non-destructive editing but for the additional colour range that can be captured.

I am slightly confused though, of the online print labs I have looked at none support the printing of TIFF files, only JPG's. Whilst I can convert my RAW's and TIFFs to JPG's surely this means a load of colour information will never make it to my print?

Thanks

James

[enaiman]

You might be missing something in terms of image quality when converting to jpg but you won't be missing anything at all in the printed image.

The dynamic range a printer can handle is much lower than you can see on the screen; so pretty much any image format will hold much more information than any printer is able to produce.

My advice - use jpg's and have no fear.

[Manfred M]

As per the previous post, the raw files have more dynamic range than your monitor and printer can reproduce and your eyes can see. The reason you want all that data is only while you manipulate your image in PP work. Your final step in your workflow for printing is converting the image to jpg.

A good analogy would be if you are doing woodwork of some kind. The raw material is always physically larger than the final product, as it gets smaller as you work it into the desired form. If you start with a piece that is too small, your end product is likely going to be compromised.

[jfh]

Thank you both. It makes more sense now!

James

[tclune]

You might be missing something in terms of image quality when converting to jpg but you won't be missing anything at all in the printed image.

The dynamic range a printer can handle is much lower than you can see on the screen; so pretty much any image format will hold much more information than any printer is able to produce.

This isn't entirely true. Even extremely high-quality JPEGs have massive loss of data over, say, 16-bit-per-channel TIFF. The most usual JPEG format has 8 bits of luminosity data per pixel and 8 bits each of the two chrominance channels for every two pixels. Then, groups of 8x8 pixel data have the chrominance data massively low-passed and the luminance data mildly lowpassed. One of the results of this is a very common artifact of JPEG images called "posterization."

So what? Printing has fewer levels of color than even JPEG, you say. Not exactly. Printing involves a conversion of pixels that is known as "screening." In traditional screening, this involves deciding how large the ink blobs of each CYMK color will be at a given location. Larger blobs of a color look, at viewing distances, like more intense colors. Newer printing techniques use something called "stochastic screening," where the effect of more intense color is achieved by having more tiny dots of a given color in a given region of the image.

Now, with either approach to printing, you have the ability to define an algorithm that will allow for gradations of color over gradually-changing macroscopic regions that do not clump into posterized regions if you have the information in the original image data that tells the screening routine that a given region is, in fact, gradually changing. If the original data has lost that information, there is no way for the screening routine to differentiate between a truly posterized image and one that was falsely posterized by the conversion to JPEG. This would be an issue in, e.g., large expanses of open blue sky that was slowly changing hue. I'm sure you've seen posterized JPEGs of this sort. It has been many years since I worked in the prepress business, but at least in those days, TIFF was commonly accepted as input precisely because of its ability to avoid posterization. FWIW

[DanK]

I am not an expert on this, but I think the real issue is that in practice, despite the large loss of data, saving a high-quality image in jpeg format at the highest quality level will not degrade a printed image noticeably. Some high-quality labs (e.g., Bay Photo, which I use, and White House Custom Color) will accept only jpegs. Here is an explanation from the WHCC website:

JPEG compression is a very efficient image compression algorithm designed specifically for saving photographic images. It takes advantage of how we see color versus brightness to only save information needed to reproduce the image for people to view. Image data is lost during compression but at high levels of quality you will not see a difference between a level 10 JPEG and a Tiff printed to paper. JPEG compression is perfect for transient files for sending to the lab for printing but avoid using the compression as a working file type. Also avoid opening a JPEG, making changes, and resaving it again as a JPEG repeatedly. If your workflow calls for this to happen, save your files as Tiff or PSD files until they are complete and ready for output. At which time you should save them as level 10 JPEG. Any JPEG artifacts you see in your prints come from the JPEG file coming out of your camera, not from saving them as a level 10 for output purposes.

[John Morton]

AS Tom has pointed out, there are options open to photographers who go through printers who are dedicated to serving high end clients. Consulting with photographers in your area who specialize in artistic prints will quickly establish for you who will be able to handle demanding print tasks properly.

Much more important than the file type, however, is the issue of color space. Most printers not only demand JPEGs, they also assume that the files they receive will be in the standardized Red Green Blue (sRGB) color space. Many photographers who progress to using RAW file format also capture their images using Adobe RGB, which captures a wider gamut of colors. Images captured in Adobe RGB and mistakenly printed as sRGB files do not look good at all.

Compounding the color space issue is the fact that printers actually use a third color space, Cyan Magenta Yellow Black (CMYK) and this color space cannot capture the vibrant colors of RGB color space. RGB colors are ones which are produced directly by light sources, such as computer monitors: the human eye detects light as red green and blue so camera sensors are designed to do that, too. Red, green, and blue light add together to give white light; but printed color comes from light that is being reflected by the white paper on which it is placed: so the CMYK ink mix is designed to SUBTRACT from that white paper and the colors that you see are actually the ones which the applied inks DO NOT mask out. For instance, magenta ink blocks the color green; yellow ink blocks out the color blue; and cyan ink blocks out the color red. Thus, yellow and cyan ink leaves only the color green to be seen; magenta and cyan ink leaves only the color blue; and yellow and magenta leaves only red. Black is used to produce the KEY (K) printing plate that the other colors are registered to; and, since CMY alone only produces a kind of muddy and very dark brown, black is added to make the blacks, well, black (text printed with CMY inks in addition to black is referred to as RICH BLACK).

All of which leaves us where? Well, in my opinion RAW files and 16 bit TIFFs saved in other than sRGB color space can be considered archival options. My work flow is thus somewhat of a downhill gradient, wherein I know I will be losing color information through the entire process but at the same time I am trying to fill up the available space that I have open to me. Even though sRGB color space is smaller than Adobe RGB, it is still very wide and there is a lot of space in sRGB that is usually open enough to allow one to boost the colors in an image a bit. The biggest problem occurs with greens, because Adobe RGB has a very wide gamut for greens that sRGB does not even come close to matching. If I have a nice bright green of, say, leaves with the sun shining through them from behind, I know that these intense green colors will not fit into sRGB space and that I need to edit them down a bit before converting.

This final conversion step is the last one I do and, like sharpening, it is something that should be done for specific ends. In other words, I do not use any JPEG conversions that I do for the Internet when I go to print an image out at a local over-the-counter venue; I produce a specific file for that from the final version TIFF I have archived. Printing at home is simpler: I have a color laser printer that is designed for pre-press modeling and it does print in Adobe RGB.

Internet browsers, however, render images in sRGB; so when I am posting images here or anywhere, I always convert them to sRGB color space because I know that Adobe RGB color space will not be rendered accurately by the browsers of those who visit this site.

[jcuknz]

Hi all,

After starting of shooting JPG's I progressed into RAW, not only for the additional control and potential for non-destructive editing but for the additional colour range that can be captured.

Thanks

James

There is nothing to stop you doing non destructive editing of your jpgs if you have the right editing programme. It is how you go about it and maintain a copy of the original file in its own folder .... in my case on a separate external hard drive, actually the hard drive from my old computer which still had loads of free space and now sits in its own box beside the new computer.

[Colin Southern]

JPEGs are a source of much confusion.

Basically, they're not "evil" or inferior to TIFFS / PSDs in any way" per se, they're just optimized for certain characteristics. With the main one being small size.

When a JPEG is created - a number of algorithms are applied. Yes, a lot of information is discarded - BUT - it's information that we can't see anyway - ASSUMING - that we're not making significant adjustments to a JPEG image afterwards. In other words, JPEG is an OUTPUT format that (at an appropriate quality setting) produces VISUALLY lossless quality at a fraction of the size that a TIFF / PSD would be.

In real world terms, if you're shooting JPEG - and then having to make big adjustments to levels - then you will notice the degradation. If you're shooting JPEG and then making small adjustments to levels then you'll probably get away with it (JPEG algorithms actually include a surprising safety margin). The artifacts that people often mention are generally the result of a file being saved with too low a quality setting (ie telling the program generating it to prioritize small file size over quality).

In terms of colours, there's really no difference. Monitors and printers can reproduce - at best - the Adobe RGB gamut - and this gamut is supported by JPEG (as is Prophoto); the BIG problem however is one where most off the street print "labs" assume that any file is sRGB so (a) clip any colours outside that gamut, and (b) reproduce an Adobe RGB image poorly; the solution to that is to (a) print your own images or (b) use a more up-market printing service (cough, good luck!). Either way, it's not a JPEG - v- TIFF thing that's limiting the colour gamut.

Hope this helps.

[John Morton]

Basically, they're not "evil" or inferior to TIFFS / PSDs in any way" per se, they're just optimized for certain characteristics. With the main one being small size.

When a JPEG is created - a number of algorithms are applied. Yes, a lot of information is discarded - BUT - it's information that we can't see anyway - ASSUMING - that we're not making significant adjustments to a JPEG image afterwards. In other words, JPEG is an OUTPUT format that (at an appropriate quality setting) produces VISUALLY lossless quality at a fraction of the size that a TIFF / PSD would be.

As Colin mentions, it is very important to remember that JPEGs are an output format. One nasty characteristic that they have is that the compression algorithm is applied EACH TIME a JPEG is saved; so editing a JPEG and saving the file at various steps during the process will progressively degrade the image file as previous compressions are themselves compressed. For instance, if eight pixels are compressed into one block in the first save, then eight blocks (64 pixels) would be compressed together in the next save; and so on until, even at maximum quality, JPEG artifacts would be apparent before very long.

Just copying a finished JPEG file doesn't do this; but saving and re-saving a JPEG file does. This doesn't happen with TIFF images, because each pixel in a TIFF has its own unique Cartesian (x/y axis) location where color information (8 or 16 bit) is stored. JPEG's, in contrast, store color information as equations which describe blocks of color of greater/lessor sizes.

[Colin Southern]

As Colin mentions, it is very important to remember that JPEGs are an output format. One nasty characteristic that they have is that the compression algorithm is applied EACH TIME a JPEG is saved; so editing a JPEG and saving the file at various steps during the process will progressively degrade the image file as previous compressions are themselves compressed. For instance, if eight pixels are compressed into one block in the first save, then eight blocks (64 pixels) would be compressed together in the next save; and so on until, even at maximum quality, JPEG artifacts would be apparent before very long.

That's something a lot of people say John, but I don't think many actually test the theory.

I think you'll find that in practice it's not so much compressing data that's already compressed, as it is re-normalising that data ... which means that in subsequent passes, there's not really anything to do, assuming relatively light editing.

In other words, it's not as big an issue in practice as people think it is in theory.

[John Morton]

Well I don't know, Colin; I've seen some pretty serious banding appear in JPEGs after not very many editing passes - in the sky, for instance. I've even seen that here on this site in at least one otherwise very photo posted by a member.

I know that one can get away with a number of edits and saves of JPEGs that have minimum compression and maximum quality; I've done it myself, when I've been in too much of a hurry to track down the edited TIFF version or the original RAW version. But when I do, I try to limit the number of saves that I make and I do a lot more editing before before a save an interim version. In fact, I'll tend to convert the JPEG into a TIFF just so that I don't lose any more image information due to file compression when saving edit versions.

I agree that it is an issue which does not necessarily assert itself as quickly as some might think; but on the other hand, once it becomes a problem it isn't something which will at any point thereafter go away.

Thus, I think it prudent to make a practice of copying JPEG files - dragging and dropping them, for instance - rather than file/saving them to a new location. I might certainly be wrong about that; but I guess the issue is, as you indicate, actually re-opening the file and then re-saving it before closing it again.

One can certainly test this quite easily by opening and re-saving a JPEG file a number of times, and keeping track of the actual (closed) file size with each successive iteration of the compression algorithm... so I'll try that and I must admit my surprise in finding that, after ten successive 're-openings' and 're-saves' at a quality level of 8, the image file I am using has actually gotten a little bit bigger!

First Version:



Tenth Version:



... so perhaps I am completely wrong about the degradation of image quality caused by successive 'saves' of a JPEG file!

[tclune]

When a JPEG is created - a number of algorithms are applied. Yes, a lot of information is discarded - BUT - it's information that we can't see anyway - ASSUMING - that we're not making significant adjustments to a JPEG image afterwards. In other words, JPEG is an OUTPUT format that (at an appropriate quality setting) produces VISUALLY lossless quality at a fraction of the size that a TIFF / PSD would be.

...

Hope this helps.

No, it doesn't help. It is false. My field is medical image processing, and I have done extensive exploration of lossy compression algorithms. JPEG is a very powerful standard, and has its uses. I like it and normally output my personal photography final images in that format -- largely because it is supported by just about everything. However, JPEG's lossiness is such that it is virtually impossible to know beforehand whether it will produce visible artifacts or not. This varies on an image-by-image basis, and artifacts include "washed out" colors (readily visible on computer screens in many cases), posterization (ditto), and checkerboarding (visible on anything). As you can imagine, the first two present significant issues with medical images, which may be batch-processed and stored without first examining the resulting JPEGs. It is considerably less of a concern with your vacation photos, which you are probably going to examine individually before you send to the printer, and will not cause you to miss a diagnosis even if some artifacts sneak by your attention. JPEG itself does not specify the contents of the key step, called quantization. A careful medical image application will define quant tables that are optimized for the particular imaging modality to make artifacts extremely unlikely at allowed compressions. But nobody who doesn't write their own JPEG compression routines (and research the bejesus out of the specific imaging parameters first) will have the ability to control (or even anticipate) the parameters that will result in creation of artifacts. The best you can do is observe the images after compression to see whether artifacts have crept in. If so, choose a different file format or -- if your application supports "quality factors" (not part of the JPEG standard itself, and quite a questionable practice mathematically FWIW) -- choose a higher QF.

[tclune]

... so perhaps I am completely wrong about the degradation of image quality caused by successive 'saves' of a JPEG file!

No, you just don't understand what "generational loss" is all about. If you open a JPEG and resave it using the same application at the same settings, the only change from one save to the next will be caused by the round-off error in the routine. That quickly approaches 0 for each successive save. Where generational loss is important is any of the following conditions:

1. You change the application that you use. In that case, the quantization tables may be different between the two applications (Quant tables in essence low-pass the luminance and chrominance data of the DCT-transformed 8x8 "GOPs" of the image. If the two applications use different low-pass filters for their quant tables, or use different "quality factors" applied to the commonly-employed sample quant tables presented in the original JPEG standard, there will be significant generational loss between compressions -- even if the image itself actually grows in size!) A good way to track these changes is by diff'ing the images and histogram-equalizing the resulting image.

2. If you apply any editing to the image before resaving, you will get additional loss on the edited areas when the quant tables low-pass the newly-modified regions. The rest of the image will be affected only by round-off error when saved, but the edited regions will have new frequency content, which will result in a whole new compression loss.

3. Changing the quality factor within your application can result in generational loss across the entire image.

FWIW

[ETA: I love this stuff. If you don't you may want to skip the following. I thought it might be reasonable to indicate why a file might grow in size under JPEG even though it has shrunk in information content. JPEG does the following: First, you convert the file to YUV (typically, YUV 4:2:2), which shrinks the pixel data to 8-bits per channel from the original (with typical RAW or TIFF data, the format would be 16 bits per channel, but the actual data will normally be no more than 12 or 14 bits per channel). Further, the two color channels use only one value of chrominance for every two values of luminance ("luminance" == grayscale, "chrominance" == color). So the data has been massively reduced just by the conversion to YUV.

Next, the data is grouped into 8x8 clumps of pixels called "GOPs" (groups of pixels) and converted using the Discrete Cosine Transform (DCT) to frequency space. Then the luminance GOPs are subjected to a relatively gentle low-pass filter that throws away some of the frequency data in the GOP, and the two chrominance channels are subjected to what is typically a very agressive low-pass filter. If you have ever JPEG'ed an image with sharp colored edges (like, say, colored text in an image), you will almost always find the edges to become fuzzy due to the standard over-compression of the chrominance channels.

Finally, the step that does the actual compression is applied. This is Huffman coding of the results of the previous step. The Hufman code represents a table entry indicating a funny kind of run-length encoding. Basically, the contents of the Huffman code are indexes into the Huffman table. The Huffman table indicates a particular run of 0s and 1s. Imagine that the first entry in the Huffman table is a run of 200 0s. Then, the value "1" represents 200 zeros. The compression is a matter of how well the Huffman table captures really long runs of repeated patterns. The reason that we apply the quant tables should now be clear -- we are trying to get a lot of 0s in our data so the Huffman tables will be more effective at compressing the data. But it should also be clear why data may actually grow when it loses some information -- the position of the 0s in the resulting GOPs may have shifted, leaving a shorter run of bits and requiring more entries in the Huffman coding. This is exacerbated by those applications that use a default Huffman table instead of generating the tables from the actual data in the particular image.]

[John Morton]

Thanks, Tom, that was really informative and it is very good indeed to know what is actually going on when JPEGs are used as a file format for images. I did indeed simply repeatedly re-open and re-save my sample image in Photoshop, without applying any changes to the file itself; and I see now that choosing a grey scale image also avoided the over-compression of chrominance channels that you mention.

[jcuknz]

The point for me, and my practice in shooting jpgs is that once the shot has been taken and opened in editing it is then saved as a loss-less file, in my case as a pspimage but adobe users could use .psd ... we could all use say tiff or bmp .... could be others i have not heard about.

On the other hand the jpg process can be adjusted to near zero compression and I remember way back a guy pointing out the lack of degradation after twenty jpg saves..... but you need to set your editing programme properly .... and it has taken me best part of twelve years to twig this in case I want to save as a jpg after an edit ... highly unlikely as when i want to save as a jpg PSP lets me select the degree of compression I want for the intended site.... PSP I consider the best in this feature though Photoshop is close behind, but other programs are really extremely clumsy in this respect. As a dial-up user until recently it is patently obvious that very few contributor to site either cannot be bothered or simply don't know how to arrange a reasonable compression which facilitates a reasonable fast download ... even after being told in one case ... no names no pack drill
End of rant

[John Morton]

Yup, back in the day not so very long ago: applying background blurs to JPEGs so that the compression algorithm was more efficient and the file size for upload smaller; using indexed color tables to decrease the actual number of colors included in an image; reducing the ppi ratio as much as possible, right down to the standard 72 ppi; using compression quality settings as low as 5 for greyscale images; processing and sizing thumbnails separately and differently than the main images so that websites downloaded much faster for dial-up users...

[Colin Southern]

No, it doesn't help. It is false. My field is medical image processing

The point is though Tom, that 99.999% of folks here are going to be using JPEGs for general photography, not medical imaging. In the vast majority of cases any JPEG degradation - if present - is only going to be visible at high magnifications. The vast majority of images have 90+ percent of their information discarded when they're down-sampled for online display - or - they're printed at such a size that the human eye is incapable of resolving any degradation.

It's classic theory -v- practice. In theory, yes, the degradation exists, but in practice - for normal JPEG applications - it's just not an issue.

[Diane]

I've been reading this thread & do not know what a 'JPEG artifact' is?

thanx ,
Diane

[Glenn NK]

The point is though Tom, that 99.999% of folks here are going to be using JPEGs for general photography, not medical imaging. In the vast majority of cases any JPEG degradation - if present - is only going to be visible at high magnifications. The vast majority of images have 90+ percent of their information discarded when they're down-sampled for online display - or - they're printed at such a size that the human eye is incapable of resolving any degradation.

It's classic theory -v- practice. In theory, yes, the degradation exists, but in practice - for normal JPEG applications - it's just not an issue.

Yes - it comes down to what is significant.

And hopefully no one will keep modifying and saving a JPEG file over and over. In my own narrow-minded way, I never shoot JPEG, and only work on an original image with software that is non-destructive.

There is a direct parallel in digital music; high quality MP3 files (Layer-3, 44,100 Hz, 320 kbps stereo), are seldom distinguishable from full WAV files by anyone over the age of 20. But if one keeps modifying the MP3 and saving, considerable degeneration will occur - and it's noticeable.

Incidentally, where I have my printing done, they can only print from a JPEG, not from a TIFF.

Glenn