Pages: 1 2 [3] 4 5 ... 7   Go Down

Author Topic: 16 Bit Printing  (Read 48039 times)

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #40 on: April 30, 2014, 08:58:40 pm »

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?
Quote
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.
Quote
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: 16 Bit Printing
« Reply #41 on: May 01, 2014, 12:21:13 am »

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?

Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #42 on: May 01, 2014, 10:20:48 am »

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:

Quote
> 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

Quote
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #43 on: May 01, 2014, 10:42:05 am »

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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: 16 Bit Printing
« Reply #44 on: May 01, 2014, 11:59:36 am »

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 :~)
Logged

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: 16 Bit Printing
« Reply #45 on: May 01, 2014, 12:03:55 pm »

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 (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
Logged
== If you do what you did, you'll get what you got. ==

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: 16 Bit Printing
« Reply #46 on: May 01, 2014, 12:12:02 pm »

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 that are often mentioned in this context.

Cheers,
Bart
Logged
== If you do what you did, you'll get what you got. ==

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #47 on: May 01, 2014, 12:13:26 pm »

Bruce on BruceRGB early on: http://www.creativepro.com/article/out-of-gamut-finessing-photoshop-color

From the ColorSync list:
Quote
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
Quote
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).
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #48 on: May 01, 2014, 12:16:09 pm »

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?
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: 16 Bit Printing
« Reply #49 on: May 01, 2014, 12:40:59 pm »

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.

Quote
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
Logged
== If you do what you did, you'll get what you got. ==

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: 16 Bit Printing
« Reply #50 on: May 01, 2014, 12:46:04 pm »

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).
 
Quote
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
« Last Edit: May 01, 2014, 12:49:48 pm by BartvanderWolf »
Logged
== If you do what you did, you'll get what you got. ==

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: 16 Bit Printing
« Reply #51 on: May 01, 2014, 12:55:01 pm »

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

:~)
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #52 on: May 01, 2014, 12:55:44 pm »

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.
Quote
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #53 on: May 01, 2014, 01:01:01 pm »

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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Paul2660

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 4066
    • Photos of Arkansas
Re: 16 Bit Printing
« Reply #54 on: May 01, 2014, 01:13:21 pm »

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
Logged
Paul Caldwell
Little Rock, Arkansas U.S.
www.photosofarkansas.com

William Walker

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1134
    • William Walker Landscapes
Re: 16 Bit Printing
« Reply #55 on: May 01, 2014, 01:46:53 pm »

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?
 
Logged
"What can be asserted without evidence can also be dismissed without evidence." Christopher Hitchens

Bart_van_der_Wolf

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 8913
Re: 16 Bit Printing
« Reply #56 on: May 01, 2014, 02:23:53 pm »

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
Logged
== If you do what you did, you'll get what you got. ==

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #57 on: May 01, 2014, 02:30:34 pm »

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?
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

JRSmit

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 922
    • Jan R. Smit Fine Art Printing Specialist
Re: 16 Bit Printing
« Reply #58 on: May 01, 2014, 03:15:41 pm »

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.
Logged
Fine art photography: janrsmit.com
Fine Art Printing Specialist: www.fineartprintingspecialist.nl


Jan R. Smit

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: 16 Bit Printing
« Reply #59 on: May 01, 2014, 03:21:16 pm »

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
Quote
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).
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".
Pages: 1 2 [3] 4 5 ... 7   Go Up