Copy link to clipboard
Copied
I've only recently become interested in printing my images. I was surprised to find that photo labs with a reputation for high quality fine art printing (e.g., Bay Photo or Whitewall) request 8-bit images. I've seen an obvious advantage in 16-bit rather than 8-bit editing, especially with respect to very gradual color transitions (e.g. gradients or mist over a field) where there is obvious banding in the 8-bit file. As an experiment, I made a copy of a 16-bit file, converted it to 8-bit, then compared the 8-bit side-by-side to the 16-bit original at print view (in this case, 22"x40"). I found no banding in areas that included gradual color transition and a barely perceptable difference in color limited to highlights. It seems like it makes sense to edit in 16 bits even if the file needs to be converted to 8 bits for printing. But I have no clue why 8-bit editing is problematic but conversion from a 16-bit to an 8-bit file does not seem to result in a degradation of the image. Can anyone explain that or point me in the direction of an article that does explain it?
It's because 8 bit editing is cumulative. You end up with the 256 values all over the place, with gaps and "combing". Everything gets exaggerated as you go.
When you work in 16 bits and then convert to 8 at the very end, the 256 values are perfectly evenly distributed. You might still see those 256 values in very smooth gradients, but you won't get the multi-value jumps.
It’s the difference between the requirements for editing, and the much simpler requirements for final delivery.
In editing, you need maximum flexibility, overhead, resolution, and margins to make changes, whether that’s redistributing the tones, preserving highly saturated colors, or making local adjustments. 16 bits per channel (and similarly, the full original color gamut), gives you the resolution and room to maintain quality as you make change after change. The tonal resolution of 16bpc he
...Copy link to clipboard
Copied
It's because 8 bit editing is cumulative. You end up with the 256 values all over the place, with gaps and "combing". Everything gets exaggerated as you go.
When you work in 16 bits and then convert to 8 at the very end, the 256 values are perfectly evenly distributed. You might still see those 256 values in very smooth gradients, but you won't get the multi-value jumps.
Copy link to clipboard
Copied
It’s the difference between the requirements for editing, and the much simpler requirements for final delivery.
In editing, you need maximum flexibility, overhead, resolution, and margins to make changes, whether that’s redistributing the tones, preserving highly saturated colors, or making local adjustments. 16 bits per channel (and similarly, the full original color gamut), gives you the resolution and room to maintain quality as you make change after change. The tonal resolution of 16bpc helps prevent the banding that large changes might create.
But when you are done with changes, it is much less necessary to preserve all of the overhead. You can just keep the final results, and drop much of the rest. The copy sent to a print shop can be flattened, 8bpc, and even JPEG (if high quality), and the final print will look good, because the penalties for stepping down the specs don’t happen if the print shop makes no further major changes to that file.
Another reason is that a print can only reproduce a smaller dynamic range and color gamut compared to the original file and on-screen editing, so print can’t reproduce it all anyway. What can be reproduced in print is typically reproducible at 8bpc, again if no additional major edits will be made.
This works the same way with the digital music and movies you enjoy. The digital files that you listen to or watch sound and look great. But the rendered digital files delivered at the movie theater or on your home AV system do not match the file size, bit depth, and quality level of the original media files (stacks of tracks and clips) that were put together to create the final movie or song.
We even know this with food. What we eat is a plate of food, and that’s exactly what we expect. But the meal could not have been prepared only with the plate and the space on it. Preparing the meal properly actually requires a much larger work surface, more ingredients (like it needed half an onion, but the store will only sell you a whole one), and a lot of water, energy, and a range of tools. But delivering the meal no longer requires all that overhead, all we need at the table is that one plate with the finished dish on it, that will not be altered any further (except maybe with a little salt and pepper).
Copy link to clipboard
Copied
That was really interesting and helpful. Thanks very much. This forum is a treasure trove.
Copy link to clipboard
Copied
@Doc_Pit good of you to come back with thanks, yeah, I agree, work in 16 bit for the seasons that @D Fosse gave - then convert a flattened copy to 8 bit (archive your layered 16 bit original inn case of adjustments down the line) - there's no point printing 16 bit
I hope this helps
neil barstow, colourmanagement net - adobe forum volunteer - co-author: 'getting colour right'
google me "neil barstow colourmanagement" for lots of free articles on colour management
Copy link to clipboard
Copied
So much to learn! Curious about how you all name or organize these two versions in your files so that you can easily retrieve the version that you want.
Copy link to clipboard
Copied
Curious about how you all name or organize these two versions in your files so that you can easily retrieve the version that you want.
By @emilyp1451082
We can follow the example of studios and professional organizations who develop and maintain a naming convention for their files, so that they know what any file is. They define what information they would like to have in the filename, also considering how they want files to be listed in a folder when sorted by name. Some keep source original files (such as PSD) in one folder, and compressed delivery-only files (such as JPEG or flattened TIFF) in another folder.
For example, some might want the project name in the filename, others might want a date but in a form that files sort chronologically when a folder is viewed by name so they add the date following the convention YYYYMMDD (year, month, day) for example 20251231. (The American convention of MMDDYY inconveniently sorts files by month and day before year, when a folder is sorted alphabetically.)
Adobe Bridge and Lightroom Classic offer powerful batch renaming features that you can use to maintain a standard naming convention. In the picture below, the Bridge command Tools > Batch Rename lets you rename multiple selected files based on things like:
You can save these settings as a preset, as shown near the top. In the example I selected 9 images in Bridge, but I could have also selected 300 images and renamed all of those at once too.
Copy link to clipboard
Copied
So much to learn! Curious about how you all name or organize these two versions in your files so that you can easily retrieve the version that you want.
By @emilyp1451082
The natural instinct is to store everything - but there's usually no reason to keep derivative copies, like e.g. print versions or web versions. They can easily be recreated with a simple action. It makes life much simpler if you only need to worry about your master files.
The exception would be if you do extensive gamut remapping to the (usually) much smaller output color space, but that would only be valid for that specific output.
Get ready! An upgraded Adobe Community experience is coming in January.
Learn more