Jump to content

Recommended Posts

Posted

With an iMac and an Eizo CG (both 30-bit colour depth possible), I don' t have any software that can support 10-bit/30-bit colour. DXO PL doesn' t / Affinity Photo doesn't. So I' m stuck.

Any ideas what software would be an alternative?

Posted

Right. But that doesn' t do any good if I cannot actually see those images in 10-bit.

Pixelmator Pro says (from website in your link):

"Extended Dynamic Range Mode for Pro Display XDR and other displays that support it"

Don' t know if this means 10/30-bit colour support....so, displaying these colours. I doubt it, because otherwise it would have been mentioned.

Posted

This still leaves room for interpretation.

On Windows, more than 8 bit seems (from memory) only supported for RBG/32 documents, with a HDR compatible display, whereas RBG/16 documents were still rendered in 8 bit colors. Can’t check now after switching to Mac.

So the question is: which Apps support 10/30 bit, and in witch document (rendering) formats? 

Mac mini M1 A2348 | MBP M3 

Windows 11 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5 | Dell 27“ 4K

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

I use iPad screenshots and videos even in the Desktop section of the forum when I expect no relevant difference.

 

Posted

Thank you fde101 and NotMyFault. I have PixelmatorPro. Beside that I asked Eizo Netherlands. They only could tell me that Photoshop does support display. Didn't t know about any other application that could actually do this. They want to check.

I don' t think that EDR mode (Extended Dynamic Range) in Pxelmator Pro does anything like true 10/30-bit colour support (that is...displaying those colours). Like it says, it uses the high peak brightness of the XDR display. Shouldn't be necessary for displaying 10/30-bit colour.

Posted

I believe we shouldn't mix those things.

8bit/10bit is viewing bit depth (between your GPU and display). It tells how smooth gradients will be as there will be more colors in 10bit mode because there are no longer 256 gradation steps but 1024.

Another thing is archiving bit depth (document mode). It may be RGB/8, RGB/16, RGB32, etc. It determines how color data will be stored in file when saved.

So we may find ourselves working with RGB/8 document on a 30bit display and we also may work with RGB/16 image on a cheap 6bit+FRC display which is barely reaches 24bit with frame rate control. 

As far as I know, Photoshop does support 30bit viewing mode. At least it does on my Mac system. Gradients are much smoother in this mode.

In case of macOS everyone can check if they're currently in 30bit mode system-wide or not.

Run the following command in Terminal:

/System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a > AGDCDiagnose.txt 2>&1 

Then go to your home folder and open text file AGDCDiagnose.txt, go to the end of file and try to find following strings:

Pixel Encoding    1 (RGB444)
Bits Per Color Component    4 (10 bpc)

That will tell you that system is currently using 10bits per channel. To double check that you can go to About This Mac -> System Report -> Graphics/Displays. You need to look for this line:

Framebuffer Depth:    30-Bit Color (ARGB2101010)

Posted

Thank you Alex. I know and you say it right: Photoshop supports 30bit viewing. I want those smooth gradations (and less chance for banding/more information out of shadows/etc.).

Do you know of any other application/photo software, that can do this? Because that' s exactly what I mean and want. Hardware is capable here...monitors/cables/etc. Now...where' s the software?

My iMac:

Framebuffer Depth: 30-bits color (ARGB2101010)

My Eizo CG2700S:

Framebuffer Depth: 30-bits color (ARGB2101010)

I hope, you don' t mind Alex, but I have shared part of your excellent reaction on another forum. Cannot explain it better myself.

 

Posted
2 hours ago, Alex M said:

I believe we shouldn't mix those things.

8bit/10bit is viewing bit depth (between your GPU and display). It tells how smooth gradients will be as there will be more colors in 10bit mode because there are no longer 256 gradation steps but 1024.

Another thing is archiving bit depth (document mode). It may be RGB/8, RGB/16, RGB32, etc. It determines how color data will be stored in file when saved.

So we may find ourselves working with RGB/8 document on a 30bit display and we also may work with RGB/16 image on a cheap 6bit+FRC display which is barely reaches 24bit with frame rate control. 

As far as I know, Photoshop does support 30bit viewing mode. At least it does on my Mac system. Gradients are much smoother in this mode.

In case of macOS everyone can check if they're currently in 30bit mode system-wide or not.

Run the following command in Terminal:

/System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a > AGDCDiagnose.txt 2>&1 

Then go to your home folder and open text file AGDCDiagnose.txt, go to the end of file and try to find following strings:

Pixel Encoding    1 (RGB444)
Bits Per Color Component    4 (10 bpc)

That will tell you that system is currently using 10bits per channel. To double check that you can go to About This Mac -> System Report -> Graphics/Displays. You need to look for this line:

Framebuffer Depth:    30-Bit Color (ARGB2101010)

I don't try to mix up thinks, but Affinity does. My observation (when using windows) was: you can use 10bit capable display only when using RGB32 documents, but not when using RGB16 documents. This might be a Windows restriction or Nvidia driver restriction.

My M1 Mac does not show an of the information, neither in Terminal nor in System report.

AGDC node not found, bailing ...

My LG display supports 10 bit ("Ultra deep Colour")

And if I create gradients in RGB/16 mode, I get the same banding as in RGB/8 mode (every 4 px on x-axis a visible step.If it would support 10 bit, I would see no step at all, or a step every x pixel) . Affinity seems unable to use more than 8 bit except in RGB/32 mode.

 

Below: you may notice banding (hard edges) at 749, 753, etc2136824621_Screenshot2022-09-02at16_29_08.thumb.png.2b533aee009b5f8cfcd20e555b81bf92.png

Screenshot 2022-09-02 at 16.21.12.png

Mac mini M1 A2348 | MBP M3 

Windows 11 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5 | Dell 27“ 4K

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

I use iPad screenshots and videos even in the Desktop section of the forum when I expect no relevant difference.

 

Posted

In no way my previous message was addressed to you, dear @NotMyFault. I know you long enough on this forum as very smart, clever and highly educated person knowing probably way more advanced and highly technical stuff than myself. Your curiousity and constant desire to learn more simply admire and inspires me every time I found your posts here.

I fully agree with you that for a proper 30bit workflow it might be better to switch to RGB/16 mode and just let the hardware do the rest. I mean, that longer we keep higher bit depth till final export, the better all our intermediate editing results will be.

You wrote, that you get 10 bit colour resolution if you create gradients in RGB/16 mode. Does this mean that you don't notice any color banding in Affinity apps canvas on your system?

The very simple test would be creating 1024px wide canvas and filling it with a simple black-to-white gradient. In RGB/8 there will be 4px (1024/4) wide steps visible. And in theory, in RGB/16 mode they should disappear.

Regarding your display: Well this may be a bit different for M1. There's another test that can quickly show us, if you have 30bit enabled system-wide. Try looking at this image: https://raw.githubusercontent.com/jursonovicst/gradient/master/test_sequences/1920x1080/gradient_1920-1080_25-50.png

Posted

For comparison, in RGB/32 I cannot see any banding / steps. as the screen capture might reduce colour depth, the file below may show banding caused by file format

 

1783433538_Screenshot2022-09-02at16_32_01.thumb.png.56793d62fb9d9b40378e670630d9da20.png

 

and a screenshot of both files at once.

975140934_Screenshot2022-09-02at16_40_47.thumb.png.ebce4fb3297270869255978f913dcb99.png

and if I import this screenshot back into photo, and use blend mode diff + levels to analyse the difference, you again see that documents in RGB/16 only use 8 bit color depth rendered to the display

1983327513_Screenshot2022-09-02at16_45_13.thumb.png.4c31c47648a4e295d5bbfa7d04fe8ba5.png

Mac mini M1 A2348 | MBP M3 

Windows 11 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5 | Dell 27“ 4K

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

I use iPad screenshots and videos even in the Desktop section of the forum when I expect no relevant difference.

 

Posted
6 minutes ago, Alex M said:

In no way my previous message was addressed to you, dear @NotMyFault. I know you long enough on this forum as very smart, clever and highly educated person knowing probably way more advanced and highly technical stuff than myself. Your curiousity and constant desire to learn more simply admire and inspires me every time I found your posts here.

I fully agree with you that for a proper 30bit workflow it might be better to switch to RGB/16 mode and just let the hardware do the rest. I mean, that longer we keep higher bit depth till final export, the better all our intermediate editing results will be.

You wrote, that you get 10 bit colour resolution if you create gradients in RGB/16 mode. Does this mean that you don't notice any color banding in Affinity apps canvas on your system?

The very simple test would be creating 1024px wide canvas and filling it with a simple black-to-white gradient. In RGB/8 there will be 4px (1024/4) wide steps visible. And in theory, in RGB/16 mode they should disappear.

Regarding your display: Well this may be a bit different for M1. There's another test that can quickly show us, if you have 30bit enabled system-wide. Try looking at this image: https://raw.githubusercontent.com/jursonovicst/gradient/master/test_sequences/1920x1080/gradient_1920-1080_25-50.png

Thanks for sharing, we had the same basic idea.

This file again confirms: Affinity is unable to render more than 8 bit color depth to the display in RGB/16 mode.

 

Using MacOS Preview App, I can clearly see the difference between 8 and 10 bit gradients. So my Display and OS works correct with this regard.

Mac mini M1 A2348 | MBP M3 

Windows 11 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5 | Dell 27“ 4K

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

I use iPad screenshots and videos even in the Desktop section of the forum when I expect no relevant difference.

 

Posted
6 minutes ago, NotMyFault said:

you again see that documents in RGB/16 only use 8 bit color depth rendered to the display

Fully confirms my findings as well, thank you very much. I believe that needs to be logged as potential area for improvement for future releases.

Posted

Here the final proof:

Mac OS Preview App renders 10 bit depth, Affinity is limited to 8 bit depth 

 

Screenshot 2022-09-02 at 16.54.54.png

 

filed a bug report:

 

Mac mini M1 A2348 | MBP M3 

Windows 11 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5 | Dell 27“ 4K

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

I use iPad screenshots and videos even in the Desktop section of the forum when I expect no relevant difference.

 

Posted
On 9/2/2022 at 7:44 AM, Mujabad said:

I don' t think that EDR mode (Extended Dynamic Range) in Pxelmator Pro does anything like true 10/30-bit colour support (that is...displaying those colours). Like it says, it uses the high peak brightness of the XDR display. Shouldn't be necessary for displaying 10/30-bit colour.

Quoting from that page:

Quote

The display’s true 10-bit color depth and P3 wide color gamut are natively supported in Pixelmator Pro.

 

Granted that what it does not say is whether or not 10-bit color depth is supported in displays other than that one.

Posted

I' m sure EDR is not the same as 10-30-bit colour support..in editing (as I would like).

This is what they say:

Pixelmator Pro features EDR mode, which will let you view and edit images in 10-bit color. However, exporting in 10-bit color isn't available as a feature at the moment. We do plan to expand Pixelmator Pro's EDR functionality in the future. You can read more about EDR mode here: https://www.pixelmator.com/support/guide/pixelmator-pro/693

Indeed extending dynamic range shouldn't be necessary at all. If at all, it would even work less optimal.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.