Luminous Landscape Forum
Raw & Post Processing, Printing => Printing: Printers, Papers and Inks => Topic started by: William Walker on April 25, 2014, 10:23:02 am
-
I am interested to know what the latest thinking is regarding 16 bit printing.
Everything I have managed to find seems to be a bit dated and the general opinion of those articles it that there is/was no visible difference in prints printed in 16 bit as opposed to 8 bit.
Is the situation still the same or is there new information available showing that 16 bit is superior?
Thanks
William
-
It's superior under a very, very strong loupe, viewing a print who's OS and driver support passing that data. That means Mac OS. And in the case of the loupe test, it was on an Epson 3880/4900. This was discussed here rather recently (I'd say this year) if you want to search the forum posts.
-
Still the same. High bit depth printing (let's say this because some printers actually only support 10, 12 or 14 bit internal processing) has always had advantages that are very, very hard to see. This coupled with the fact that checking 16 bit printing checkboxes sometimes screws up color management translates into a situation where we have to ask "Is this worth it?". High bit depth has huge advantages for image processing especially when big adjustments are made - that where we need it. But once our images are adjusted and sharpened and converted to they print space does it make sense to send it to the printer at high bit depth? Not much. For the masses, it just slows things down and creates the possibility of something going wrong. Those that choose to use high bit depth printings need to keep an eye on their prints and make sure nothing is going wrong, but there is some satisfaction in doing all the things needed to make the very best prints possible.
And just to clarify some details, Canon's iPF PS print plug-in made high bit depth printing without a RIP first possible in 2004 and it's completely flawless and reliable. Lightroom's 16 bit printing checkbox has been particularly prone to causing color space conversion problems with some but not all printers.
-
I often do 16 bits printing using the EWS of my HP z3200ps. And there is very visible difference for me. The prints are sharper, and you get more gradients and better transitions on subtle images. Hope it helps.
-
And there is very visible difference for me. The prints are sharper, and you get more gradients and better transitions on subtle images. Hope it helps.
Smoother transitions and gradations are what I see when printing granger rainbows but as to why bit depth might improve sharpness is beyond me... Sometimes I think there's a psycho semantic nature to these visual analyses..
-
Smoother transitions and gradations are what I see when printing granger rainbows but as to why bit depth might improve sharpness is beyond me...
It shouldn't but we have idea what the driver may be doing above and beyond sending just a higher bit depth.
When I asked Epson engineers several years about this, why the differences at the time were so visually tiny, they said that with that current driver technology, one wasn't expected to see a difference but what they could do in the future might change.
-
When I asked Epson engineers several years about this, why the differences at the time were so visually tiny, they said that with that current driver technology, one wasn't expected to see a difference but what they could do in the future might change.
When the whole 16 bit printing debate came up years ago Canon was unusually generous providing information about what they were doing on their printers to make this possible. They talked about their LCOA processor that allowed for high bit depth handling (not quite 16) on their iPF pritners and one could do a quick test with a granger rainbow with 8 and 16 bits in their PS printing plug-in and see the results. They mentioned that the costs involved to make this happen would prevent them (or anyone else) from doing so on a sub $1000 consumer printer. When I brought this up to Epson and questioned them on what internal bit depth handling they supported and on what printers they were very quick to say "no comment" which seems interesting. When asked directly if they had full 16 bit internal image handling on the 3880 they were quick to say "no comment" and did so with a devious smile! The Print Academy Evangelists were quick to say 'all Epson printers have 16 bit internal handling' but I'd love to hear more details straight from Epson on this.
-
The Print Academy Evangelists were quick to say 'all Epson printers have 16 bit internal handling' but I'd love to hear more details straight from Epson on this.
Not all but all the Pro versions do on Mac. And again, visually the differences sending 16-bit data with and without the check boxes do produce a tiny difference that requires a loupe (at least for these old eyes).
Not sure a Granger Rainbow is the best approach, certainly depending on the working space. That comment kind of goes along with the images used for testing differing profile packages. Indeed, the Granger Rainbow is useful in some respects, not in others.
-
Not all but all the Pro versions do on Mac.
It's just interesting that when pressed, Epson higher ups won't confirm this!
The processing power needed to process high bit depths increases exponentially I'm told. So 10 bit processing is computationally about twice as 'expensive' and 8 bit processing, and 12bits twice and expensive as 10 bit processing, etc. Canon was really forthcoming about saying they felt (12 or 14 bits - I forget) was the sweet spot that they choose to developed for. So for Epson's non-employee evangelists to come out and say all their printers have full 16 bit internal processing even though the drivers at the time they were made couldn't deliver 16 bit data, seemed questionable. And then when these same evangelists started bashing Canon for having only 12 or 14 bit internal support it felt like a lot of clever marketing speak without any transparency.
Not sure a Granger Rainbow is the best approach, certainly depending on the working space. Indeed, the Granger Rainbow is useful in some respects, not in others.
Of course, and my evaluation images contain a variety of images including the rainbow. My point was that when toggling between 8 and 16 bit modes on the iPF pritners the difference was most noticeable on these rainbows.
-
You can achieve 16-bit printing in Windows with a RIP, though.
-
You can achieve 16-bit printing in Windows with a RIP, though.
I'll add that Canon updated some of their XPS (16 bit) drivers on April 11, 2014 and posted them for Windows for some printers. No specifics as to what was done though. Wish they would say more as to what was done. Might be time to redo some profiles made with prior issues and see what if any shows up using them.
SG
-
Thank you for all the info!
Would it be fair to sum it up in this way:while the effects might not be easily noticeable, if you have the capability, print 16 bit?
William
-
Would it be fair to sum it up in this way:while the effects might not be easily noticeable, if you have the capability, print 16 bit?
Absoulty! All my files are high bit (16-bit). If I'm printing from Lightroom or Photoshop, I check the little 16-bit box in the driver, why not? And I've as yet never seen any difference in the color and thus the need to alter a profile at least printing this way to an Epson.
-
Would it be fair to sum it up in this way:while the effects might not be easily noticeable, if you have the capability, print 16 bit?
The potential problem with this is that you might print for the next 6 months before realizing: "wait a minute, everything seems a little off". I've been to enough people's studios that have experienced this - and when we unchecked this one checkbox and saw the color they were supposed to see all along, they were furious. Furious that the solution was so simple, that it took them so long to figure it out and furious that that checkbox was the problem all along.
If people call saying "My color is a little off when I print from Lightroom" the answer is always to uncheck the 16 bit printing checkbox. Seems like this problem is mostly with some Canon printers, but I haven't kept tight notes.
So I tell the masses to be careful and double check their print quality if they use it, and to leave it unchecked if they want to be sure they don't have problems. People usually fall into two camps - one group is detail oriented and wants to be thorough and use this checkbox, the other group is oriented towards the productivity of their image making and wants to minimize failure and doesn't use the checkbox.
I'm a print quality geek but even I think, realistically, you're not missing much by unchecking it but you are ensuring a reliable printing workflow.
-
If people call saying "My color is a little off when I print from Lightroom" the answer is always to uncheck the 16 bit printing checkbox.
All printers or just Canon? Because I've never heard nor seen this with an Epson. And when I measured the differences between using the check box on or off to the Epson, the dE values were so tiny, it was due to noise one expects from a Spectrophotometer between two readings (IOW, well below 1dE).
-
All printers or just Canon?
Well I work with a diverse base of clients that use everything under the sun, and that checkbox is causing problems for a number of them. Although I haven't drawn a direct correlation to what printers, off the top of my head I can think of several that are using Canon printers...
-
Well I work with a diverse base of clients that use everything under the sun, and that checkbox is causing problems for a number of them.
Just sayin, not on my radar nor reported to me by my diverse base of clients. It would be useful to get to the bottom of it, but I have no experience with it being an issue, that's all.
The issue that's pissing me off in terms of LR is 'corrupted' display profiles that wack the previews only there and V4 profiles that cause the app to barf. It's reported often on the Adobe UtoU forum.
-
Barfing apps! I can see the icon animation in the dock right now, LOL!
-
I can testify that 16-bit printing on my Epson 7900 from Photoshop CS6 (MAC OS 10.8.2) consistently destroys the colour management. And it isn't subtle. After a week of terror and trials I found that it was the 16-bit box that was responsible for the onset of colour management problems when I upgraded my OS to the current version. It looks like the software uses sRGB as the printer profile; as I said, not a minor problem. Before this problem I had always used 16-bit printing, at least ever since it was available. VERY upsetting.
-
I print 16 bit out of LR. I can certainly see the difference. I'm printing from D800 RAW files. BUT.. I only really see the difference on images where there are nice smooth gradients. Like a sky. 16 bit always makes the gradations smother. My color management never has any issue. It's about as exact to what I'm seeing on screen as I can get.
-
A while ago I experimented printing gradients in 16-bit and 8-bit on an Epson 7900. I printed all kind of gradients, some very long. There was exactly zero difference between the two methods. I was really surprised by the results as I certainly expected to see some subtle steps in the 8-bit version. There were absolutely none. My conclusion is that either the driver applies some kind of dithering to 8 bit file or that the intrinsic dithering used by inkjet printers to apply ink droplets makes any difference invisible to the human eye.
For the effect of noise (and I assume also dithering) and bit-depth see: http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/noise-p3.html (http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/noise-p3.html)
There is a measurable different when printing uniformly colored patches but the only scenario where it would matter is when validating icc profiles (not when creating them as the source file is 8-bit).
If anyone knows a method to demonstrate an observable difference in the smoothness of gradients printed in 8-bit vs 16-bit, please share!
-
I'm curious if those of you who don't see any difference are printing from JPEG's or anything that was a JPEG in some part of it's image journey. Clearly if you are printing 8bit images, like a JPEG, you won't see any difference.
-
Not printing in jpg. I printed long dither free, noise free, silky smooth gradients. No difference.
-
A while ago I experimented printing gradients in 16-bit and 8-bit on an Epson 7900. I printed all kind of gradients, some very long. There was exactly zero difference between the two methods. I was really surprised by the results as I certainly expected to see some subtle steps in the 8-bit version. There were absolutely none. My conclusion is that either the driver applies some kind of dithering to 8 bit file or that the intrinsic dithering used by inkjet printers to apply ink droplets makes any difference invisible to the human eye.
For the effect of noise (and I assume also dithering) and bit-depth see: http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/noise-p3.html (http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/noise-p3.html)
There is a measurable different when printing uniformly colored patches but the only scenario where it would matter is when validating icc profiles (not when creating them as the source file is 8-bit).
If anyone knows a method to demonstrate an observable difference in the smoothness of gradients printed in 8-bit vs 16-bit, please share!
As I said in my previous post, using my Hp z3200ps with the EWS and sending a 16 bits tiff file directly to the printer, the difference in very clear for me. As the user manual of the HP3200ps states, the conversion from 16 to 8 bits printing is done inside the printer hardware. No color managment issues if you have the right paper preset and icc profile for the paper selected. Neither is a OS involved in the process.
-
It could be that there is a observable difference between '16bit > 8bit > icc' vs '16bit > icc > 8bit'.
My tests were performed with application and printer driver CSM off.
-
It could be that there is a observable difference between '16bit > 8bit > icc' vs '16bit > icc > 8bit'.
My test were performed with application and printer driver CSM off.
This is what the HP z3200ps user´s manual states:
HP Designjet Z3200PS Printer Series - Print 16-bit color images
Print 16-bit color images
In a 16-bit RGB image, each of the three primary colors is encoded by a 16-bit value, so that each pixel takes up 48 bits.
If you print your 16-bit color images through a printer driver, they will be reduced to 8-bit colors before they reach the printer.
In order to send a 16-bit color image to the printer, you must save it as a 16-bit color TIFF or JPEG file, then send the file directly to the printer without using a printer driver (see Using the Embedded Web Server to print files ). In this case, color management is done on the 16-bit color image, and is therefore done more accurately. The image is still reduced to 8-bit colors for final printing.
Some applications refuse to save a 16-bit color image in JPEG format; others automatically reduce it to 8-bit colors. A TIFF file generally gives a higher-quality result, and is recommended.
-
The image is still reduced to 8-bit colors for final printing.
So it seems that no matter what, the HP Z3200 only ever use 8-bit to print. If you let the HP printer (driver) manage colors (uncommon), as opposed to letting the application do the job (more typical), this '16bit > 8bit > icc' could happen, which isn't optimal.
Now what about PS, LR, Qimage? How do these applications actually handle the printer color profile conversion of a 16-bit image before sending it to the printer driver? I assume they perform '16bit > icc > 8bit'? Do Epson and Canon drivers ever actually send 16-bit data to the printer?
-
Now what about PS, LR, Qimage? How do these applications actually handle the printer color profile conversion of a 16-bit image before sending it to the printer driver?
Can't tell you how Qimage does it, but if you are printing a 16 bit image using either Photoshop or Lightroom to manage color AND you use the Adobe ACE CMM, then the application does a color transform from the current color space to the output color space (the printer profile) in 20-bit precision. So, while the print pipeline can only handle 8 bit (except for Epson on the Mac or the Canon export plug-in) that final conversion from the image color space to the printer color space has 20-bit precision before the final 8-bit conversion...
Which is one reason that comparing printing in 16-bit is hard to compare to 8-bit. In essence, on Mac or Windows the print pipeline can already handle the 16-bit to 8-bit in high precision. So, it's hard to prove that printing in 16-bit is superior...
In point of fact, the only time I've ever seen a real advantage is when print long and subtle synthetic gradations...Illustrator or InDesign gradations can show better/smoother gradations when printed using a 16-bit print pipeline.
Personally, I'm pretty much on the fence about image detail in a 16-bit vs 8-bit print pipeline. Since I'm using 16-bit ProPhoto RGB images and printing primarily using Lightroom, I go ahead and print using the 16-bit print option. But, I'm using LR manages color and get the benefit of 20-bit precision anyway...but if I forget and print using the normal Epson 8-bit pipeline, I'm not seeing any substantial differences.
If you are printing 16-bit using an Epson on Mac (or using the Canon export plug-in) you may as well use the 16-bit option. The only downside is slightly slower print spooling times...
But if you are printing on Windows using an Adobe app managing colors, the differences will be so subtle as to be irrelevant.
Yes, it would be useful if both OSs offered 16-bit print pipelines...on Windows Photoshop has the ability to use a 16-bit display pipeline (don't ask me why Apple has failed to offer 16-bit).
-
In point of fact, the only time I've ever seen a real advantage is when print long and subtle synthetic gradations...Illustrator or InDesign gradations can show better/smoother gradations when printed using a 16-bit print pipeline.
Hi Jeff,
I think that the conversion from a large gamut colorspace, with relatively large quantization steps per channel, down to a generally much smaller print-medium colorspace, with relatively much smaller quantization steps to cover a smaller possible range, is where the potential damage is occurring. Afterall, ProPhoto RGB is not recommended for an 8-b/ch colorspace when significant image editing is yet to take place, and profile conversion is IMO significant image data manipulation.
It might be interesting to repeat such a gradient print, one with a prior conversion to the output profile in 16-b/ch, then changing the mode to 8-b/ch, and compare that print out to a full bit depth pipeline output.
Of course, dithering in an 8-b/ch profile conversion can attempt to hide some of the problems.
Cheers,
Bart
-
After two pages, I believe the general answer is, you have to test this with your particular workflow. The OS, print driver, application, color space and more seem to play a role here and there are too many variables. I'd suggest that if you have high bit data, might as well send it to the printer with the hope it's getting there <g>. In a raw workflow, I think most of us will work with high bit data and probably wide gamut data going off to the printer under our control. So if you have options for sending it that way, do so. I would expect that if you do run into differences in color and tone sending 8-bit vs. 16-bit, build the profile with a 16-bit target. Again, my experience is that I can send 8-bit vs. 16-bit data to my Epson's with the same profile but YMMV. It might be interesting for those that have seen these differences to send a patch target through as both 8-bit vs. 16-bit, them measure them so we could plot the differences in something like ColorThink. I'd love to see where in color space these differences are seen.
-
In point of fact, the only time I've ever seen a real advantage is when print long and subtle synthetic gradations...Illustrator or InDesign gradations can show better/smoother gradations when printed using a 16-bit print pipeline.
Jeff, thank you for your informative post. I’m interested in trying to reproduce the results you obtained with the synthetic gradients. I did some test a couple years back with long gradients and saw no difference.
I printed from a Mac to an Epson 7900, all CMS off. Linear gray gradients were created in PS 16-bit with dither off. I used partial gradients, with different gray level ranges, 23” long @ 360 dpi, no resize.
I haven’t tried illustrator, radial or colored gradients.
Jeff, do you remember what kind of synthetic gradients you used to evaluate smoothness? It would be neat if there was a image we could all use to evaluate our workflow for smoothness.
-
Jeff, do you remember what kind of synthetic gradients you used to evaluate smoothness? It would be neat if there was a image we could all use to evaluate our workflow for smoothness.
All I remember is when we were putting together the Epson Print Academy Track II around the time that the 79/9900 were first introduced and Epson was touting the 16-bit print pipeline, Epson had some Illustrator files that could show a smoother gradation when printed in 16-bit vs 8-bit. Note, as I recall we weren't using the Adobe ACE CMM, I think it was the Apple CMM (which is less precise than ACE). As I recall there were some color gradations and neutral gradations that showed areas where the gradation was a bit blocky in 8-bit vs the 16-bit. I'm pretty sure they were printed from Illustrator.
Sorry I can't any further...and truth be told, the differences seen were subtle. I've never seen any differences when using Photoshop or Lightroom when printing photographic images with grain or sensor noise.
-
Note, as I recall we weren't using the Adobe ACE CMM, I think it was the Apple CMM (which is less precise than ACE). As I recall there were some color gradations and neutral gradations that showed areas where the gradation was a bit blocky in 8-bit vs the 16-bit. I'm pretty sure they were printed from Illustrator.
So it's conceivable that any difference you saw back then was introduced during the color transform performed by the CMM, not purely by the printer using or not using 16-bit data, correct? And if so the benefit of the 16 bit pipeline is independent of the brand and type of printer, OS, etc. The only variables that matter are which CMM does the transform and at what bit depth. (The horse is not quite dead yet ;D )
-
Apple CMM has a 16-bit color transform. Adobe ACE (originally done by Thomas Knoll) has 20-bit precision. It also has Black Point Compensation (which may or may not be a real factor, it is, however another potential factor).
But, in the grand scheme of things, I don't think there is a "smoking un" here...YMMV :~)
-
Now what about PS, LR, Qimage? How do these applications actually handle the printer color profile conversion of a 16-bit image before sending it to the printer driver? I assume they perform '16bit > icc > 8bit'? Do Epson and Canon drivers ever actually send 16-bit data to the printer?
For Qimage a recent discussion Mike participated in, makes it clear:
http://ddisoftware.com/tech/qimage-ultimate/on-the-subject-of-16-bitchannel-internal-workings/
--
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
April 2014, 600+ inkjet media white spectral plots.
-
For Qimage a recent discussion Mike participated in, makes it clear:
http://ddisoftware.com/tech/qimage-ultimate/on-the-subject-of-16-bitchannel-internal-workings/
So, Qimage does 16-bit>8-bit>icc. Bummer.
-
So, Qimage does 16-bit>8-bit>icc. Bummer.
Hi,
In practice, there is hardly ever any detectable difference in output quality between 16-bit versus 8-bit pipelines, and if there is, it's only possible to demonstrate in a side by side comparison.
I was especially pleased to learn that that the colorspace conversion is done last, after the creation of new pixels at the native printer driver resolution (and Qimage has some very good resampling algorithms to choose from), and after output sharpening (which is halo free, so can be pushed quite far). That's a lot of data to convert, but it does give the best results because the pixels are finished.
Choosing a better workingspace profile than ProPhoto RGB will also help.
Cheers,
Bart
-
Choosing a better workingspace profile than ProPhotoRGB will also help.
Hum, what do you think is a better working space?
-
Hum, what do you think is a better working space?
Hi Jeff,
Smaller gamut than ProPhoto RGB, and large enough for the most demanding output medium.
ProPhoto RGB has relatively large quantization steps due to the large gamut that needs to be covered and then mapped down to a smaller output quantization which leads to potential posterization (different values getting the same resulting value). Also, a gamma of 2.2 provides a better spread of data points throughout the gamut space than the gamma 1.8 of ProPhotoRGB (see BruceLindbloom's analysis of his Beta RGB colorspace (http://www.brucelindbloom.com/index.html?BetaRGB.html)). Beta RGB has a 99 percent coding efficiency (http://www.brucelindbloom.com/index.html?BetaRGB.html), ProPhoto RGB 87.3 percent.
Cheers,
Bart
-
In practice, there is hardly ever any detectable difference in output quality between 16-bit versus 8-bit pipelines, and if there is, it's only in a side by side comparison.
...
Choosing a better workingspace profile than ProPhoto RGB will also help.
I love Qimage for its sharpening, upsampling, etc. And the OCD in me will eventually recover from the realization that I've been throwing all these bits away for so long. :o
ProPhoto is currently the only space available in ACR that doesn't clip the gamut of the printer. AFAIK, the quantization steps are small enough in 16-bit. But you are right, it's probably not a good space to be in 8-bit.
-
I love Qimage for its sharpening, upsampling, etc. And the OCD in me will eventually recover from the realization that I've been throwing all these bits away for so long. :o
And if you can't see the difference or need a really strong loupe, what's the big deal?
ProPhoto is currently the only space available in ACR that doesn't clip the gamut of the printer. AFAIK, the quantization steps are small enough in 16-bit.
Exactly. It's moot if you're using an Adobe raw processor. Plus I really, really doubt Thomas Knoll ages ago would have selected this space if there were issues and one has to wonder how many images (millions?) have been run through this process and color space since ACR was introduced with few if any reporting issues with the color space selection.
But you are right, it's probably not a good space to be in 8-bit.
It's 'more better' in high bit but I recall Bruce Fraser doing a lot of testing for Kodak when the space was being introduced doing work in both 8-bit and high bit, I seem to recall him suggesting it's not a significant issue. I'll see if I can dig up the posts but we're going back a very long time. But again, in the raw workflow you refer to, it's high bit.
-
ProPhoto RGB has relatively large quantization steps due to the large gamut that needs to be covered and then mapped down to a smaller output quantization which leads to potential posterization (different values getting the same resulting value).
And in all my years of using ProPhoto RGB since Bruce Fraser convinced me to use it, I've never seen any quantization errors (due to ProPhoto RGB) on any RGB or CMYK images I've ever made. Yes, I've heard the smaller gamut is more efficient argument...I've never seen any real image evidence. Got any? And yes, I've talked to Bruce Lindbloom as well as Thomas Knoll about this "issue" and Thomas isn't convinced–which is why he chose ProPhoto RGB (linear gamma) as the working space for Camera Raw (and also Lightroom).
You'll note that the last time Bruce updated his Beta RGB web page was in 2003-which was the year that Camera Raw first shipped. I'm pretty sure that if Thomas though Beta RGB was a better color space because of coding efficiency, he would have used it. He didn't...
The only caveat is that using 16-bit for ProPhoto RGB is important because in 8-bit there's a greater risk of quantization errors than in 16-bit (actually 15-bit plus one level).
Just to be clear, it was Bruce Fraser, doing consulting work for Eastman Kodak who tested ROMM RGB (Reference Output Medium Metric). And yes, in early testing he was concerned about the potential of quantization errors-which lead him to develop his own Bruce RGB. But his extensive testing convinced him that the risk of quantization errors was overblown. And all the color geeks I know agree with him :~)
So, you got proof?
-
Also, a gamma of 2.2 provides a better spread of data points throughout the gamut space than the gamma 1.8 of ProPhotoRGB
Dug this old stuff up:
> Anyone know the rational why Kodak used the same working space gamma?
ROMM (ProPhoto) has an 8bpc and 16bpc implementation, and with the
limited precision offered with 8bpc with such a huge space, going
from XYZ to RGB back to XYZ could produce significant errors in
blacks. The steeper the TRC (tone response curve), the bigger the
reversal error. So a TRC defined with gamma 1.8 was chose, largely
for reversibility. It's a useful characteristic because, of course,
we convert captures into that space for editing and then we convert
them out of the space for output.
And
About ProPhoto RGB, transfert function and sRGB…
Color gamut of ProPhoto RGB, alias Kodak ROMM RGB, is defined by D50 white point, a red primary on the spectrum locus and two primaries “green and blue” OUTSIDE the spectrum locus (imaginaries). So, Pro Photo RGB waste 13% or codification capabilities in imaginaries colors… Its CIELAB volume is approximately 2.2 time the one of Adobe RGB (1998). This is a very very large gamut.
R : x=0.735 y=0.265 Y=0.28804
G : x=0.160 y=0.840 Y=0.71187
B : x=0.037 y=0.0001 Y=0.000096
Transfert function don’t define color gamut but response to light intensity/Luminance. When Kodak specified it, ROMM RGB transfert function was based on an encodage gamma of 1/1.8 plus a slope of 16 for low levels :
Output = (Input)^(1/1.8) if 0.001953<Input<1
Output = Input x 16 if 0<Input<0.001953
Gamma curve is NOT an exponential curve. The exponent is a numerical constant equal to 1/1.8 for ProPhoto RGB. The 16 slope is linear but is NOT linear gamma… Linear gamma or linear color space is space with gamma =1. This means Output=Input.
Now, ProPhoto RGB ICC profiles forget always the slope. If you inspect ProPhoto RGB profile published by Adobe, you will only see a simple 1/1.8 gamma. There is no consequence of this undocumented modification because CMM (Adobe, Kodak…) generally substitute a 16 slope to gamma curve when input is very low. Because calculation is dangerous around zero or infinite…
Because ProPhoto RGB transfert function is now only defined by a simple gamma value (1/1.8) for each primary color, ProPhoto RGB profile is a light profile, as Adobe RGB and all common color matrix working spaces (1 Ko).
sRGB is a different case. Its transfert function is not defined by a gamma value. As original ROMM RGB, its transfert function is composed of two parts : an analytical curve (more complicated than the trivial gamma curve Output = (Input)^(gamma)) plus a slope for low levels. According to ICC standard, it is impossible to define such a curve with simples analytical parameters. So, in sRGB profiles, transfert function is defined by 3 x 1024 points (one for each primary). That is why sRGB profile is 4 times heavier than Adobe RGB (1998) and more difficult to use in calculations.
Jean Delmas
Bottom line is, it works well and has been used a long time without the crys from users or other color geeks it isn't an acceptable working space. Much like this discussion of bit depth sent to a printer and the results, YMMV and it's a bit of minutiae.
-
http://books.google.com/books?id=hFx18ukMq_gC&pg=PT127&lpg=PT127&dq=Bruce+Fraser+ProPHoto+8-bit&source=bl&ots=pRq90klchr&sig=xip3VXvRA5fjF0TxyAMoPAKrA6k&hl=en&sa=X&ei=wJ5hU_O9KZG0yATI1oLIBQ&ved=0CDoQ6AEwAg#v=onepage&q=Bruce%20Fraser%20ProPHoto%208-bit&f=false
Bruce writes he designed BruceRGB for CMYK work, therefore NOT as a replacement for ProPhoto RGB because he had an issue with it. Big difference. And in the link above, he writes ProPhoto RGB is OK for minor editing on 8-bit per color images.
-
Bruce writes he designed BruceRGB for CMYK work, therefore NOT as a replacement for ProPhoto RGB because he had an issue with it.
Ah yes...now I remember, Bruce was worried that Adobe RGB (originally SMPTE 240M with some typos) was too big and ColorMatch was too small. Hence BruceRGB...and yes, that was a long time ago :~)
-
So, you got proof?
Hi Jeff,
As you know, it's hard to prove something that's hardly noticeable in regular images (with photon/read/pattern noise). Nevertheless, it may be interesting to conduct an experiment that's goes a bit further than handwaving. One might even learn something.
May I propose the following, so others can also participate with their particular tools / workflow / output profiles and devices:
1. Download this image (http://bvdwolf.home.xs4all.nl/main/downloads/GrangerRainbow.zip) (it's in a ZIP archive to make sure no download corruption can take place) of a 16-b/ch version of a Granger Rainbow. It's designed to have more than 6 pixels per degree of hue-change, and plenty levels in the vertical brightness/saturation axis.
2. Open the image in e.g. Photoshop.
3. In the Missing Profile warning dialog select "Leave as is (don't color manage)"
3. Make 2 additional copies, 3 copies in total.
4. On copy #1, Assign a ProPhoto RGB colorspace profile.
5. On copy #2 and #3, Assign a Beta RGB colorspace profile.
6. Convert the copy #3 from Beta RGB to ProPhoto RGB.
The copies #2 and #3 contain the same colors, only mapped to two different colorspaces. Copy #1 is a torture test for any system, because it contains imaginary 'colors' and Out-of-Gamut colors for all output modalities, so we are guaranteed to see issues after conversions. We could also additionally make a Copy #4 (e.g. a duplicate of Copy #2) for an 8-bit/channel output pipeline, with a mode change to 8-b/ch RGB if we stay in Photoshop.
7. Now resample all the images to 360% size (like a conversion from 300 to 360 PPI and a 3x magnification to make it easier to see the effects at 100% zoom), while using Bicubic Smoother to reduce the risk of adding resampling artifacts.
8. Now Convert the colorspace profile of all images to that of an output modality's profile, e.g. a display profile to evaluate on a monitor display (sRGB or Adobe RGB capable) or a paper profile of choice for the evaluation of printed output.
The posterization issues are most likely to occur in the Blue/Cyan to Yellow range, especially at the transitions between display primaries or at transitions between ink colors. Look at the brightest least saturated regions for curved posterization and the regions just below the middle of the vertical brightness/saturation scale for horizontal posterization bands where I'd expect the most prominent trouble, if any. One may prefer to crop out that area to avoid wasting too much ink when actual prints are made. The printing process, dithering/weaving, and paper structure may still hide remaining issues, so nothing beats an actual print.
Of course, these output profiles may introduce additional modality specific corrections and non-linearities on top of the colorspace conversions. So we're looking for pipeline differences, not non-linearity issues (which are almost impossible to avoid). Again, these artificial targets are much more critical than real images, but that's because we want to spot the issues and avoid them (if possible) by modifying the workflow.
Maybe you have a better suggestion, so feel free to share your thoughts. The famous "Twenty-Eight Balls.tif" target is also a useful basis for testing, but it's a bit larger, so it requires more paper.
Cheers,
Bart
-
Ah yes...now I remember, Bruce was worried that Adobe RGB (originally SMPTE 240M with some typos) was too big and ColorMatch was too small. Hence BruceRGB...and yes, that was a long time ago :~)
Danny Pascale has a nice summary of the RGB colorspaces (http://www.babelcolor.com/main_level/links.htm#RGB_spaces_sites) that are often mentioned in this context.
Cheers,
Bart
-
Bruce on BruceRGB early on: http://www.creativepro.com/article/out-of-gamut-finessing-photoshop-color
From the ColorSync list:
On Feb 14, 1999, at 11:17 AM, Bruce Fraser <bruce@pixelboyz.com> wrote:
5.) I designed BruceRGB with a very specific purpose in mind, which was to
provide a safe space for people who need to do moderate-to-heavy correx on
24-bit RGB that's ultimately headed for CMYK output. It's a compromise
between the gamut clipping of ColorMatch RGB and the quantization problems
in Adobe RGB (1998). People who care about preserving the E6 gamut
shouldn't use it.
Back to ProPhoto RGB (and this fine site):
http://www.luminous-landscape.com/tutorials/prophoto-rgb.shtml
One of the most knowledgeable voices in the area of colour management over the last few years has been Bruce Fraser, the co-author of the current definitive work on colour management for photographers – Real World Color Management. In articles that he's written elsewhere Bruce suggests that digital photographers should consider working in the much large ProPhoto RGB colour space. (ProPhoto RGB was developed by Kodak).
-
6. Convert the copy #3 from Beta RGB to ProPhoto RGB.
Before anyone tries this, an important question: what should Dither be set for within the Color Settings? Should that setting be maintained for just the test or all conversions going foward?
And how would the results of this in a raw converter like LR/ACR be tested?
-
And if you can't see the difference or need a really strong loupe, what's the big deal?
Hi Andrew,
I don't think anybody considers it to be a big deal, just part of a quest for the best possible output quality one can achieve with the means at hand. As Jeff said, he also only once saw a demonstration of the small differences, on a specifically construed 'image'. It's hardly an issue in day to day output of real camera images that also contain photon-shot-noise and read-noise. Designs in Illustrator or similar applications, without adding dithering to gradients, may be the more risky data sources.
It's moot if you're using an Adobe raw processor. Plus I really, really doubt Thomas Knoll ages ago would have selected this space if there were issues and one has to wonder how many images (millions?) have been run through this process and color space since ACR was introduced with few if any reporting issues with the color space selection.
Again, on the unlikely occasion that an issue is visible, one then additionally needs to make the mental connection to a potential profile issue. Statistically even less probable to occur, especially if one is not even aware that the workingspace choice can make a difference in some scenarios ...
I agree that keeping the data in as high a bit depth as possible during conversion won't hurt, if the printer driver is also 16-bit. Otherwise, there will still be a colorspace reduction to 8-b/ch and a smaller gamut output space, which means rounding/truncating and remapping that will reduce differences to same values.
Cheers,
Bart
-
Before anyone tries this, an important question: what should Dither be set for within the Color Settings? Should that setting be maintained for just the test or all conversions going foward?
Hi Andrew,
Maybe it has changed for Photoshop CC, but on my CS6 , Dithering is only available for 8-bit/channel mode (for a reason).
And how would the results of this in a raw converter like LR/ACR be tested?
Good question, but I'm not sure whether the output pipeline is quite comparable with that of Photoshop or other image editors. Maybe it is, I just can't say for sure. Isn't the Melissa workingspace a given, or can the user even influence that?
Cheers,
Bart
-
And how would the results of this in a raw converter like LR/ACR be tested?
Ah, therein lies the issue for me...since I use ACR/LR, my raw processing working space is already in ProPhoto RGB primaries. In ACR for CC, I can specify any RGB, CMYK or even Lab as the output color space, but it will be going from ProPhoto RGB primaries to another smaller (with "better" coding efficiency) RGB color space and then ultimately to yet a final smaller RGB color space for printing. So, will the secondary color space's increased coding efficiency offset what are going to be increased quantization errors going from ProPhoto RGB to the next working space before the final output profile? Hum, not sure that's a rabbit hole I want to go down.
In the case of Lightroom, the above wouldn't apply because unless you take a trip outside of LR, you couldn't use an intermediate smaller gamut working space since LR goes from PP RGB > whatever output profile one would use for printing. Even if you did make the effort and go from LR into Photoshop, there's still the secondary color transform required with all that entails. Then if you save the image back into LR for further processing, that additional processing would be done on top of the new secondary working space which would require transforming back into PP RGB for any additional LR adjustments (such as might be done based on soft proofing) and then a final color transform for the output profile...
That seems like a lot of work and color transforming going on merely to improve the coding efficiency from 87.3 to 99% when the process starts in ProPhoto RGB in the first place.
Nope, I think I'll stick to good old ProPhoto RGB for my work, I don't print Granger Rainbows...
:~)
-
Maybe it has changed for Photoshop CC, but on my CS6 , Dithering is only available for 8-bit/channel mode (for a reason).
You're correct (I sit corrected). I've done so many of these tests where I needed to ensure the check box was OFF I didn't realize we're (duh) talking about 16-bit for all testing.
Good question, but I'm not sure whether the output pipeline is quite comparable with that of Photoshop or other image editors. Maybe it is, I just can't say for sure. Isn't the Melissa workingspace a given, or can the user even influence that?
MelissaRGB is the working space used for Histograms and RGB percentages along with a 2.2 TRC, the internal color space is using a quite different TRC hence the question. But as I said, it's moot, we can't avoid using that color space in LR/ACR. But one could build a ProPhoto RGB working space with a 1.0 TRC in Photoshop and do your tests there which might be interesting. At least to compare the two methods. It wouldn't tell us anything about the ACR engine for certain and since there's no way around it, probably isn't important unless one were trying to justify moving to another raw converter. Getting the facts of it's internal color space isn't easy. IOW, Adobe has been up front about what it uses for the processing.
-
Nope, I think I'll stick to good old ProPhoto RGB for my work, I don't print Granger Rainbows...
I do along with a number of other such 'synthetic' images, a few really good ones our friend Karl Lang built. But we do this to evaluate output profiles and how they affect all those colors. And depending what built the profiles, the differences are significant. I say that because I suspect that part of the pipeline plays a massively larger role than anything prior. We've sent the same averaged data used to build profiles to different packages using the Granger Rainbow and man, the differences can be visually enormous, especially with a perceptual intent.
I guess what I'm suggesting is that the output profile plays such a huge role when you compare them with all the other data being the same, it would be nearly impossible to say: This effect is the working space, this effect is the CMM, this effect this the bit depth.
-
This has been an interesting discussion, very good more to me more info on ProPhoto RGB vs Adobe RGB (1998).
In the last two years, I have moved back to Adobe RGB (1998), mainly for two reaons.
My NEC monitor can't even display 100% of the Adobe RGB (1998) colorspace (even their latest versions claim only 99.3)
Constant problems soft proofing for printing, with colors out of gamut, (when using Prophoto RGB).
My print profiles, have always mainly be the generic Epson ones or the profiles made by paper companies, Breathing Color, Canson, Moab etc. I have also worked with creating custom profiles with i1 publish.
With both, images in the ProPhoto RGB color space, 16 bit tend to have too much out of gamut color, mainly blues. This is worse with canvas.
My printer is a 9900 and and I windows based, win 7 64 bit, so I realize all my work is 8 bit output as I am using the Epson driver.
Is a better workflow to create the image in Prophoto RGB, then convert to Adobe RGB (1998) for images I want to print?
Thanks
Paul
-
As a complete layman when it comes to this type of discussion, would I be wrong in suggesting that this extract from Andrew's link to "Real World Adobe Photoshop" is the simplest argument for using ProPhoto RGB?
-
With both, images in the ProPhoto RGB color space, 16 bit tend to have too much out of gamut color, mainly blues. This is worse with canvas.
Hi Paul,
That is an additional issue, after postprocessing and boosting saturation, one now needs to downscale that filled to the brim gamut to fit inside a smaller gamut output colorspace. It is partly manageable by soft proofing, but that requires all components in the chain of events to play nicely together.
Holding back a bit on saturation boosts of primary/ink colors may help. The difficulty is that many images only fill part of the gamut, e.g. a red tomato on a red surface will leave Green and Blue under-utilized. So part of the trick is learning to judge whether the gamut limits of the smaller output gamut are exceeded significantly yet, or not.
The Argyll CMS has a few tools that allow to map the actual colors in an image inside the Profile's 3D Gamut. One can instead also use a PS action to show a more accurate image of the potentially clipped colors by comparing two image versions, and correct based on a mask (a sort of selfmade perceptual remapping) before actual conversion for output.
Cheers,
Bart
-
My NEC monitor can't even display 100% of the Adobe RGB (1998) colorspace (even their latest versions claim only 99.3)
But depending on the output device, you could use more of those colors for the output. So the question we have to ask ourselves is this: do you use a larger gamut space that contains colors you can print but can't see? Or use a smaller color space so you can see those colors but by doing so, limit what you send to the output device?
-
A study by american museums on digital preservation of 2D art (FADGI) showed that the impact on the color quality as encoded in the different colorspaces (sEGB, aRGB, pRGB) was actually insignificant. note that most colors captured were well within sRGB, a few within aRGB and of the classical art (medieval paintings etc), none was is pRGB. The encoding process aka tools however did. Unfortunately i did not find a indication as to which color encoding tools were tested.
There was an awful lot more information presented in a several hours presentation, but the part on the colorspaces i remembered.
For me it indicated that the actual colorspace used for the encoding is not so significant as long as it is big enough to hold all colors of given image.
One area where the color capture fails is the blue, cobalt blue and blues close to cobalt blue. This was attibuted to the fundamental difference in how humans "see"colors vesus how cameras "see"colors.
-
A study by american museums on digital preservation of 2D art (FADGI) showed that the impact on the color quality as encoded in the different colorspaces (sEGB, aRGB, pRGB) was actually insignificant.
But the capture was of 2D art work? Because I have captures of actual real world stuff and often, depending on subject of course, it falls outside Adobe RGB (1998).
Some examples in this video:
High resolution: http://digitaldog.net/files/ColorGamut.mov
Low Res (YouTube): http://www.youtube.com/watch?v=n0bxSD-Xx-Q
For me it indicated that the actual colorspace used for the encoding is not so significant as long as it is big enough to hold all colors of given image.
And as illustrated, for that, ProPhoto RGB is necessary or something larger than sRGB or Adobe RGB (1998).
-
For me it indicated that the actual colorspace used for the encoding is not so significant as long as it is big enough to hold all colors of given image.
Unless your only goal is to reproduce art work, I don't think the argument is relevant here. It doesn't matter that the capture or the scene's colors are entirely within a given colorspace. What matters is whether or not a given colorspace can hold the entire output colorspace. This is because processing of the captured image could expand its gamut.
-
As a complete layman when it comes to this type of discussion, would I be wrong in suggesting that this extract from Andrew's link to "Real World Adobe Photoshop" is the simplest argument for using ProPhoto RGB?
It doesn't seem to be the to me if the final output is a inkjet print, which is what I am working for. I don't think Epson can print to the Prophoto RGB color space based on the number of out of gamut softproofs I will get. Plus if you are out of gamut, then most times reducing saturation ruins the look of the image, thus all the time spent, and converting to Adobe RGB (1998) also seems to lose the look, where as working in the Adobe RGB (1998) space tends to give me images that softproof to the profiles for the 9900. This just gets worse if you are working with canvas, printing on matte canvas to coat later as the available gamut seems to be much less. I realize Glossy canvas has a larger working gamut, but there are other issues with glossy canvas that make me stay with matte. I realize that ProPhoto RGB has Billions of more colors, just can't get it to softproof cleanly very often.
If I could get the Prophoto space to softproof better, I would definitely stay there.
Paul
-
It doesn't matter that the capture or the scene's colors are entirely within a given colorspace. What matters is whether or not a given colorspace can hold the entire output colorspace. T
Both are important. We can't (easily) pick and choose what encoding color space we can use based on the image we might capture. Hence use a big one. Beats using a smaller one where the result is clipping of colors. And that's probably why Adobe raw converters use such a big space.
I suppose if you're in a studio setup, capturing art work, one could use something smaller. But for the rest of us?
-
If I could get the Prophoto space to softproof better, I would definitely stay there.
But you are not using ProPhoto to soft proof, you're using the output profile which like ProPhoto, may contain colors that are outside your display gamut. The limitation is the display and in more ways than just it's gamut. Again, toss colors you can output just so you can see them?
-
Both are important.
Correct. I meant to say it isn't sufficient for the entire captured gamut to fit within a colorspace. It's necessary but not sufficient...
-
It doesn't seem to be the to me if the final output is a inkjet print, which is what I am working for. I don't think Epson can print to the Prophoto RGB color space based on the number of out of gamut softproofs I will get. Plus if you are out of gamut, then most times reducing saturation ruins the look of the image, thus all the time spent, and converting to Adobe RGB (1998) also seems to lose the look, where as working in the Adobe RGB (1998) space tends to give me images that softproof to the profiles for the 9900.
I'm not sure how you are soft proofing, which what application and on what display, but I gotta tell you that being concerned about out of gamut color warnings is a wast of time. In Photoshop and Lightroom, OOG is a simple binary in/out indication. It tells you NOTHING about HOW the OOG colors will look. That's what soft proofing is designed to tell you.
I cringe when I hear people say that they try to desaturate OOG colors for the purposes of getting the color in gamut. Of course, that ruins the image...what matters most is deciding which rendering intent will best render the color (in or out of gamut) and what will the image look like when printed. This predictive function of soft proofing allows you to use the limitations of the output media to try to get the optimal output in terms of color & tone.
While ProPhoto RGB certainly has a ton of colors (some imaginary) that the Epson 9900 can't print, there are a lot of potential color that the 9900 CAN print but can't be contained within Adobe RGB. Red, yellows and oranges in particular will be clipped when using ARGB and some of those same colors CAN be printed on the 9900.
While written as an sRGB vs PPRGB discussion, this page: sRGB-VS-PPRGB (http://schewephoto.com/sRGB-VS-PPRGB/), the color gamut of ARGB is not hugely better that sRGB and similar issues of gamut clipping can occur.
But hey, if what you are doing is working for you, by all means, keep doing what you are doing with the exception of thinking that viewing out of gamut colors is giving you anything useful. Soft proof? For sure, but get over the OOG habit.
-
Jeff:
In my last post, I used OOG and soft proofing as the same, and that was a mistake. I never view OOG in CC or LR (not sure how to do it in LR). By OOG I was referring to the view you get in soft proofing to a paper profile and the soft proof shows a different shade of blue or hue etc. I have always assumed that this color change when soft proofing to a paper profile in CC or LR implies that the color that has changed is OOG for that paper profile.
I found that if I stayed in the Adobe RGB (1998) for images that know will be printed on my Epson 9900 or 7800, I run into less issues with color miss matches when soft proofing to the paper profile. For me most common in blue skies, where I have added a bit of clarity and saturation.
I am still on a NEC 3090, using Spectraview, and soft proof in CC and LR via the drop downs, using the custom option and then selecting the paper profile I am looking to proof.
However in my workflow, I never set CC to display OOG. I just rely on the results of the soft proof.
Paul
-
In light of the current discussion, I wanted to reproduce the results from the experiment I ran 3 years ago with gradients that showed no difference between 8 bit and 16 bit images.
I found out that it’s actually not entirely correct. What I can’t see is the difference between a 16 bit image and the same 16 bit image downsampled to 8 bit with dithering. It seems some applications introduce dithering when converting from 16 to 8 bit and some don’t. If the conversion is made without dithering, the resulting prints can show clear banding.
LR and PS dither when downsampling, Qimage doesn’t (double bummer).
I’ll run more tests to see if there is any visible difference between Epson 16 bit mode on Mac vs 8-bit with dither.
I apologize if I misled anyone with my previous statements.
-
LR and PS dither when downsampling
I should add LR and PS dither when converting to 8 bit not just when selecting Image>Mode>8 Bits/Channel but also in the print module if needed unless, I assume, Epson 16-bit mode is active.
-
I should add LR and PS dither when converting to 8 bit not just when selecting Image>Mode>8 Bits/Channel but also in the print module if needed unless, I assume, Epson 16-bit mode is active.
Correct...and when done in LR or Photoshop that conversion from 16-bit > 8-bit is done in 20-bit precision...
-
Correct...and when done in LR or Photoshop that conversion from 16-bit > 8-bit is done in 20-bit precision...
Thanks for the precision. ;D
-
But the capture was of 2D art work? Because I have captures of actual real world stuff and often, depending on subject of course, it falls outside Adobe RGB (1998).
Some examples in this video:
High resolution: http://digitaldog.net/files/ColorGamut.mov
Low Res (YouTube): http://www.youtube.com/watch?v=n0bxSD-Xx-QAnd as illustrated, for that, ProPhoto RGB is necessary or something larger than sRGB or Adobe RGB (1998).
Yes, manmade colours or flowers and sometimes also foliage easily are beyond aRGB.
Then the color encoding/transformation behaviour of the engine together with the quality of profiles come even more into play.
-
Unless your only goal is to reproduce art work, I don't think the argument is relevant here. It doesn't matter that the capture or the scene's colors are entirely within a given colorspace. What matters is whether or not a given colorspace can hold the entire output colorspace. This is because processing of the captured image could expand its gamut.
With my post i was responding more to the point earlier in this thread about transforming to a smaller space for more coding efficiency. Of course for the working space i agree to have a spa e big enough to hold all relevant colorspaces in the image process.
For me i am happy with pRGB.
-
For me i am happy with pRGB.
Just to be clear, your reference to pRGB means ProPhoto RGB (PPRGB). Right? Or is there some other "p" out there? :~)
-
LR and PS dither when downsampling,
Hi,
I'm not sure that is correct, assuming you mean mode change from 16 to 8-bit/channel. The dither option is greyed out for profile conversion in PS when in 16-bit/channel mode. Only when already in 8-bit/channel mode does PS offer an option to dither for profile conversions, in 8-b/ch space.
Are you saying dithering is always added with a mode change? Any references for that? The Color settings preference states that only within 8-bit mode conversions are affected (see attachment).
Cheers,
Bart
-
Just to be clear, your reference to pRGB means ProPhoto RGB (PPRGB). Right? Or is there some other "p" out there? :~)
There is another one out there now and it is pRGB which stands for Printer RGB. Something Qimage has come out with around version 2014.213 or so. Somewhere between Adobe RGB and ProPhoto RGB.
More here: http://ddisoftware.com/tech/qimage-ultimate/prgb-same-as-printer-rgb/?PHPSESSID=sqhvan1opdd06lrm0lila1rj32 (http://ddisoftware.com/tech/qimage-ultimate/prgb-same-as-printer-rgb/?PHPSESSID=sqhvan1opdd06lrm0lila1rj32)
I've been wondering about it too since I spotted it in the folder.
SG
-
There is another one out there now and it is pRGB which stands for Printer RGB. Something Qimage has come out with around version 2014.213 or so. Somewhere between Adobe RGB and ProPhoto RGB.
Hi,
It (pRGB = Printer RGB) was actually around a lot longer (the pRGB.icm profile on my computer is dated 07 Sept 2007), but it gets automatically installed since version Qimage Ultimate 2014.213. Mike Chaney also mentioned it in his Tech article from 2006, called December 2006: Hype or hero take 2: 16-bit printers (http://ddisoftware.com/tech/articles/december-2006-hype-or-hero-take-2-16-bit-printers/msg35/#msg35).
Cheers,
Bart
-
Just to be clear, your reference to pRGB means ProPhoto RGB (PPRGB). Right? Or is there some other "p" out there? :~)
Indeed i mean prophotoRGB with pRGB.
-
I'm not sure that is correct, assuming you mean mode change from 16 to 8-bit/channel. The dither option is greyed out for profile conversion in PS when in 16-bit/channel mode. Only when already in 8-bit/channel mode does PS offer an option to dither for profile conversions, in 8-b/ch space.
Are you saying dithering is always added with a mode change? Any references for that? The Color settings preference states that only within 8-bit mode conversions are affected (see attachment).
Hi Bart,
Yes, I'm saying, by default, the conversion from 16-bit > 8bit in PS is done with dithering. There is a way to turn that feature off (but there is probably no good reason to do so): deselect Edit>Color Settings...>Conversion Options>Use Dither (8-bit/channel images).
The option in the screen shot you attached applies only for conversion of image already in 8-bit.
My source for this are my eyeballs. I made a ramp in 16-bit and watched the effect of converting it to 8-bit.
-
Hi Bart,
Yes, I'm saying, by default, the conversion from 16-bit > 8bit in PS is done with dithering. There is a way to turn that feature off (but there is probably no good reason to do so): deselect Edit>Color Settings...>Conversion Options>Use Dither (8-bit/channel images).
The option in the screen shot you attached applies only for conversion of image already in 8-bit.
Hi,
But that attachment shows the only (CS6 Extended) option related to dithering in the Color settings dialog, and it only applies to conversions from 8-bit to 8-bit ... Do you have another option in your (CC?) version, if so could you post a screen capture so I can see what you are referring to?
Cheers,
Bart
P.S. When I make a gradient in 16-bit ProPhoto RGB and change the mode to 8-bit, no dithering takes place. And while in 16-bit/channel mode, profile conversions also do not add dithering. The only dithering taking place is when the marked option is checked, and only between 8-bit to 8-bit profile conversions.
-
But that attachment shows the only option related to dithering (CS6 Extended) in the Color settings dialog, and it only applies to conversions from 8-bit to 8-bit ... Do you have another option in your version, if so could you post a screen capture so I can see what you are referring to?
I have PS CC and it has the same dither settings as CS6. The 'Use Dither' in 'Color Settings...' also impacts the 16>8-bit conversion. As it is a global setting, not specific the active image, it's never greyed out (unlike the identical option in the 'Convert to Profile...' dialog box).
To demonstrate:
- 1. create a 16-bit partial ramp
- a. File>New... 1000x300, RGB Color>16-bit, Color Profile: Don't Color Manage this Document
- b. Gradient Tool: Dither off. Create a linear gradient from say RGB 120,120,120 to 130,130,130
- 2. The result on a 8-bit display is a grey ramp with lots of banding due the 8-bit display pipeline. But if you look in the info tool in RGB 16-bit, you can confirm that the ramp is indeed a smooth 16-bit gradient.
- 3. Image>Mode>8-bit/Channel. The result on display is a smooth gradient. It is smooth only because it is dithered and the 8-bit display is able to display the 8-bit dither. If you look very carefully, you can actually see the dithering pattern.
- 4. Undo the 8-bit conversion. Deselect Dither in 'Color Settings...'. Convert to 8-bit again and observe the dither free, but full of banding result.
-
I have PS CC and it has the same dither settings as CS6. The 'Use Dither' in 'Color Settings...' also impacts the 16>8-bit conversion.
Hi,
Okay, with such a low gradient delta (1:100) as per your suggested settings, I now do see a bit of dithering of a few lines. It apparently is also controlled by that same dither option (even no restart required), even if it doesn't tell us that it will. Oddly, also the help files seem to do not mention that behavior. Good to know, thanks.
Cheers,
Bart
-
I did some test to see if the dithering pattern introduced by PS when converting from 16-bit to 8-bit could ever be visible in the final print.
The preliminary results are that the dithering pattern is totally unnoticeable (with one caveat). Meaning, printing in Mac Epson 16-bit mode, versus dithered 8-bit, produces the same results as far as smoothness and as far as the number of possible shades are concerned. You can print all the shades possible in 16-bit between any two consecutive 8-bit values using dithered 8-bit. The dithering disappears in the intrinsic dithering used by the printer to lay individual ink droplets.
The one big caveat, is that the dithering should be performed at the final output resolution of the printer. In Epson's case at 360 or 720 dpi. Unfortunately, if one let the PS printer module perform the pixel size upsampling (I assume the module does that, right? Or is it the driver?) and the bit depth downsampling, it seems the module does the bit depth downsampling before the pixel upsampling. That means the dithering could be upsampled and can become visible.
I haven't tested LR. And I haven't test the potential effect of the dithering on sharpness.
And yes I'm aware I'm deep inside pixel peeping territory, but once this is done my goal is to find out what does or doesn't make a difference whatsoever.
-
You can print all the shades possible in 16-bit between any two consecutive 8-bit values using dithered 8-bit.
I should really research that further. I suppose it depends on cell size, etc. But it's good enough for all intents and purposes.
-
I should really research that further. I suppose it depends on cell size, etc. But it's good enough for all intents and purposes.
Hi Luc,
If you, or any of the other readers of this thread, have an image that's very sensitive to posterization/banding due to profile conversion or bit depth reduction, it might also help to let Mike Chaney have a go at it. He is asking for images (http://ddisoftware.com/tech/qimage-ultimate/on-the-subject-of-16-bitchannel-internal-workings/msg15939/#msg15939), in order to see if he can find a further optimization for Qimage (which only converts between colorspaces as a last step, after upsampling and output sharpening). Maybe adding some dithering during that last step, with the most recent LCMS engine, can help? It apparently used to cause occasional issues with an older version of LCMS), but maybe he can make it work better now?
Cheers,
Bart
-
Okay, with such a low gradient delta (1:100) as per your suggested settings, I now do see a bit of dithering of a few lines. It apparently is also controlled by that same dither option (even no restart required), even if it doesn't tell us that it will. Oddly, also the help files seem to do not mention that behavior. Good to know, thanks.
In addition to adding a dither to color space transforms, PS also adds a dither to 8-bit gradients. I can't remember exactly when this was put into Photoshop (I think it came AFTER PS 5, maybe PS 6-pre-suite numbering). I do remember a lot of discussion going on between Bruce Fraser and Mark Hamburg along with Chris Cox about why. As I recall, adding even a tiny bit of noise into the conversion/gradient less likely to posterize with subsequent edits...
Now, it's on by default for both conversions and gradients...and you have to actively turn it off in the main Color Settings prefs...
-
Dither is used for other functions than just conversions even though the controls for it's use is in the Color Settings.
According to Chris Cox:
There is dithering happening in 16 bit/channel gradients -- at an amount appropriate for the least significant bit in 16 bit/channel.
But that’s a dither of 1/32768 instead of the 1/256 you see in 8 bit/channel documents.
So that dithering helps the 16 bit data, but won’t show up on your 8 bit display.
Using an 8 bit dithering amount on a 16 bit gradient would trash the quality of the gradient, making the use of 16 bits pointless.
According to Dave P:
We generally don't dither when printing (except to PostScript printers), since Photoshop never resamples when printing, and if there's a down-conversion from 16-bit to 8-bit (when a printer doesn't support 16 bit printing, or the checkbox is turned off), you should get exactly the same effect as if you'd selected image>mode>8 bit. Any dithering would be performed by the printer driver (which in many cases just calls back to the OS to do the dithering).
According to Roy Harrington on the ColorSync list:
The Dither option in Color Settings applies to all conversions that result in an 8bit file. This would include 8-bit to 8-bit color profile conversions and all conversions of 16bit to 8bit -- i.e. explicit Mode conversions and Printing to an 8 bit driver. The effect of the dithering is to preserve more of the 16bit data in the 8 bit file. While this may seem like an impossible task it in fact does this very well because adjacent pixels are averaged. For example consider all the 16-bit values between 127 and 128, without dither you'll get all the same 8bit values. But with dither you can represent a patch of 127.3 with 30% 127 and 70% 128, and so forth.
So if you spend the effort to use a 16bit workflow in general it's well worth using the Dither on the way to the printer. There is no negative side effect of multiple dithers -- it's a negative if you don't use it. I'd consider it a mandatory option for just about all PS work.
Roy
And I agree, the dither setting should always be one for most uses. I turn it off if I'm doing some kinds of analysis where ultimately I'll put a color list in ColorThink to get a dE report and the resulting differences are expected to be tiny (for example, you're using the same profiles but testing differing CMM's).
-
According to Dave P:
... if there's a down-conversion from 16-bit to 8-bit (when a printer doesn't support 16 bit printing, or the checkbox is turned off), you should get exactly the same effect as if you'd selected image>mode>8 bit. Any dithering would be performed by the printer driver.
Except the effect you get when selecting image>mode>8 bit is dithering.
If I understand correctly, he's also saying PS Print module does not resample the image pixel size to fit the native dpi of the printer driver. Is that correct? The resize is left to the driver?
-
If I understand correctly, he's also saying PS Print module does not resample the image pixel size to fit the native dpi of the printer driver. Is that correct? The resize is left to the driver?
Correct...you CAN alter the final output resolution, but you must actively do that–it doesn't happen in PS nor LR by default.
-
Correct...you CAN alter the final output resolution, but you must actively do that–it doesn't happen in PS nor LR by default.
How do you do that in PS print module?
EDIT: added 'print module'.
-
How do you do that in PS print module?
You change the Scaled Print Size in the Print dialog...if you alter the Scale, you can see the image size & Print Resolution. It's not "optimal" but it's usable...LR is easier to deal with (no surprise). Alliteratively, you can use Image Size before going into the Print dlog...the downside is you'll need to run some sort of output sharpening after the image resize :~(
In LR, you can do everything at once (another benefit of LR).
-
You change the Scaled Print Size in the Print dialog...if you alter the Scale, you can see the image size & Print Resolution. It's not "optimal" but it's usable...
Wait. I must be missing something. If I increase the scale, the Print Resolution goes down accordingly. It doesn't seem to resample.
-
Wait. I must be missing something. If I increase the scale, the Print Resolution goes down accordingly. It doesn't seem to resample.
You are missing the fact you were talking about the output resolution (not resampling) and I showed how you can alter the final output resolution (and yes, if you change the output resolution, the image size changes–doooh).
That's also why I mentioned Image Resize–if you needed to do more (resizing & resampling).
Edit: Sorry, wasn't trying to be snarky, just showing that the Print dlog in PS can do some things in the dlog...
-
Hi Luc,
If you, or any of the other readers of this thread, have an image that's very sensitive to posterization/banding due to profile conversion or bit depth reduction, it might also help to let Mike Chaney have a go at it. He is asking for images (http://ddisoftware.com/tech/qimage-ultimate/on-the-subject-of-16-bitchannel-internal-workings/msg15939/#msg15939), in order to see if he can find a further optimization for Qimage (which only converts between colorspaces as a last step, after upsampling and output sharpening). Maybe adding some dithering during that last step, with the most recent LCMS engine, can help? It apparently used to cause occasional issues with an older version of LCMS), but maybe he can make it work better now?
This photo (http://lucbusquin.com/sites/default/files/torture_test.tif) exhibits lots of posterization/banding when printed in Qimage but none in PS and LR.
I don't know that adding dithering after the 8-bit conversion makes sense. Actually it would just be like adding noise since there would be nothing to dither at that point.
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.
-
This photo (http://lucbusquin.com/sites/default/files/torture_test.tif) exhibits lots of posterization/banding when printed in Qimage but none in PS and LR.
Hi Luc,
I saw that image on your website, and thought it would be a good candidate, but I didn't know if the specific output profile you converted to caused any issues. Since it apparently does, I think it would be very useful to send both (image+output profile) to Mike Chaney, so he can find a solution. We can only gain from such an exchange, you get better output results when you want to use the benefits of Qimage (nesting/interpolation/output sharpening/re-using prior print jobs for identical copies, etc.), and Mike is eager and motivated to improve output quality, which will push competition to improve their quality as well.
I don't know that adding dithering after the 8-bit conversion makes sense. Actually it would just be like adding noise since there would be nothing to dither at that point.
No, that's not what he is going to look at, he is going to look at the dither option of profile conversions after the image is already resized and sharpened, as the final step before sending the bytes to the printer driver. The dither would break up posterization at the 600/720 PPI level, beyond normal visual acuity. It would be similar in effect to the 16-->8 bit mode change dither, although it is not clear how the microweaving / color dithering / uni- or multidirectional printing / etc. of the printer driver interacts with such dithering (also depends on the dither algorithm, which may have changed since LCMS version 1).
Ideally you want to upsample the pixel size first and downsample the bit-depth last.
I agree, if it produces better results. Maybe the paper structure and print process (dithered colors with blending/overlapping of multiple ink droplet sizes that diffuse in the medium, in the case of inkjet output) has a larger influence.
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.
I agree that a optional dither would probably be best, but it should be done as a final step, after resizing and output sharpening and colorspace conversion, otherwise the effect will vary all over the image. Until then, just adding some noise at the 600/720 PPI level is probably also effective enough for pathological cases, but it would be nice to have a slightly more elegant solution. Adding noise can help with other (lack of resolution) issues, so it's best to only use it for that purpose.
Cheers,
Bart
-
Hi Luc,
I saw that image on your website, and thought it would be a good candidate, but I didn't know if the specific output profile you converted to caused any issues. Since it apparently does, I think it would be very useful to send both (image+output profile) to Mike Chaney, so he can find a solution. We can only gain from such an exchange, you get better output results when you want to use the benefits of Qimage (nesting/interpolation/output sharpening/re-using prior print jobs for identical copies, etc.), and Mike is eager and motivated to improve output quality, which will push competition to improve their quality as well.
Yes it seemed like a good candidate for the posterization hall of fame, but it actually prints just fine out of the box. To make it really challenging I applied strong noise reduction, which really help show the potential problems associated with converting to 8-bit by rounding instead of dithering. Also I pushed the saturation a bit; the image's gamut is now outside AdobeRGB but inside the printer gamut. This might help show further posterization during the color profile conversion (I'll experiment later to see if it's actually happening).
To be clear the test image does not reflect my aesthetic choices; I've pushed it to the limits for demonstration purposes.
I also downsampled its pixel size. So if it's printed to letter size or bigger it might show the problem associated with dithering before enlarging (PS?).
Right now, out of PS, LR, and QI, only LR does all the steps in the right sequence, i.e. 8-bit-with-dither last.
Also, I hear you, I'm a big fan of Mike and QI. Even if this minor problem is never fixed (which I doubt, knowing Mike), given that the chance of actually visibly occurring in a real world print is very low, and now that I know what to watch for, QI remains my favorite tool for the job. For the pathological cases (as you say ;) ), it's always possible to alter the normal workflow by performing the steps 'manually' in PS.
No, that's not what he is going to look at, he is going to look at the dither option of profile conversions after the image is already resized and sharpened, as the final step before sending the bytes to the printer driver. The dither would break up posterization at the 600/720 PPI level, beyond normal visual acuity. It would be similar in effect to the 16-->8 bit mode change dither, although it is not clear how the microweaving / color dithering / uni- or multidirectional printing / etc. of the printer driver interacts with such dithering (also depends on the dither algorithm, which may have changed since LCMS version 1).
I agree, if it produces better results. Maybe the paper structure and print process (dithered colors with blending/overlapping of multiple ink droplet sizes that diffuse in the medium, in the case of inkjet output) has a larger influence.
Ah ok, I understand now. It would be interesting to see if dithering introduced in the last step from 8-bit-source-profile > 8-bit-printer-profile would help hide the posterization introduced in the first step. I'll test this approach to see if it could help.
Regarding the question of whether a 8-bit dithering pattern will be visible if performed at output resolution, there is no worries there; it won't. The max amplitude of the dithering is half an 8-bit step in this case; it's totally invisible against the background noise intrinsic to the printer unless it's enlarged by a large factor.
We should probably continue the QI specific discussion over at ddisoft forum (http://ddisoftware.com/tech/qimage-ultimate/on-the-subject-of-16-bitchannel-internal-workings/new/?topicseen#new)?
-
ProPhoto is currently the only space available in ACR that doesn't clip the gamut of the printer.
Turns out ACR let you choose whatever profile you desire; at least in CC. Not sure if it's a relatively new feature or if I've I just always assumed wrong.
-
Not sure if it's a relatively new feature or if I've I just always assumed wrong.
Yes, it's new to ACR 8.x in Photoshop CC.
-
As a complete layman when it comes to this type of discussion, would I be wrong in suggesting that this extract from Andrew's link to "Real World Adobe Photoshop" is the simplest argument for using ProPhoto RGB?
This question seems to have been "lost" in the ongoing debate - Jeff, Andrew, anyone...?
To me, the key is: "It needs these extreme primaries to accommodate the dark, saturated colors we can readily achieve in print that get clipped by smaller spaces."
Thanks
William
-
Simple matrix profiles of RGB working spaces when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. But the opposite is the case with print (output) color spaces. Printers produce color by adding ink or some kind of colorant while working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB. All RGB working space's shapes are simple as seen as you plot them. Then there is the issue of very dark colors of intense saturation which do occur in nature and we can capture with many devices. Many of these colors fall outside Adobe RGB (1998) and when you encode into such a space, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance.
-
Simple matrix profiles of RGB working spaces when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. But the opposite is the case with print (output) color spaces. Printers produce color by adding ink or some kind of colorant while working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB.
This is why PrinterRGB is a bit of a misnomer as it clips some dark cyans that the printer is able to reproduce. It's a significant improvement over AdobeRGB though, and probably a very reasonable compromise if your workflow narrows to 8-bit prematurely.
-
This is why PrinterRGB is a bit of a misnomer as it clips some dark cyans that the printer is able to reproduce.
I have no idea what PrinterRGB is, never heard of it. But it sounds like you're saying it's a working space based profile and it's gamut is bigger than Adobe RGB (1998).
-
I have no idea what PrinterRGB is, never heard of it. But it sounds like you're saying it's a working space based profile and it's gamut is bigger than Adobe RGB (1998).
It's that pRGB or PrinterRGB that popped up earlier in this conversation. It seems to be a new comer. It's included in the latest versions of Qimage. Can't seem to find much info about it. It's bigger than Adobe, smaller than ProPhoto and therefore clips the printer gamut just a bit.
-
Mike added dithering as the default in the latest version of Qimage Ultimate.
Ernst, op de lei getypt.
-
To recap, here is my understanding of how LR, PS, and QI process 16-bit images for printing to an 8-bit printer driver, with color management done in-app.
Lightroom print module:
1. Pixel size resampling.
2. Output Sharpening.
3. Color Profile conversion rounded to 20-bit -> dithered to 8-bit (semi-random dithering) at output resolution.
Photoshop print module:
1. Color Profile conversion rounded to 20-bit -> dithered to 8-bit (semi-random dithering).
2. No sharpening or resampling.
3. Printer driver performs pixel size resampling.
Qimage Ultimate as of v2014.219:
1. 16-bit -> rounded to 9-bit -> dithered to 8 bit with repeating checkerboard pattern (non-semi-random) dithering.
2. Pixel size resampling (choices of interpolation methods).
3. Output Sharpening (halo free DFS).
4. Color Profile conversion rounded to 9-bit -> dithered to 8 bit with repeating checkerboard pattern (non-semi-random) dithering at output resolution.
-
To recap, here is my understanding of how LR, PS, and QI process 16-bit images for printing to an 8-bit printer driver, with color management done in-app.
[...]
Qimage Ultimate as of v2014.219:
1. 16-bit -> rounded to 9-bit -> dithered to 8 bit with repeating checkerboard pattern (non-semi-random) dithering.
2. Pixel size resampling (choices of interpolation methods).
3. Output Sharpening (halo free DFS).
4. Color Profile conversion rounded to 9-bit -> dithered to 8 bit with repeating checkerboard pattern (non-semi-random) dithering at output resolution.
Hi Luc,
As far as I can see, it's:
Qimage Ultimate as of v2014.217:
1. 16-bit -> rounded to 8-bit.
2. Pixel size resampling (choices of interpolation methods).
3. Output Sharpening (halo free DFS).
4. Color Profile conversion rounded to 9-bit -> dithered to 8 bit with repeating checkerboard pattern (non-semi-random) dithering at output resolution.
Re 1. I cannot see any dithering in the imported image, e.g. you ramp, not even with a radius 1 and 2000% DFS sharpening in the image editor. It just accentuates the 1-bit transitions between the gradient steps. It would also be a bad thing because it could be enlarged by resampling and become visible with sharpening. Dithering is now the last thing that's applied during/after final colorspace conversion.
Re 4. I'm not 100% sure about the 'conversion rounded to 9-bit -> dithered' part, it may also be an option within the LCMS engine (I have not yet found a description of the built-in dither option on the LCMS website). Mike's remarks on his Techcorner are not explicit enough about the exact implementation, but he suggests 8-bit dithered to '512 virtual levels'.
The checkerbord dithering pattern may not be a bad choice since it is applied at the native printer resolution (600/720 PPI), and it avoids accidental clumping together with the printer driver's dithering patterns which are assumed to look rather stochastic.
Cheers,
Bart
-
Hi Bart,
check qu v219. Things change quickly. Mike added dithering in step 1. Also 9-bit give 512 levels.
-
Hi Bart,
check qu v219. Things change quickly. Mike added dithering in step 1. Also 9-bit give 512 levels.
Hi Luc,
Yes I have that version. It's not exactly clear what those new options do, so I left a question about that on Mike's Techcorner. I was wondering, since I cannot see any dithering on the imported 8-b/ch image. Maybe I have to look deeper somehow.
Cheers,
Bart
P.S. I had a closer look, and indeed the input conversion from 16-b/ch to 8-b/ch can now optionally be dithered. It has the checkered pattern (becomes faintly visible with excessive sharpening). I'll wait for Mike's answers on his techtalk forum.
-
Hi
Has anybody tried a conversion from 16-bit prophoto to 16-bit pRGB (with RC not perceptual) before sending to Qimage?
Or a more general question : Is somebody using pRGB 16-bit as workspace versus prophoto 16-bit?
-
Hi
Has anybody tried a conversion from 16-bit prophoto to 16-bit pRGB (with RC not perceptual) before sending to Qimage?
Or a more general question : Is somebody using pRGB 16-bit as workspace versus prophoto 16-bit?
Color space to color space conversions are, currently, always relative no matter what the settings.
I stay in prophoto while in LR and PS, plus plugins. Before going to Qimage, I convert (export), in LR, to printerRGB 8bit TIFF.
-
Hi
Has anybody tried a conversion from 16-bit prophoto to 16-bit pRGB (with RC not perceptual) before sending to Qimage?
Hi Alain,
A two step profile conversion towards a smaller gamut (and the actually required current output profiles are much smaller) will most likely invoke two rounds of quantizing to smaller integer encoded colorspaces (PPRGB->pRGB->media/display RGB). It's probably safer to just do a single conversion at the end of the process. Whether it makes a visible difference in practice, depends on the actual colors encoded in the image data (with an even smaller required gamut than the output gamut) and print method (e.g. C-print is different from inkjet).
Or a more general question : Is somebody using pRGB 16-bit as workspace versus prophoto 16-bit?
I have used the Beta RGB for critical images (which is pretty close to pRGB in gamut but mainly with a different gamma encoding), i.e. images with very smooth gradients such as noise reduced sky or smooth seamless backgrounds. But one has to use it as a working space for all color/brightness/etc. corrections in the image editor! For such critical images, which I need to outsource (e.g. because of size), I first check what the actually required gamut is. Depending on the outsourcing partner, I'm occasionally told that I'm the first to ask for their output profile ... One can use different tools for such an output profile check, amongst others the excellent free Argyll CMS tools (in particular iccgamut.exe, tiffgamut.exe, and viewgam.exe).
Cheers,
Bart
-
Color space to color space conversions are, currently, always relative no matter what the settings.
I stay in prophoto while in LR and PS, plus plugins. Before going to Qimage, I convert (export), in LR, to printerRGB 8bit TIFF.
Hi John,
Indeed, given that one cannot really select the working space profile in LR (it's Melissa RGB, the linear gamut version of ProPhoto RGB), that's generally safer than a two-step quantization.
For Qimage, if you only use a single output medium, it's even preferable to directly convert from LR to that output profile. Otherwise, an intermediate conversion from LR's linear gamma Melissa space to a narrower color-space that still covers all possible output media, such as pRGB or Beta RGB, makes sense.
Cheers,
Bart
-
(it's Melissa RGB, the linear gamut version of ProPhoto RGB)
Just to be clear, the actual working space of Lightroom is NOT "Melissa RGB". The only place where LR uses is to calculate the histogram and color readouts in the Develop module. Melissa RGB has ProPhoto RGB colors but with an sRGB tone curve (altered from the normal 2.2 gamma).
That actual internal working space is PhotoPhoto RGB colors and a linear gamma. To the best of my knowledge, Thomas has never actually given that color space a name.
I was around and involved in the decision to alter the histogram and color readouts to use the modified sRGB color space for display purposes...and Melissa Gaul asked why there weren't any color spaces with woman's names...so, by consensus, the LR engineering team decided to call that special color space "Melissa RGB"...
Wich unfortunately leads to some miscommunication because people seem to glom onto the "Melissa RGB" and think that's the internal working space, but it's not. The difference is in the gamma of the color space.
BTW, Melissa loves the fact she got a color space named after her (she deserves it) even though she's no longer working on LR.
-
Just to be clear, the actual working space of Lightroom is NOT "Melissa RGB". The only place where LR uses is to calculate the histogram and color readouts in the Develop module. Melissa RGB has ProPhoto RGB colors but with an sRGB tone curve (altered from the normal 2.2 gamma).
That actual internal working space is PhotoPhoto RGB colors and a linear gamma. To the best of my knowledge, Thomas has never actually given that color space a name.
Hi Jeff,
Thanks for the explanation.
Cheers,
Bart
-
For Qimage, if you only use a single output medium, it's even preferable to directly convert from LR to that output profile. Otherwise, an intermediate conversion from LR's linear gamma Melissa space to a narrower color-space that still covers all possible output media, such as pRGB or Beta RGB, makes sense.
Cheers,
Bart
Hello Bart,
I would expect at least two papers in use, gloss and matte, even for amateurs. True with no other goal than printing this (Tiff) file through Qimage Ultimate and then abandon it, it is a solution. I did not trust QU with QTR custom B&W profiles and used this method. The Qimage Ultimate extrapolation, sharpening etc happens after profile conversion then, which is not ideal or the file found better algorithms to requested printer resolution in another application before the profile conversion. For people that use Qimage Ultimate for image editing, even for minor adjustments (not my taste in both cases) it is not recommended either.
The second method I like more. If at the end of the RAW development one could export a 16 bit Tiff in pRGB to Qimage Ultimate, little would be lost and the file can be kept there for different jobs. But I wonder whether that still is a good idea if one imports it in Photoshop for more image editing on the 16 bit Tiff. Is that gamut not just covering the best printers' gamuts? The PS edits may have an influence on the boundaries of that gamut which might not cover the best output gamuts as nice anymore? With extended RAW developers like RawTherapee the route to a Tiff image editor is less needed, a RawTherapee pRGB conversion in the Tiff export can be done at best conditions if I interpret its features correctly.
--
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
April 2014, 600+ inkjet media white spectral plots.
-
Hello Bart,
I would expect at least two papers in use, gloss and matte, even for amateurs. True with no other goal than printing this (Tiff) file through Qimage Ultimate and then abandon it, it is a solution. I did not trust QU with QTR custom B&W profiles and used this method. The Qimage Ultimate extrapolation, sharpening etc happens after profile conversion then, which is not ideal or the file found better algorithms to requested printer resolution in another application before the profile conversion. For people that use Qimage Ultimate for image editing, even for minor adjustments (not my taste in both cases) it is not recommended either.
The second method I like more. If at the end of the RAW development one could export a 16 bit Tiff in pRGB to Qimage Ultimate, little would be lost and the file can be kept there for different jobs. But I wonder whether that still is a good idea if one imports it in Photoshop for more image editing on the 16 bit Tiff. Is that gamut not just covering the best printers' gamuts? The PS edits may have an influence on the boundaries of that gamut which might not cover the best output gamuts as nice anymore? With extended RAW developers like RawTherapee the route to a Tiff image editor is less needed, a RawTherapee pRGB conversion in the Tiff export can be done at best conditions if I interpret its features correctly.
--
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
April 2014, 600+ inkjet media white spectral plots.
Ernst....
If I need further processing...in LR, PS, other editor....I go back to the 16 bit, PrpPhoto TIFF, which is still in LR, do the processing on it, which will create a new tiff, then export that to 8bit pRGB TIFF.
JOHN
-
The second method I like more. If at the end of the RAW development one could export a 16 bit Tiff in pRGB to Qimage Ultimate, little would be lost and the file can be kept there for different jobs. But I wonder whether that still is a good idea if one imports it in Photoshop for more image editing on the 16 bit Tiff. Is that gamut not just covering the best printers' gamuts?
Hoi Ernst,
Yes, it's supposed to cover all printer media gamuts, but it's not nearly as small as an Adobe RGB gamut, it is instead still reasonably big. When I plot Adobe RGB, pRGB, and ProPhotoRGB colorspaces, the Argyll CMS 'Viewgam.exe' reports a gamut of:
1209647.5 cubic units for AdobeRGB 1998 (100% inside the pRGB colorspace),
1779999.8 cubic units for pRGB (68% intersected by AdobeRGB, so 32% larger, and 100% inside the ProphotoRGB colorspace),
2893604.8 cubic units for ProPhotoRGB (61.6% intersected by pRGB, so another 38.4% larger but partly imaginary 'colors').
The PS edits may have an influence on the boundaries of that gamut which might not cover the best output gamuts as nice anymore?
Yes, in theory one could push colors outside the pRGB gamut by editing, but it would not make sense to do so, because the colors cannot be printed. With a bit of luck, a perceptual rendering intent will pull them back into gamut, but also alter many other colors.
Luckily, it is rarely an issue because actual image colors in a file usually only occupy a small percentage of the full gamut of pRGB. Only those colors exactly on the axes of the primaries of the colorspace run a risk of being edited into an OOG color, others will just map to previously unused coordinates with lots of room to spare. It is really an eye-opener to see how little colorspace an image occupies.
To view it from another angle, Luc's 'torture_test.tiff' image, in ProPhotoRGB and with pushed saturation, intersects for 92.19% with the pRGB colorspace. Only a few very dark blue colors risk being clipped to marginally brighter very dark blue colors. In comparison, that image intersects for 92.22% with the ProPhotoRGB colorspace, only 0.03% additional colors are encoded, the rest of the coordinate space is unused and reserved for imaginary 'colors' we can't even see, and certainly not print/display, and with much coarser quantization steps to cover the (98.3% for nonexisting image colors) distance. The image only occupies 2.76% of the pRGB gamut, and 1.7% of the ProPhoto RGB colorspace.
pRGB is plenty large enough, but not insanely so.
With extended RAW developers like RawTherapee the route to a Tiff image editor is less needed, a RawTherapee pRGB conversion in the Tiff export can be done at best conditions if I interpret its features correctly.
Correct, but the risk of overcooking the colors remains very small, even with an additional editor step. pRGB offers hardly any downsides (why create an unprintable color anyway), but many upsides (more accurate, denser quantization, less risk of posterization in an 8-bit pipeline). The added dithering in Qimage reduces the posterization risks even further.
Cheers,
Bart
-
Ernst....
If I need further processing...in LR, PS, other editor....I go back to the 16 bit, PrpPhoto TIFF, which is still in LR, do the processing on it, which will create a new tiff, then export that to 8bit pRGB TIFF.
Hi John,
Yes, you are using a correct print output workflow. By outputting an 8-b/ch file, Qimage then optionally only dithers at the very last colorspace conversion step after output sharpening, adding a virtual 9th bit to the pipeline. With a 16-b/ch input image it optionally dithers both at the 16 to 8-b/ch conversion and at the final colorspace conversion. Since Qimage usually prints at 600/720 PPI resolution, the final dither is beyond human visual acuity, it can only help.
Cheers,
Bart
-
Hi John,
Yes, you are using a correct print output workflow. By outputting an 8-b/ch file, Qimage then optionally only dithers at the very last colorspace conversion step after output sharpening, adding a virtual 9th bit to the pipeline. With a 16-b/ch input image it optionally dithers both at the 16 to 8-b/ch conversion and at the final colorspace conversion. Since Qimage usually prints at 600/720 PPI resolution, the final dither is beyond human visual acuity, it can only help.
To be clear, note that doing the 16-bit>8-bit conversion in LR also introduces dithering which will be enlarged and sharpened in QU (although the dithering algorithm QU and LR are very different.)
-
Hi folks,
I'm not sure if the attached VRML file is allowed as file type, but for those who have a VRML viewer plugin (e.g. one from the Cortona3D viewer page) installed in their browser one can display, zoom, and rotate the colorspace hulls in 3D (solid for the smaller gamut and wireframe for the larger gamut colorspace).
It shows that the pRGB colorspace adds a more saturated gamut and specifically darker colors to AdobeRGB, yet covers a reasonably large part of the excessively-large ProPhoto RGB.
Cheers,
Bart
-
Hi folks,
I'm not sure if the attached VRML file is allowed as file type, but for those who have a VRML viewer plugin (e.g. one from the Cortona3D viewer page) installed in their browser one can display, zoom, and rotate the colorspace hulls in 3D (solid for the smaller gamut and wireframe for the larger gamut colorspace).
It shows that the pRGB colorspace adds a more saturated gamut and specifically darker colors to AdobeRGB, yet covers a reasonably large part of the excessively-large ProPhoto RGB.
Cheers,
Bart
Thanks Bart
Could you compare pRGB to a "good" printer/paper gamut?
or pRGB compared to some camera's "gamut"?
The more I look at pRGB the better it gets.
Is there a way to find (rather easy) how much % of actual 16-bit prophoto images are out of gamut for pRGB?
Alain
-
Could you compare pRGB to a "good" printer/paper gamut?
Hi Alain,
I don't know if this Fine Art paper is a very challenging medium, so let me know if something else is preferred.
Attached:
Hahnemühle Fine Art Baryta glossy (solid hull), inside pRGB (wireframe hull), slight risk of clipping of hyper-saturated orange and mint cyan/green (which the RGB filtered camera probably cannot capture anyway), Perceptual rendering intent can cope with that by modest compression of all colors, while with Relative Colorimetric intent probably only those oranges are at risk. Pro Photo RGB will of course be able to encode almost all of the media gamut, at the cost of posterization risk in (amongst others) sky blues. Both Epson and Canon printer profiles are used. pRGB seems to fit the medium gamut reasonably well.
Do note that it may be required to compress the potential Camera gamut (for very saturated colors) quite a bit (if the image content has such colors) to fit inside the output medium space, but it's good to know where to look for issues, also based on actual image content. Good soft-proofing should identify such issues ahead of time.
Cheers,
Bart
-
Could you compare pRGB to a "good" printer/paper gamut?
See earlier post.
or pRGB compared to some camera's "gamut"?
This is where things get complicated. In fact, one should look at the intersection between Camera and Output profile gamut and actual image colors in the scene. The Camera RGBs can allow to capture more saturated colors than the output medium's gamut can render, while the output medium's secondary colors (notably orange and cyan green, and some yellows) can have excess room which the camera cannot capture, but may be edited into the image by increasing saturation.
So the question becomes, which colors are in the image itself, can the camera capture those, and how much of that can be printed anyway. Afterall, a red tomato on a red plate won't challenge the cyan greens that the camera cannot capture anyway, but the output medium could print.
Is there a way to find (rather easy) how much % of actual 16-bit prophoto images are out of gamut for pRGB?
Exactly, that's what is needed, good softproofing. Other than specialist software like Colorthink (http://www.chromix.com/colorthink/), I think GamutVision (http://www.gamutvision.com/docs/tour_gamutvision.html#images) would fit the requirements quite well. Obviously, one would need to purchase it so it would need to satisfy a recurring requirement to be worth the investment.
The Argyll CMS has free tools (which I used to create the VRML files), but that requires one to do some script/batchfile editing to be of use.
Lightroom of course only offers linear gamma ProPhoto RGB to edit in, but it does allow to softproof that with pRGB or an output medium's colorspace.
FWIW, I've attached 3D plots of 2 (solid hull) camera profiles (from CaptureOne) 'inside' pRGB (wireframe hull).
Cheers,
Bart
-
Thanks to all who are contributing. This is proving a very useful discussion.
I want to be able to "future-proof" my files, and also avoid clipping colours until the output stage, and have always used Prophoto for that reason. I see no reason not to convert my workflow to another colour space, such as BetaRGB if there will be a tangible benefit.
For what it's worth, I've only had a problem with a smooth gradient in one image (blue/greys), and can't say whether it's a problem with the printer hitting its limit, or the colour space.
David
-
Hi Alain,
A two step profile conversion towards a smaller gamut (and the actually required current output profiles are much smaller) will most likely invoke two rounds of quantizing to smaller integer encoded colorspaces (PPRGB->pRGB->media/display RGB). It's probably safer to just do a single conversion at the end of the process. Whether it makes a visible difference in practice, depends on the actual colors encoded in the image data (with an even smaller required gamut than the output gamut) and print method (e.g. C-print is different from inkjet).
...
Cheers,
Bart
Hi Bart
A 16-bit PPRGB -> 16-bit pRGB -> 8-bit pRGB --> media/display RGB would probably give less errors that a 16-bit PPRGB -> 8-bit PPRGB --> media/display RGB like in Qimage.
EDIT : And because pRGB is about 40% smaller would give more possible values where the image is in gamut.
Alain
-
Hi Bart
A 16-bit PPRGB -> 16-bit pRGB -> 8-bit pRGB --> media/display RGB would probably give less errors that a 16-bit PPRGB -> 8-bit PPRGB --> media/display RGB like in Qimage.
Hi Alain,
Maybe, maybe not. That's why it's safer to eliminate the PPRGB to begin with. When starting with a smaller gamut colorspace (e.g. pRGB), the subsequent gamut resampling will produce fewer artifacts.
Again, it's rarely the gamut of the actual image data that requires PPRGB. The image data is usually a small subset even of the theoretical maximum that pRGB, or even Adobe RGB (ARGB), could encode. Only with specific colors, saturated and on the axes of the inks colorants, can a wider gamut make some difference.
EDIT : And because pRGB is about 40% smaller would give more possible values where the image is in gamut.
Indeed, when used as the working space. When used as a space to convert to, as an intermediate, some of the original data may alias a little when several different colors get encoded to the same coordinates (even while remaining in 16-bit/channel).
As a theoretical maximum gamut experiment, see what happens to the RGB16Million.png (http://www.brucelindbloom.com/index.html?RGB16Million.html) file, when we run it through several conversions in Photoshop after the initial assignment and mode change to 16-bit:
8-b/ch-->PS16-b/ch-->assigned PPRGB-->pRGB-->ARGB-->8-b/ch = 5762264 colors (=34%) out of 16777216 original colors.
8-b/ch-->PS16-b/ch-->assigned pRGB-->ARGB-->8-b/ch = 7344153 colors (=44%) out of 16777216 original colors.
The lost color differentiation may not be important, if those colors were not in the image data-set to begin with, but it does suggest a higher risk of losing meaningful differences. How much loss, and if it's in smooth gradients, depends on the actual image.
In general, one should reduce the number of recoding operations between colorspaces, and start with a colorspace that is large enough to hold the actual image data and is close to the theoretical maximum gamut of the output profile.
Cheers,
Bart
-
Hi Alain,
Maybe, maybe not. That's why it's safer to eliminate the PPRGB to begin with. When starting with a smaller gamut colorspace (e.g. pRGB), the subsequent gamut resampling will produce fewer artifacts.
Again, it's rarely the gamut of the actual image data that requires PPRGB. The image data is usually a small subset even of the theoretical maximum that pRGB, or even Adobe RGB (ARGB), could encode. Only with specific colors, saturated and on the axes of the inks colorants, can a wider gamut make some difference.
Indeed, when used as the working space. When used as a space to convert to, as an intermediate, some of the original data may alias a little when several different colors get encoded to the same coordinates (even while remaining in 16-bit/channel).
As a theoretical maximum gamut experiment, see what happens to the RGB16Million.png (http://www.brucelindbloom.com/index.html?RGB16Million.html) file, when we run it through several conversions in Photoshop after the initial assignment and mode change to 16-bit:
8-b/ch-->PS16-b/ch-->assigned PPRGB-->pRGB-->ARGB-->8-b/ch = 5762264 colors (=34%) out of 16777216 original colors.
8-b/ch-->PS16-b/ch-->assigned pRGB-->ARGB-->8-b/ch = 7344153 colors (=44%) out of 16777216 original colors.
The lost color differentiation may not be important, if those colors were not in the image data-set to begin with, but it does suggest a higher risk of losing meaningful differences. How much loss, and if it's in smooth gradients, depends on the actual image.
In general, one should reduce the number of recoding operations between colorspaces, and start with a colorspace that is large enough to hold the actual image data and is close to the theoretical maximum gamut of the output profile.
Cheers,
Bart
Hi Bart
You're example has a "problem" by assigning to PPRGB or pRGB you make those vastly different images. It's normal that the high values that are assigned PPRGB are outside ARGB.
A better comparison would be :
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB-->pRGB-->ARGB-->8-b/ch
8-b/ch-->PS16-b/ch-->assigned camera space --> pRGB-->ARGB-->8-b/ch
Alain
-
A better comparison would be :
Hi Alain,
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB-->pRGB-->ARGB-->8-b/ch, gives 4643194 colors.
8-b/ch-->PS16-b/ch-->assigned camera space --> pRGB-->ARGB-->8-b/ch, gives 4643292 colors
A much smaller difference, but again not worse for Printer RGB as working space. I used the EOS 1Ds3 profile, other cameras may show somewhat different results.
Cheers,
Bart
-
Hi Alain,
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB-->pRGB-->ARGB-->8-b/ch, gives 4643194 colors.
8-b/ch-->PS16-b/ch-->assigned camera space --> pRGB-->ARGB-->8-b/ch, gives 4643292 colors
A much smaller difference, but again not worse for Printer RGB as working space. I used the EOS 1Ds3 profile, other cameras may show somewhat different results.
Cheers,
Bart
Hi Bart,
Thanks. Far better than I expected. Two that are maybe important for Qimage Ultimate users :
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB-->8-b/ch-->ARGB
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB --> pRGB-->8-b/ch-->ARGB
Alain
-
Two that are maybe important for Qimage Ultimate users :
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB-->8-b/ch-->ARGB, results in 3964053 colors.
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB --> pRGB-->8-b/ch-->ARGB, results in 4160101 colors.
and another
8-b/ch-->PS16-b/ch-->assigned camera space --> pRGB-->8-b/ch-->ARGB, results in 4159482 colors.
Particularly the Conversion of PPRGB to 8-bit seems to take a hit on available colors, as does conversion in 8-b/ch space. Dithering will be required to improve that situation, which is what Qimage now does.
The actual pipeline through Lightroom and Qimage adds dithering at various stages so this is a somewhat simplified situation, besides that it's not really an assignment of the camera space because the camera's Raw data is immediately demosaiced/converted into a working space with some tonemapping and saturation adjustment to something with a potentially larger gamut.
Cheers,
Bart
-
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB-->8-b/ch-->ARGB, results in 3964053 colors.
8-b/ch-->PS16-b/ch-->assigned camera space --> PPRGB --> pRGB-->8-b/ch-->ARGB, results in 4160101 colors.
and another
8-b/ch-->PS16-b/ch-->assigned camera space --> pRGB-->8-b/ch-->ARGB, results in 4159482 colors.
Particularly the Conversion of PPRGB to 8-bit seems to take a hit on available colors, as does conversion in 8-b/ch space. Dithering will be required to improve that situation, which is what Qimage now does.
The actual pipeline through Lightroom and Qimage adds dithering at various stages so this is a somewhat simplified situation, besides that it's not really an assignment of the camera space because the camera's Raw data is immediately demosaiced/converted into a working space with some tonemapping and saturation adjustment to something with a potentially larger gamut.
Cheers,
Bart
Bart
Thanks a lot.
It's simplified, but it's unlikely that an image contains a lot of colors close to the gamut boundary. It's more a problem with gradients which are inside the gamut of the printer space and are manipulated in 16-b/ch.
The important part of the tests is that going from PPRGB --> pRGB in 16-b/ch is a possible enhancement if it's needed.
Alain
-
Bart
Thanks a lot.
It's simplified, but it's unlikely that an image contains a lot of colors close to the gamut boundary.
Correct, and the lost colors are all over the place, not just at the boundaries, so it's hard to predict which colors will be impacted and are also part of the actual image dataset.
Just for the fun of it, I also ran the following tests:
8-b/ch-->PS16-b/ch-->assigned pRGB-->Qimage-->ARGB, results in 5516502 colors.
8-b/ch-->PS16-b/ch-->assigned pRGB-->8-b/ch-->Qimage-->ARGB, results in 7784709 colors.
Qimage does dithering on input of 16-b/ch images as it converts to 8-b/ch, and no dithering on input of 8-b/ch images. No resampling and no sharpening was used, which would have potentially created additional new colors. The final 'output profile' conversion used dithering. On average, the dithering introduced a difference between 16-b/ch and 8-b/ch input with a standard deviation of 0.342 (virtually imperceptible). It looks like 8-b/ch input is not a problem, as is confirmed by actual output.
Cheers,
Bart