10/30bit colour support computer and monitor (in my case even 2 monitors), and 8bits per channel in used software (DXO PL). If this is you…what do you do? Maybe extra software next to/in conjunction with PL? Maybe nothing at all? Maybe not important? Maybe you just don’ t care?
Really interested in workflow.
Thank you!
3x8 bits are good enough to prevent steps to be visible for the human eye. Having more bits per colour could be an advantage for a few things, but again, the difference would hardly be visible.
Internally, PhotoLab uses more than 8 bits per channel. Otherwise, using 12 or 14 bit RAW files would be a waste of resources…but the display driver reduces whatever number of bits it gets to whatever the display hardware can stomach, which is, in most cases, 3x8 bits.
PS: Vote for your proposal, @mujabad.
2 Likes
Thnxs Platypus. 10bits/30bits monitor here. Hopefully no reducing by PL.
A suggestion: why is this topic created as a voteable feature request, when such requests for 30-bit color support already exist? This topic should probably be recast as a tip or tutorial.
Consider the following chain of displaying your content:
- Content → Application → OS → Driver → Display internal electronics → Display panel + backlight
Somewhere, bit depth has to be adapted between the end points, the later the better.
You’re right Egregius. Don’ t know how to move this.
Don’ t know what you exactly mean by this, Platypus.
Content: (what do you mean?)
Application: DXO PL (8bit colour per channel)
Mac OS / 10bpc + Eizo CG2700S Wide Gamut monitor/ 10bpc colour
Canon PROgraf-1000 printer
Okay, I’ll give it another try.
- you have a RAW image with 14 bits per channel (14x4 for RGGB of the typical Bayer sensor)
- PhotoLab reads 4 x 14 bits, decodes it into 3x64, 3x32, 3x16 or whatever -
and you add your customising adjustments like exposure, local adjustments etc. - as your screen can show 3x10 bits, somewhere between PhotoLab (decoder + customizer functionality) and your display panel (the stuff that will turn bits into colour and brightness), bit depth must be adapted, which is usually done by the driver, which translates PhotoLab output to something that your display electronics can understand. If there were no driver, PhotoLab would have to provide “translations” for whatever output device could come along.
Imagine the driver as being an interpreter at a meeting. Attendants don’t have to speak everybody else’s languages, because an interpreter is there to help.
1 Like
I think I understand, but I’ ll have to read more into this.
My simple thought is, that I cannot see 10bpc colours inside PL (despite the fact that driver supports it and monitor could actually show it; PL is “restricted” to 8bpc). Working on files in PL therefore seem to limit me.
Like I said, I’ ll (have to) look deeper into this.
Thnxs again for the extra effort!
What makes you think that?
According to Photoshop’s advanced performance settings, PS will do 10bpc on my iMac. 8bpc has been maximum bit depth in the Mac’s OSs for a while, but this limit seems to have gone, GPU permitting.
Just for fun:
- 8bpc resolves colours with 0.4% “accuracy”, 10 bpc will do 0.1%.
- according to this text, we cab distinguish 150 hues, so 8 bits should be more than enough for H in a HSB model. 10 bits would resolve 1024 hues, almost 7 times the number we can actually distinguish.
Well, especially this thread makes me think that:
Especially your question:
Does this mean that DPL only puts out 8 bits per channel to the dislay but works with > 8 bits per channel and prints and writes files with > 8 bits per channel?
I’d appreciate some insight here…
And Benoits answer:
Hi.
That’s correct. For now, the picture is converted into 8-bits per channel just before displaying, while it can be > 8 bits inside processing or at export…
So, converted to >8 bits per channel just before displaying .
Now I’ m not quite sure, what he means by : " >8bits inside processing"…at export I understand, but that doesn’ t help while editing.
I know this is PL3 but I asked later in a thread, and there where no changes in this field.
I have such a system and have spent the $$ to support that desire as well.
I agree and cast my VOTE for your proposal as well.
MGBJAY
As I said near the beginning of this thread, there is already a votable feature request for this. It’s here:
I hope Jay voted in that thread as well (like I did)