Mike Chaney's Tech Corner
March 29, 2024, 05:57:51 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Qimage registration expired? New lifetime licenses are only $59.99!
 
   Home   Help Search Login Register  

Professional Photo Printing Software for Windows
Print with
Qimage and see what you've been missing!
Pages: 1 [2]
  Print  
Author Topic: On the subject of 16-bit/channel, internal workings  (Read 27096 times)
Cybis
Newbie
*
Posts: 4


View Profile WWW
« Reply #15 on: May 04, 2014, 06:43:31 AM »

Quote

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.

Hi Mike,

Here is one: http://lucbusquin.com/sites/default/files/torture_test.tif.

It's in 16-bit ProPhoto. It exhibits lots of posterization/banding when printed in Qimage but none in PS and LR. Most of it because QI does the conversion to 8-bit without dithering while LR & PS use dithering.

Ideally you want to upsample the pixel size first and downsample the bit-depth last.

If that can't be done, a second best, would be to downsample to 8-bit with dither, and hope that all the pixel size upsampling and sharpening won't make the dithering pattern visible. Maybe make the dithering a selectable option? Not sure. And let's not forget that it's a non issue with the vast majority of real world photos.
Logged

Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #16 on: May 04, 2014, 01:51:51 PM »

Quote

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.

Hi Mike,

Here is one: http://lucbusquin.com/sites/default/files/torture_test.tif.

It's in 16-bit ProPhoto. It exhibits lots of posterization/banding when printed in Qimage but none in PS and LR. Most of it because QI does the conversion to 8-bit without dithering while LR & PS use dithering.

Ideally you want to upsample the pixel size first and downsample the bit-depth last.

Hi Luc,

Indeed, I think it would be a mistake to dither this soon in the processing pipeline (upon opening the file), even before resampling to output size and output sampling.

It may also be useful to send Mike a copy of your Output profile, although you say that with that same output profile PS/LR do not exhibit as much posterization/banding. It might also be interesting to try Raw converting the image to pRGB or BetaRGB instead of ProPhoto RGB (PPRGB), and see if that makes a lot of difference in this particular case.

Cheers,
Bart
Logged
Cybis
Newbie
*
Posts: 4


View Profile WWW
« Reply #17 on: May 05, 2014, 05:09:41 AM »

Hi Mike,

There is a similar conversation taking place coincidentally right now over at Luminous Landscape about 16-bit printing and Bart made me aware of the discussion here yesterday. So I'll jump in.

… 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.

Ideally, it would be best if the 8-bit conversion was happening last. It wouldn’t affect compatibility with any Windows drivers and would result in a higher quality print.

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.

At least in the case of the Epson x900, the printer gamut portion outside AdobeRGB is significant, not just in the yellow and magenta but also in the blue, cyan, and green. So IMO there is a strong case for operating in a larger gamut. A lot of us are using ProPhoto for that reason or because they've been told it's the 'best' profile for that reason.  As long as one operate in 16-bit, there is no drawback to it.

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.

Actually, you want a profile that fully encompasses both the source and the output, in our case the camera and the printer.
This is because processing could expend the source image gamut.

But the real issue, IMO, is not the volume of the gamut but the conversion to 8-bit. Even a grayscale image could potentially suffer if the conversion to 8-bit isn’t done at the last possible step.

Banding can easily be seen in dither free, noise free, 8-bit grayscale ramp.

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

I agree that noticeable banding/posterization caused by 16 to 8-bit conversion or by profile conversion with rounding without dithering will be very rare in real world photographs due to the presence of noise. Though it can make synthetic gradients and nearly noise free images look awful.
 
8-bit dithering performed at output resolution (e.g. 360 dpi) is invisible in inkjet prints. The dithering blends in the background noise intrinsic to the inkjet droplets dithering pattern.  Even under a loupe there is no difference between 8-bit-dither and a pure 16-bit print.
Now, you may run into problems if the dithering is done before pixel size upsampling.  At what enlargement factor does it become a problem? Don’t know…

To me, of all the software options out there, QU is by far the best solution because of its ease of use, versatility, quality of its upsampling algorithm, quality of its sharpening, etc.

But the 8-bit pipeline is Qimage’s weak spot, although it only shows in a tiny fraction of prints if ever. That's the cost of being nearly perfect in all other aspects.

Logged

admin
Administrator
Forum Superhero
*****
Posts: 4109



View Profile Email
« Reply #18 on: May 05, 2014, 12:25:05 PM »

There is so much going on in this debate that I can't possibly cover it without writing an entire article.  I'll answer a few questions but first I'll just cut to the chase and say... the best solution is to stop using color spaces that are much too large for the job (ProPhoto)!  Just use Printer RGB (pRGB) and be done with it.  It is significantly larger than Adobe RGB, large enough to hold the gamut of any inkjet printer, and not so large that it requires 16 bits/channel.  That said, the need for something any bigger than Adobe RGB is more rare than you think.  There are a lot of factors to consider:

(1) Changing from an 8 bit to 16 bit pipeline isn't like flipping a switch.  The entire internal code base has to be changed.  All Windows graphics API's are 8 bit based so the code has to be completely rewritten and many third party modules have to be dumped and custom code written.  Then you have to deal with bugs and the fact that some people are already feeding QU 1GB and larger images and now with the innards being 16 bit, memory requirements double so without a major rewrite of the memory management, you can only load images half the size.  There will be a speed slowdown as well.  All... for nothing really.

(2) To your point about the gamuts, for a photograph, you only need a gamut large enough for the union of your camera's sensor gamut (yes, they have gamuts) and your printer gamut, not their "universe" (both combined).  If your camera can't reproduce it, it isn't there to map to your printer's gamut.  If your camera can produce it but the printer can't, it'll map to the printer's gamut hull never to exceed it (physically impossible to reproduce).  I get your point about taking the camera image and editing it so that the colors in the photo ARE outside both of those gamuts but honestly, where are you going to edit that?  On your screen which has a smaller gamut than even Adobe RGB?  I don't think that's realistic.  To actually need ProPhoto, you need all of four things to happen: (a) you need a subject to photograph that actually has colors outside the Adobe RGB or Printer RGB gamuts [or something you intend to cleverly modify beyond those gamuts - although then it becomes something other than a photograph IMO], (b) that color has to be inside the camera sensor's usable gamut, (c) the color has to also be inside the printer's gamut for the ink/paper, and (d) you'll have to print using relative colorimetric intent else the color you want won't print anyway due to scaling... and with RC intent, if there are any colors in your image that are outside your printer's gamut, your posterization in those areas is likely to be worse than if you had just rendered in a smaller gamut and used perceptual intent!  It's a complicated scenario: kinda damned if you do and damned if you don't.  99% of the people who are using ProPhoto are using it because they heard some blogger say it's good.  And he said it's good because "bigger is better".  And their images are likely no better (probably worse) as a result.

(3) ICM is not a "smart model".  There is so much fluff going on inside profiles WRT gamut mapping (particularly with perceptual intent) that using an overly large gamut like ProPhoto for your photos can actually cause some images to look worse.  The ICM model doesn't look at image content so it'll always assume you need as much "room" as is in the source profile whether it is used or not: so "making" colors that look as vibrant as ProPhoto can contain just for the heck of it isn't a good idea.

All that said, I did already build in one level of dithering into 217 which should be out later today, giving us 9 bits (512 virtual levels as opposed to 256).  It's limited in that we're still starting with 8 bits but being able to render the output of the final profile conversion into 9 bits dithered does help smooth out posterization in those ProPhoto torture tests.  But you really have to make a deliberate effort to find a man-made mathematical gradient that shows posterization even with ProPhoto.  So I end how I started: by saying if it hurts when you poke yourself in the eye, perhaps glasses aren't the answer, meaning... use Printer RGB and deal with the problem at the source: you won't have to deal with the 16 bit conundrum and the extra space and time needed to store/process them.

Mike
Logged
DdeGannes
Full Member
***
Posts: 175


Retired Banker; Golf; Photography; Travel.


View Profile
« Reply #19 on: May 05, 2014, 01:28:18 PM »

Where is pRGB available?
Logged

COMP EQP: iMac 27" mid 2015 5K Retina macOS 11.2.3; 24GB Ram; Scan Elite 5400 film scr.
CAMERA EQP: Oly OMD EM-1, Digital Zuiko & OM lenses.
Imaging Apps: PS CC 20; LR Classic CC 9.3; Qimage U & One; VueScan.
Fred A
Forum Superhero
*****
Posts: 5644



View Profile WWW Email
« Reply #20 on: May 05, 2014, 02:15:15 PM »

Hi Dennis,
It's in the main Qimage folder. Comes with Qimage, and it automatically is selected when you invoke Let Printer Manage Color.
Fred
Logged
Cybis
Newbie
*
Posts: 4


View Profile WWW
« Reply #21 on: May 05, 2014, 03:27:18 PM »

Mike,

Your points are all valid. We are really in the domain of the improbable and the diminishing returns.

One small point about those colors outside the display gamut but inside the printer gamut. Out of gamut warning or iterative printing can help with the dead reckoning. Also your software could be used by people who create images that are outside your definition of a photograph, no?

Where can I find more info on PrinterRGB?

And for those using ACR, as of ACR v8.x (PS CC), it let you choose whatever profile you want to work in, including PrinterRGB if installed. Previous version only have the choice between sRGB, AdobeRBG and ProPhotoRGB.

I'm looking forward to 217.
Logged

admin
Administrator
Forum Superhero
*****
Posts: 4109



View Profile Email
« Reply #22 on: May 05, 2014, 04:41:41 PM »

Just a note: all versions starting with 2014.213 will automatically install Printer RGB in your system color folder.  So it should be visible in any other program after install.

Mike
Logged
Ernst Dinkla
Sr. Member
****
Posts: 410


View Profile Email
« Reply #23 on: May 06, 2014, 10:02:14 AM »

Just a note: all versions starting with 2014.213 will automatically install Printer RGB in your system color folder.  So it should be visible in any other program after install.

Mike

Mike,

Based on the last two messages in this thread Dave Coffin could put the cream on the cake for QU by adding PrinterRGB to the DCraw color spaces.

Ernst, op de lei getypt.
Logged
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #24 on: May 10, 2014, 03:19:31 PM »

Hi Mike,

On the release notes of v2.18 it is mentioned:
v2014.218 offers improved dithering for 16 bit images and profiles plus some bug fixes.

This adds the following Dithering options to the Color management panel:
  • None
  • 16 bit images only
  • Full (16 bit images and profiles)

Could you elaborate about the 16-bit images option. Does that dither 16-bit/channel images on input conversion to 8-b/ch? If so, doesn't that carry the risk of magnifying/enlarging whatever dither there might be visible when adding a filter sharpening in the image editor, and enlarging that with output upsampling?

I've also seen that the output dither has a checkerboard pattern. Is that part of the LCMS colorspace dither option? Is a checkerboard pattern safer than a stochastic pattern to avoid clashes with the printer dither pattern, or just faster? It may not matter much at the native printer driver resolution (600/720 PPI), although we have the option to use a lower resolution and the printer driver may be set-up to a maximum of 300/360 PPI, but I'd like to understand the pros and cons.

Thanks for the additions.

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



View Profile Email
« Reply #25 on: May 10, 2014, 07:26:29 PM »

Sure, any of that is possible, but there are many factors here worth noting:

(1) Remember that the dithering only makes neighboring pixels differ by a single RGB unit: example, 110,120,130 and 110,121,130.  Most image operations (even reasonable sharpening) won't enhance the pattern by an appreciable amount because there's basically no edge there.

(2) LCMS has no dither option.  It was taken out in v2 and only existed in the v1 series.  This is my own dithering that I've found to be the least visible.  With the checkerboard pattern your eyes have to be able to resolve a single pixel to be able to see it.  Even on screen, I have to go as high as 400% zoom just to see it, and with many images, up to 800%.  And again, the "checkers" only differ by one unit in RGB value so, very hard to see!

(3) If you have a very low resolution image that needs a lot of interpolation (low res image printed large), it's possible that the pattern could get larger and be more visible, but then again, interpolation algorithms tend to smooth over individual pixel details!  So again, doubt it'll ever be a problem.  By the time the interpolation algorithm has blown it up big enough to see the pattern, it has at the same time averaged intermediate pixels and smoothed them over.

(4) As with any 16 bit image, you should have already performed all your editing (like sharpening for example) prior to the final save.  That should completely eliminate even the most remote possibility of (1) above being an issue.

Mike
Logged
Bart_van_der_Wolf
Newbie
*
Posts: 20


View Profile
« Reply #26 on: May 10, 2014, 09:05:04 PM »

Sure, any of that is possible, but there are many factors here worth noting:

(1) Remember that the dithering only makes neighboring pixels differ by a single RGB unit: example, 110,120,130 and 110,121,130.  Most image operations (even reasonable sharpening) won't enhance the pattern by an appreciable amount because there's basically no edge there.

Hi Mike,

I agree, the likelihood of spotting it is slim, and if only a single bit in an RGB triplet is affected it's even less likely. I have however seen in the output dither that R and G and B were all affected in the same way. Maybe I need to check some more samples of both input (16 -> 8 bit) and output (profile) dither to see if that was an accident or not.

Quote
(2) LCMS has no dither option.  It was taken out in v2 and only existed in the v1 series.  This is my own dithering that I've found to be the least visible.  With the checkerboard pattern your eyes have to be able to resolve a single pixel to be able to see it.  Even on screen, I have to go as high as 400% zoom just to see it, and with many images, up to 800%.  And again, the "checkers" only differ by one unit in RGB value so, very hard to see!

Okay, I thought there was something in LCMS 2 because in my perusals on the LCMS site, I couldn't find anything about the dithering, yet in the source-code there was a Boolean Dither Flag or something like that. Maybe it's a remnant of the previous version.

Quote
(3) If you have a very low resolution image that needs a lot of interpolation (low res image printed large), it's possible that the pattern could get larger and be more visible, but then again, interpolation algorithms tend to smooth over individual pixel details!  So again, doubt it'll ever be a problem.  By the time the interpolation algorithm has blown it up big enough to see the pattern, it has at the same time averaged intermediate pixels and smoothed them over.

Yes, chance has it that it's gone due to interpolation. However, if the resampling factor effectively is 1.0 (image 600 PPI, output also 600 PPI) or something very close, the Smart output sharpening might enhance the earlier image dither, and add another layer of dither after that. To avoid the reinforcement of the dithers, maybe a fourth option would be safe to cover all grounds?

Something like:
  • None
  • 16 bit images only
  • Profile conversions only
  • Full (16 bit images and profiles)

Quote
(4) As with any 16 bit image, you should have already performed all your editing (like sharpening for example) prior to the final save.  That should completely eliminate even the most remote possibility of (1) above being an issue.

Agree, it's just something one should be aware of when creating a filter that sharpens.

Thanks again for providing some more insight into the inner workings.

Cheers,
Bart
« Last Edit: May 10, 2014, 09:07:15 PM by Bart_van_der_Wolf » Logged
admin
Administrator
Forum Superhero
*****
Posts: 4109



View Profile Email
« Reply #27 on: May 11, 2014, 12:46:32 AM »

I wouldn't worry too much about the additive effect of the double dither.  I did some pretty extensive pixel peeping in that area and I found that when that happened, it actually needed the dithering in both places.  In every case I tried, including both grayscale and ProPhoto color images, the result was better with both enabled.  You really have to have a demanding image, usually man-made gradients, to even have any dither at all but even if dithering is needed/used on both input and profiling, you still are only going to get a max deviation of 2 in each RGB channel.  And the average is still 1 because most won't change and the ones that do can even be canceled (input goes up and profile takes it back down for example).

Mike
Logged
rani
Jr. Member
**
Posts: 92


View Profile
« Reply #28 on: June 13, 2014, 06:49:29 PM »

I just wanted to say - great info!
Logged
Prof.Jewell
Newbie
*
Posts: 2


View Profile Email
« Reply #29 on: February 05, 2015, 04:36:32 AM »

Between you and me and the fence post ;-)

dcRAW *can* output an image in Pro Photo color space. The code is "-o 4 "

By the way one can put in *any* color space they might desire (I use my linear D65 variant of BetaRGB--hats off to Bart--but unfortunately one has to also put in a camera profile at the same time: " -p (camera) -o (* icc) "

Bob
 Qimage user from when it was only desperately need software for printing!
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!
Security updates 2022 by ddisoftware, Inc.