Ad
Ad
Ad
Pages: [1]   Bottom of Page
Print
Author Topic: 16 bit processing  (Read 2423 times)
marvpelkey
Full Member
***
Offline Offline

Posts: 126


« on: August 15, 2012, 10:45:29 AM »
ReplyReply

I have read a number of articles and comments over the years which support a 16 (48) bit workflow. Some recent comments even suggest taking 16 bit right through to the printer for optimum (yet subtle?) results. Personally, I have been using the full 16 bit workflow for years.

However, my question relates to the value of 16 bit for both up-ressing and output sharpening. I'm sold on the value of 16 bit for tonal, et al, corrections, however, is there any real benefit to having a file in 16 bit when up-ressing and/or sharpening? I guess conversely, does the file suffer if not in 16 bit during these two operations?

Because the file should be 16 bit for editing and printing, and up-ressing/sharpening occur between those two, perhaps my question is moot, however, I have never viewed any discussion on this particular aspect of file processing.

Marv
Logged
Tony Jay
Sr. Member
****
Offline Offline

Posts: 2157


« Reply #1 on: August 16, 2012, 05:44:23 AM »
ReplyReply

Marv you raise an intersting point.
You don't say what combination of software that you are using.
Lr4 also has the ability to do 32-bit editing now.

Perhaps you might follow through, first for your own interest - and then hopefully for us, and perhaps do a bit of tinkering (research) on this issues and then report your findings.
I bet that would interest a lot of individuals on this forum.

Regards

Tony Jay
« Last Edit: August 16, 2012, 06:07:24 AM by Tony Jay » Logged
hjulenissen
Sr. Member
****
Offline Offline

Posts: 1712


« Reply #2 on: August 16, 2012, 06:34:12 AM »
ReplyReply

I think that 16 bit makes sense as an intermediate format for editing. If you are going to apply umpteen nonlinear operations on your image, it only makes sense to not introduce rounding error between each step.

I dont think it makes much sense for 16 bits once you are done editing (i.e. distributed files, viewing on your display, printing).

-h
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9225



WWW
« Reply #3 on: August 16, 2012, 08:39:31 AM »
ReplyReply

You can currently send 16 bits of data to newer Epson drivers on Mac only. I can’t see a difference. That said, I keep all rendered images that I’ll print to such devices in 16-bit and see no reason not to send that data. And some day, we might see a newer printer or driver from Epson or someone else who does use that data to produce a visible difference.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
marvpelkey
Full Member
***
Offline Offline

Posts: 126


« Reply #4 on: August 16, 2012, 07:49:54 PM »
ReplyReply

Thanks for the replies,

To respond to some of the points:

I currently use NX2 for raw processing into a 16 bit TIFF, then use both Picture Window Pro and Photoshop CS5 for further editing. I do not have Lightroom. Traditionally, I have maintained the file in 16 bit TIFF right through to printing and I usually print out of PWP after enlarging in CS5 and sharpening with the Photokit plugin.

The 16 bit versus 8 bit arose when I recently attended a 3 day seminar in Covina California and the 3rd day was largely devoted to enlarging and printing images (as many as each participant wanted and up to 30 X 40 inches). Because some of the files became so large due to the size I was printing to, a discussion ensued over the value of maintaining 16 bit as opposed to converting to 8 bit. My concern (as a result of previously read comments that 16 bit to the end was best) was loss of quality in exchange for reduced file size. However, no-one, including the fellow who had been printing at the facility for 35 years (both Chroma and inkjet), could support 8 bit or 16 bit with bona-fide evidence of quality one way or the other. Once again, I don't question 16 bit for editing, just wonder about the up-ressing/sharpening/printing stages.

I decided to do a bit of research and started with L.L., where many of the experts stop and rest.

On Andrew Rodney's point of not being able to see a difference with 16 bit at the printing stage, logic suggests that if enlarging and sharpening are the last two steps prior to printing, and both have the same quality results in 16 or 8 bit, then reducing the file to 8 bits before up-ressing, sharpening and printing would be more efficient. Having said that, I can't yet find a fact-supported opinion one way or the other on this point.

Due to my Epson printer being down (with clogs), I am unable to do some personal hands-on comparisons at the moment.

The research continues.....

Marv
Logged
Tony Jay
Sr. Member
****
Offline Offline

Posts: 2157


« Reply #5 on: August 17, 2012, 12:00:20 AM »
ReplyReply

Maybe Jeff Schewe might lend his opinion here?

Regards

Tony Jay
Logged
marvpelkey
Full Member
***
Offline Offline

Posts: 126


« Reply #6 on: August 17, 2012, 02:23:09 PM »
ReplyReply

So, I did some comparisons (probably not very scientific and certainly not extensive) this morning to see if I could detect a difference in a couple of images that were up-ressed and sharpened, in both 8 bit and 16 bit. The comparison was only done on-screen because, as previously noted, my printer is down for the moment. The images were taken with a D3X and, although landscapes, each had some high and low frequency detail.

Each image was copied and one of the pair was maintained at 16 bit while its matching pair was converted to 8 bit. Both pairs were up-ressed to 12096 X 8064 (400%), using Bicubic Smoother in CS5 then output sharpened with the Photokit plugin, using the same parameters on each image.

Through an on-screen visual comparison up to 400%, I was unable to detect any difference at all (I used PWP to lay one image over the other and toggled back and forth between the two at exactly the same spots in the image, moving around the image to areas of high contrast and low contrast in tone and colour). I then used PWPs Absolute Difference Composite Transform and no difference was detected (this transform will identify a difference between two images in tone/colour, down to a single pixel - I'm not familiar with Photoshop to know if it has a similar ability). I will also add, that the up-ressing and sharpening of the 16 bit image took way, way longer on my machine than for the 8 bit.

Taking the time factor, along with the absence of any difference in on-screen comparison and Andrew Rodney's assertion that he can't detect a difference at the printed stage, it seems unnecessary to keep a file in 16 bit past the editing stage, at least from my casual tests and with the state of the software/hardware currently available to me (as I have a moderate setup). Of course, I will always retain the RAW file and a 16 bit master TIFF.

Once again, not extensive/scientific and I am open to any other input.

Cheers,

Marv
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9225



WWW
« Reply #7 on: August 17, 2012, 02:31:59 PM »
ReplyReply

Through an on-screen visual comparison up to 400%, I was unable to detect any difference at all (I used PWP to lay one image over the other and toggled back and forth between the two at exactly the same spots in the image, moving around the image to areas of high contrast and low contrast in tone and colour).

You might (might?) see a difference using the process described in this PDF using Photoshop’s subtract command:

http://digitaldog.net/files/Apply_Image.pdf

Keep in mind the role of Dither! You should probably turn this preference OFF first since with the 8-bit image, depending on the operation, PS might add this to the image.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7054


WWW
« Reply #8 on: August 17, 2012, 02:58:10 PM »
ReplyReply

So, I did some comparisons (probably not very scientific and certainly not extensive) this morning to see if I could detect a difference in a couple of images that were up-ressed and sharpened, in both 8 bit and 16 bit. The comparison was only done on-screen because, as previously noted, my printer is down for the moment. The images were taken with a D3X and, although landscapes, each had some high and low frequency detail.

Each image was copied and one of the pair was maintained at 16 bit while its matching pair was converted to 8 bit. Both pairs were up-ressed to 12096 X 8064 (400%), using Bicubic Smoother in CS5 then output sharpened with the Photokit plugin, using the same parameters on each image.

Through an on-screen visual comparison up to 400%, I was unable to detect any difference at all (I used PWP to lay one image over the other and toggled back and forth between the two at exactly the same spots in the image, moving around the image to areas of high contrast and low contrast in tone and colour). I then used PWPs Absolute Difference Composite Transform and no difference was detected (this transform will identify a difference between two images in tone/colour, down to a single pixel - I'm not familiar with Photoshop to know if it has a similar ability). I will also add, that the up-ressing and sharpening of the 16 bit image took way, way longer on my machine than for the 8 bit.

Taking the time factor, along with the absence of any difference in on-screen comparison and Andrew Rodney's assertion that he can't detect a difference at the printed stage, it seems unnecessary to keep a file in 16 bit past the editing stage, at least from my casual tests and with the state of the software/hardware currently available to me (as I have a moderate setup). Of course, I will always retain the RAW file and a 16 bit master TIFF.

Once again, not extensive/scientific and I am open to any other input.

Cheers,

Marv

Too many variables at play at the same time so you can't tell what is clarifying or obscuring what;  and you'd see things in a print you may not see on your display. The procedure isn't scientific enough to be conclusive. You need to make comparative tests isolating one variable at a time. All that said, I think the conclusion is likely to be the one Andrew mentioned previously.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Schewe
Sr. Member
****
Offline Offline

Posts: 5532


WWW
« Reply #9 on: August 17, 2012, 03:11:28 PM »
ReplyReply

Maybe Jeff Schewe might lend his opinion here?

Maybe...

Bruce Fraser and I tested resampling and sharpening on 8 vs 16-bit files and could see no difference. However, dropping to 8 bit for sharpening and resampling will indeed impact that final RGB to output color transform with outputting. Even if 16-bit printed output at the print head may not show much if any differences, the final RGB>output profile color transform is better done in 16-bit because it's a color edit. Buy more ram and get bigger hard drives has been my solution and working on 80MP IQ 180 files in 16-bit taxes my system when I do panos but in my opinion, it's worth the effort. The only time I ever use 8-bit files is after I do the final color transform to the output profile and that's really only for CMYK files at this point.
Logged
Tony Jay
Sr. Member
****
Offline Offline

Posts: 2157


« Reply #10 on: August 17, 2012, 05:49:41 PM »
ReplyReply

So it is probably better to maintain files as 16-bit for the entire process if I understand Jeff correctly, irrespective of the fact that resampling and sharpening show no difference between 8-bit and 16-bit files.
I agree with Mark that any testing on the issue has to use final prints as the arbitrater of the process.

Regards

Tony Jay
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 7054


WWW
« Reply #11 on: August 17, 2012, 07:05:40 PM »
ReplyReply

And it should test variables one change at a time.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Pages: [1]   Top of Page
Print
Jump to:  

Ad
Ad
Ad