Mike Chaney's Tech Corner
November 30, 2020, 04:40:27 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Feb 2013: Qimage Ultimate Challenges... have fun and explore features!
 
   Home   Help Search Login Register  

Professional ICC Profiling Software for Windows
Create custom ICC profiles with
Profile Prism for accurate color!
Pages: [1] 2
  Print  
Author Topic: On the subject of 16-bit/channel, internal workings  (Read 18415 times)
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« on: April 29, 2014, 08:28:36 AM »

Hi folks,

I know about the general Qimage approach towards the handling of 16-b/ch file input. And Indeed, it is only in rare situations that a difference between 8-b/ch and 16-b/ch input, will lead to visible differences in output. Added to that is the difficulty to actually print through a 16-b/ch pipeline, due to operating system / printer driver limitations.

My question is more about the order of conversions, and probably only Mike is able to answer that but maybe I failed to find the post (I did search) where it was explained before.

Assuming we have an input file, coming from a competent (14-bit ADC or better) camera, which is Raw-converted and additionally worked on in a competent Photo-editing application, in a working-space that's a bit on the large size, say ProPhoto RGB, because a lot of image manipulation might push saturation beyond the limits of Adobe RGB. We now have a 16-bit/channel file with relatively large quantization steps to fill the ProPhoto RGB gamut for some colors, and largely unused space for other colors.

Now, what happens when we open such a file in Qimage?
1. Is it already truncated/rounded to 8-bit/channel upon opening, or does the original precision remain available (or is retrieved again when needed) until after later Color Space conversions?
2. When re-sampling (usually deferred until actual printing, unless the editor is used to interpolate first), is that based on the original 16-bit (possibly truncated/rounded) precision, but the result is in 8-b/ch precision?
3. The conversion to the output profile, is that done prior to up-sampling, or after up-sampling.

Number 1 may cause issues when we interpolate notably smooth gradient transitions, although the interpolation itself may be smooth. Number 2 would probably require re-reading the original data, when the moment arrives that it's needed, but the result could again be held as 8-bit/channel data. Number 3 is potentially the biggest issue, especially with large gamut original image data. Conversion from one colorspace to another can be considered a major image editing operation, and we know that large gamut colorspaces like ProPhoto RGB is best used in 16-bit/channel mode if major editing is yet to take place. That is because the huge quantization steps in a large gamut space, may not map nicely to a smaller quantization step size, especially when only 8-bits/channel are available. That's why perhaps dithering is required to hide the errors (does Qimage/LCMS apply dithering?).

So, I'm basically looking for the moment of 16-b/ch conversion to 8-b/ch, and the moment that the profile conversion is done, before or after 16-8-bit conversion. Any help and profound insight into the inner workings of Qimage would be appreciated.

Cheers,
Bart (A long time user of Qimage, since 2001)
Logged
admin
Administrator
Forum Superhero
*****
Posts: 3179



View Profile Email
« Reply #1 on: April 29, 2014, 01:39:53 PM »

Hi Bart,

To put it as simply as possible, all operations performed after the image is loaded are 8 bits/channel.  That means if you have a 16 bit/channel TIFF that you worked in PhotoShop or some other raw converter (for example), the moment it is opened in Qimage Ultimate, it is converted to 8 bits/channel to be compatible with Windows display and printer drivers and Windows graphics API's.

Keep in mind that all operations performed in Qimage Ultimate's raw refine tool are 16 bits/channel and the raw refine tool never converts to 8 bits/channel.  This is because when in raw refine, you are working on the image as it stands before it is actually loaded by the main software code.  My suggestion when working on raws is to work your raws in Qimage Ultimate.  You'll get all the benefits of 16 bits/channel when working on white balance, exposure, fill light, and HDR in the QU refine window and you'll likely get better results much faster/easier than you would in another raw converter anyway because QU "sees" more of what is going on in the raw and automatically takes care of 95% of all editing that will be required in other software.

That said, if you must manipulate the raw in other software and you plan on editing in 16 bits/channel, just be sure to complete your editing and don't leave any major editing left on the table.  I'd also suggest using Adobe RGB even when saving in 16 bits/channel.  This is because ProPhoto is much larger than necessary while Adobe RGB is only very slightly smaller than your printer's gamut, with only a small peak in mostly the yellow and magenta areas that Adobe RGB can't reproduce.

Remember that your printer only needs to be able to reproduce the color gamut that both your camera sensor combined with your printer inks/paper can reproduce.  And that happens to match Adobe RGB pretty well so no need to go overboard and use a bloated gamut like ProPhoto RGB.

For more info, see:
http://ddisoftware.com/tech/articles/december-2006-hype-or-hero-take-2-16-bit-printers/

Mike
Logged
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #2 on: April 29, 2014, 04:25:36 PM »

Hi Bart,

To put it as simply as possible, all operations performed after the image is loaded are 8 bits/channel.  That means if you have a 16 bit/channel TIFF that you worked in PhotoShop or some other raw converter (for example), the moment it is opened in Qimage Ultimate, it is converted to 8 bits/channel to be compatible with Windows display and printer drivers and Windows graphics API's.

Hi Mike,

Thanks for clarifying that. It's pretty much what I expected, just wanted some confirmation.

Quote
Keep in mind that all operations performed in Qimage Ultimate's raw refine tool are 16 bits/channel and the raw refine tool never converts to 8 bits/channel.  This is because when in raw refine, you are working on the image as it stands before it is actually loaded by the main software code.  My suggestion when working on raws is to work your raws in Qimage Ultimate.  You'll get all the benefits of 16 bits/channel when working on white balance, exposure, fill light, and HDR in the QU refine window and you'll likely get better results much faster/easier than you would in another raw converter anyway because QU "sees" more of what is going on in the raw and automatically takes care of 95% of all editing that will be required in other software.

All understood, and it makes sense. Unfortunately, my workflow can get very complex (incl. Focus stacking, Exposure fusion, and Panostitching those).

Quote
That said, if you must manipulate the raw in other software and you plan on editing in 16 bits/channel, just be sure to complete your editing and don't leave any major editing left on the table.

Clear. Unfortunately, when multiple output profiles are needed (for different media), it is just too practical to use Qimage for also that last number crunching operation called colorspace conversion and resampling to the native printer driver resolution, which will then be in 8-bit/channel space. I assume colorspace is converted first, then resampling is done?  As said, rarely an issue, but it might be in some rare smooth gradient situations.

Quote
I'd also suggest using Adobe RGB even when saving in 16 bits/channel.  This is because ProPhoto is much larger than necessary while Adobe RGB is only very slightly smaller than your printer's gamut, with only a small peak in mostly the yellow and magenta areas that Adobe RGB can't reproduce.

Remember that your printer only needs to be able to reproduce the color gamut that both your camera sensor combined with your printer inks/paper can reproduce.  And that happens to match Adobe RGB pretty well so no need to go overboard and use a bloated gamut like ProPhoto RGB.

Yes, ProPhoto RGB is humongous, not only does it exceed any current output gamut capability, it is also revealing to know how little actual image data of the full output media's gamut is actually present in most images, except for the most saturated cases (like some flowers). That's why I often use the Beta RGB workingspace (http://www.brucelindbloom.com/index.html?BetaRGB.html) as a slightly more reasonable sized gamut colorspace. It's much less likely to cause quantization related issues, and still offers more color resolution than Adobe RGB does.

Thanks for your help.

Cheers,
Bart
« Last Edit: April 30, 2014, 02:39:17 PM by Bart_van_der_Wolf » Logged
admin
Administrator
Forum Superhero
*****
Posts: 3179



View Profile Email
« Reply #3 on: April 29, 2014, 05:12:03 PM »

I assume colorspace is converted first, then resampling is done?  As said, rarely an issue, but it might be in some rare smooth gradient situations.

Color space conversion is always done last.  Resampling and sharpening are applied and then color space is converted last.  The color space conversion must come last because if you convert to something like a printer color space first and then do interpolation and sharpening, you can end up with some really blotchy artifacts due to the "jaggedness" of most printer gamuts.

Quote
Yes, ProPhoto RGB is humongous, not only does it exceed any current output gamma capability, it is also revealing to know how little actual image data of the full output media's gamut is actually present in most images, except for the most saturated cases (like some flowers). That's why I often use the Beta RGB workingspace (http://www.brucelindbloom.com/index.html?BetaRGB.html) as a slightly more reasonable sized gamut colorspace. It's much less likely to cause quantization related issues, and still offers more color resolution than Adobe RGB does.

Thanks for your help.

You can also use pRGB which is included with Qimage Ultimate.  pRGB is a color space specifically designed to be able to encompass the gamut of any inkjet printer, even those with expanded inks.  It goes as far as it needs for printer color but not way beyond (like ProPhoto).  That's an option as well.  It installs automatically with v2014.213 and up.  In prior versions, you would have to go to \programdata\ddisoftware\qimage and get it from there.  The color gamut of pRGB is somewhere in between that of Adobe RGB and ProPhoto and it's small enough to be used with 8 bit/channel images without posterization.

Mike
« Last Edit: April 29, 2014, 05:14:07 PM by admin » Logged
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #4 on: April 29, 2014, 06:04:04 PM »

Color space conversion is always done last.

Super. No cutting of corners for speed reasons, but rather quality, first and last.

Quote
You can also use pRGB which is included with Qimage Ultimate.  pRGB is a color space specifically designed to be able to encompass the gamut of any inkjet printer, even those with expanded inks.

Indeed, I forgot about that one.

Quote
The color gamut of pRGB is somewhere in between that of Adobe RGB and ProPhoto and it's small enough to be used with 8 bit/channel images without posterization.

Mike, thanks again.

Cheers,
Bart
« Last Edit: April 30, 2014, 02:43:03 PM by Bart_van_der_Wolf » Logged
Ernst Dinkla
Sr. Member
****
Posts: 396


View Profile Email
« Reply #5 on: April 30, 2014, 07:33:19 AM »

Edit: sorry, edited your post instead of replying to it by mistake...

Quote
You can also use pRGB which is included with Qimage Ultimate.  pRGB is a color space specifically designed to be able to encompass the gamut of any inkjet printer, even those with expanded inks.  It goes as far as it needs for printer color but not way beyond (like ProPhoto).  That's an option as well.  It installs automatically with v2014.213 and up.  In prior versions, you would have to go to \programdata\ddisoftware\qimage and get it from there.  The color gamut of pRGB is somewhere in between that of Adobe RGB and ProPhoto and it's small enough to be used with 8 bit/channel images without posterization.

Mike

Mike,

Could it get the same status as AdobeRGB, sRGB, in the selectable color spaces of the RAW Image Options?
I mean if there will not be a 16 bit color space to printer profile conversion in QU and this is the next best thing it could optimize the existing RAW to print workflow.

BTW, what kind of gamma, 2.2 - 1.8 - x.x does it have?

--
Met vriendelijke groet, Ernst

http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
April 2014, 600+ inkjet media white spectral plots.
« Last Edit: April 30, 2014, 04:24:10 PM by admin » Logged
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #6 on: April 30, 2014, 04:11:31 PM »

BTW, what kind of gamma, 2.2 - 1.8 - x.x does it have?4, 600+ inkjet media white spectral plots.

Hi Ernst,

It has (16-bit) gamma 2.2 TRCs, just like BetaRGB and AdobeRGB. Oherwise it is somewhat similar in gamut trade-offs to BetaRGB.

Cheers,
Bart
Logged
admin
Administrator
Forum Superhero
*****
Posts: 3179



View Profile Email
« Reply #7 on: April 30, 2014, 04:24:42 PM »

Mike,

Could it get the same status as AdobeRGB, sRGB, in the selectable color spaces of the RAW Image Options?
I mean if there will not be a 16 bit color space to printer profile conversion in QU and this is the next best thing it could optimize the existing RAW to print workflow.

BTW, what kind of gamma, 2.2 - 1.8 - x.x does it have?

--
Met vriendelijke groet, Ernst

http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
April 2014, 600+ inkjet media white spectral plots.

A reasonable request but unfortunately not.  DCRAW doesn't provide an option for ProPhoto output (similar to the camera which lets you choose Adobe RGB or sRGB).  Fortunately if your camera is one of the ~60 that includes a custom profile, you already have better than ProPhoto: the image is left in the sensor's color space.  But if your camera doesn't include a custom profile, the only options are Adobe RGB and sRGB so if I provided a ProPhoto option, it would already start with Adobe RGB and then convert to ProPhoto which is obviously not useful.

Regards,
Mike
Logged
Ernst Dinkla
Sr. Member
****
Posts: 396


View Profile Email
« Reply #8 on: April 30, 2014, 07:09:28 PM »


A reasonable request but unfortunately not.  DCRAW doesn't provide an option for ProPhoto output (similar to the camera which lets you choose Adobe RGB or sRGB).  Fortunately if your camera is one of the ~60 that includes a custom profile, you already have better than ProPhoto: the image is left in the sensor's color space.  But if your camera doesn't include a custom profile, the only options are Adobe RGB and sRGB so if I provided a ProPhoto option, it would already start with Adobe RGB and then convert to ProPhoto which is obviously not useful.

Regards,
Mike

I was thinking of pRGB, not ProPhoto. The last will suffer more in the conversion at 8 bit to the printer profile as already discussed in this thread. Makes no difference on your reply I guess as DCRAW will not allow pRGB either.

--
Met vriendelijke groet, Ernst

http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
April 2014, 600+ inkjet media white spectral plots.
Logged
David Sutton
Newbie
*
Posts: 3


View Profile
« Reply #9 on: April 30, 2014, 11:29:14 PM »


Yes, ProPhoto RGB is humongous, not only does it exceed any current output gamut capability, it is also revealing to know how little actual image data of the full output media's gamut is actually present in most images, except for the most saturated cases (like some flowers). That's why I often use the Beta RGB workingspace (http://www.brucelindbloom.com/index.html?BetaRGB.html) as a slightly more reasonable sized gamut colorspace. It's much less likely to cause quantization related issues, and still offers more color resolution than Adobe RGB does.

Cheers,
Bart
Hello Bart.
Not to get off topic, but will the Beta RGB workingspace open in Photoshop? Being unwilling to throw away information that can be seen in print (my information is that current inkjet exceeds the gamut of Adobe RGB 1998 for cyan-green midtones and yellow highlights) I  have used ProPhoto in the past and have seen no banding issues. There is also the question of future-proofing current files for tomorrow's technology.
David
Logged
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #10 on: May 03, 2014, 08:28:14 AM »

Not to get off topic, but will the Beta RGB workingspace open in Photoshop?

Hi David,

Yes, should be no problem. Depending on your OS version, just make sure that Beta RGB (or pRGB, Printer RGB) is installed (right-click the profile and click Install, or copy/paste it) in the required location(s) so that Photoshop also picks it up, and it can also be embedded in a TIFF so it should be picked up by other systems.

Cheers,
Bart
« Last Edit: May 03, 2014, 08:39:48 AM by Bart_van_der_Wolf » Logged
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #11 on: May 03, 2014, 08:33:39 AM »

One more question: Does Qimage use the LCMS Dither option? Dithering adds an imperceptible amount of randomness to the individual channels, and is a customary operation when trying to avoid posterization/banding in smooth gradients in 8-bit/channel space.

Cheers,
Bart
Logged
admin
Administrator
Forum Superhero
*****
Posts: 3179



View Profile Email
« Reply #12 on: May 03, 2014, 01:18:36 PM »

One more question: Does Qimage use the LCMS Dither option? Dithering adds an imperceptible amount of randomness to the individual channels, and is a customary operation when trying to avoid posterization/banding in smooth gradients in 8-bit/channel space.

Cheers,
Bart

I don't use the dither option for two reasons.  First, it is almost never needed in normal photographic prints and only seldom needed in mathematically derived gradients.  Second, in my own testing, the dithering can cause clotting and other artifacts that become more noticeable, taking an almost imperceptible level of banding on some mathematical test gradient and turning it "dirty" in appearance.  In other words, the dithering can in some cases become more noticeable than the slight banding it is trying to address.  I haven't retested it since version 1x of LCMS so I may retest again in the future to see if there are any benefits.

Mike
Logged
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #13 on: May 03, 2014, 02:14:24 PM »

[I don't use the dither option for two reasons.  First, it is almost never needed in normal photographic prints and only seldom needed in mathematically derived gradients.  Second, in my own testing, the dithering can cause clotting and other artifacts that become more noticeable, taking an almost imperceptible level of banding on some mathematical test gradient and turning it "dirty" in appearance.  In other words, the dithering can in some cases become more noticeable than the slight banding it is trying to address.  I haven't retested it since version 1x of LCMS so I may retest again in the future to see if there are any benefits.

Hi Mike,

Great to hear you've considered it, but decided not to use it due to potentially worse results. Maybe the dithering in LCMS 2 has improved, let's hope. We're in principle talking about a maximum of +/- 1 in 256 randomness, which even differs per channel, which should be imperceptible especially on printed output. But maybe the implementation in LCMS 1 was something else, more pattern based, I don't know.

The quest for perfection continues.

Cheers,
Bart
Logged
admin
Administrator
Forum Superhero
*****
Posts: 3179



View Profile Email
« Reply #14 on: May 03, 2014, 02:40:24 PM »

[I don't use the dither option for two reasons.  First, it is almost never needed in normal photographic prints and only seldom needed in mathematically derived gradients.  Second, in my own testing, the dithering can cause clotting and other artifacts that become more noticeable, taking an almost imperceptible level of banding on some mathematical test gradient and turning it "dirty" in appearance.  In other words, the dithering can in some cases become more noticeable than the slight banding it is trying to address.  I haven't retested it since version 1x of LCMS so I may retest again in the future to see if there are any benefits.

Hi Mike,

Great to hear you've considered it, but decided not to use it due to potentially worse results. Maybe the dithering in LCMS 2 has improved, let's hope. We're in principle talking about a maximum of +/- 1 in 256 randomness, which even differs per channel, which should be imperceptible especially on printed output. But maybe the implementation in LCMS 1 was something else, more pattern based, I don't know.

The quest for perfection continues.

Cheers,
Bart

What would actually help is if you have a particular image in a particular color space where you notice posterization when converting to another profile.  I've learned over the years that certain images with certain profiles (particularly printer profiles that can vary wildly) can produce effect that are hard to reproduce.  The more samples I can get (image and the "to" profile) the better.

Mike
Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!