Pointing out a quick contradiction here:
If your red tones look different here (7), yet you can't display the wider gamut (1), could it be because of an incorrect rendering intent (3). How do you know when you're displaying the correct ones if you can't display the larger gamut, and more so if your screen displays the sRGB gamut and you can visibly see a difference when you convert from AdobeRGB TO sRGB then isn't this indicative of a loss of colour accuracy due to conversion since it implies that in the original wide gamut would display the original colour on a correct wide gamut display?
Well, I only
think I can't display the full spread of the gamut. I don't actually know. (
My current monitor is a 6bpp screen with an 8bpp pallet) And it might be that with AdobeRGB or any other color-space that it will indeed select and display the pallet colors most populated in the file. So is there's "Red 100" in AdobeRGB but "Red 100" doesn't exist in sRGB and the image has "Red 100" in it then the app or whatever decides what to show (I assume it's the app) might display "Red 100" even though it can't actually display the entire gamut. When CYMK editing in PS printed and displayed colors are VERY different (especially reds!) then when printing and editing in RGB modes. And I can never get the same reds in RGB mode no matter how much I tweak. And visa versa. So, it may be selective with different weights and pallet selections available in different modes. Honestly, I dunno. Those are all just guesses.
The printers some of the higher end CcMmYyK printers and the CMYRGBK printers can display the gamut.
You mean 7-ink printers? Yeah, those are $350 now. Mine is 5-ink on purpose because I'm totally CHEAP!
$0.15 a print "L" size in 5-color and $0.27 a print "L" sized in 7-color. The actual printers are the same price though. +/- $50.00
And the branding won't be instantly visible, this is something for the pixel peepers, but like 16bit editing it becomes relevant if you do quite a bit of editing on the files since when you extend the dynamic range without extending the bit depth your average processing error increases too.
Banding is very noticeable on my 5-ink printer anywhere there are closely spaced tones spread over a reasonable sized distance. I hear it's not so with the 7-ink models but that's the trade off I took for the cheeper prints. If I hate it terribly I can select it and fill with a solid color or a more diverse gradient to eliminate it. So far I've always been too lazy and just think "crappy epson/canon printers, bah!"
Mind you this may sound like a moot point to some, and it is to a degree. There are no doubt quite a few people on this forum who will disagree with me, but I will bet a few lira that those are the people who either have nicer screens, printer their own photos either at a pro lab or with a nicer printer, use 16bit processing to get the most out of their pictures, and otherwise have something to gain.
Let'em disagree. We'll have ourselves a nice discussion.
For me it's not moot at all. I want to know what's going on under the hood and what my options are so if I need to skew something (write a program) or use that info to my advantage somehow in editing I'll know more about what I'm doing. But I of course use, edit, and store in 16 bit.
PS those who "have something to gain" are the funniest. :mrgreen:
But for the majority of this forum who will take a photo and store it on their computer and look at it on their screens, more data for data sake in this case is a step backwards since you're literally clipping the colour channels of the data you are displaying. It just looks more subtle than highlight clipping and would be visible as a shift in colour (e.g. from Green to Yellow when you shoot a high contrast plant).
Hmm. Yeah. I guess that's true (about the wasted space thing) but what about in 4 or 5 years if the new world order hasn't put us all in the ovens I mean.. Won't more computers, (display cards and monitors) be 16 bit savvy? What then when all you're coolest shots from long ago are in a dreaded 8-bit space.
Also, I don't see how anything is clipped differently. When you convert it into 8 bit from 16 bit (that was created from the 12 or 14 bit camera files) isn't it the same exact thing as converting it to 8 bit. Only it's done on the fly so to speak, and not actually saved that way? I thought so anyway.
See this makes (3) very much applicable. More so to people with no rendering intent whatsoever
No rendering intent??? At all? So just send them an empty file padded with all 0's to the same size. I'm not understanding this part at all. If they have 12, 14, or 16 bit files then it's overkill for rendering an 8-bit display (size-wise) - granted. But if you're keeping both the 8 and 16 bit formats on your storage device, just send them the 8-bit files and no problem. Tho in actuality, the only problem I can see is the file size. It's going to render to their screen the same or better than an 8-bit depending on their display subsystem and monitor's ability (or print if rendered to a printer).
What am I missing here?
It all makes sense if you take a photo (most cameras are native AdobeRGB, but few scenes grander than a sunset will make use of the extra gamut), then edit that photo on a screen with a wide gamut, and then print it on a printer with native AdobeRGB support. Other than that, sRGB is the standard and the only way to make the process reliable.
Sorry.
may have been a more appropriate emoticon.
![[No title]](/data/xfmg/thumbnail/41/41891-e5bba75ac5ce57c6892ade4cfc3f7d4c.jpg?1734176244)