So I did my first monitor color calibration with my Spyder5. I know this is not the best possible calibration tool it is mighty slow but it is all I could afford
I did a XYZ Lut + matrix profile Medium speed and 800 patches. From everything I see in the report things look fine.
However, while messing about with gimp and color management (I wanted to see how the display changed between color managed and non color managed) I noticed a banding issue in my tests.
First I did some solid back fills and things looked fine when comparing managed and non managed.
Then I tried a black to white gradient and everything was smooth when non color managed but when I turned on my monitor profile the banding was hideous.
Did I do something wrong with my calibration/profile? From what I understand is I should not have any banding.
From what I’ve read, DisplayCal makes the best quality profile for your monitor, while the manufacturer software varies in quality from “close to as good as DisplayCal” to “utter junk.” Which software did you use to produce the profile and on what OS?
For what its worth, my colormunki is also super slow at generating a profile.
Used DisplayCal currently running Fedora Linux. If it is worth anything I have a Dell U2515H monitor. Set displaycal to white led as that is the mode this monitor requires. almost everything default just changed color temp to 6500k, whitepoint to 120 cd/m2. Black level is as measured. gama 2.2. Medium speed, xyz lut + matrix 833 patches. profile quality high.
I am assuming some issue is going on with the blacks/greys causing the banding.
Seems either way dithering applied or no the banding is present when my monitor profile is active in gimp. Not sure if Screenshots can help here but I will try anyway lol. It is almost like a greenish and magentaish hue to the banding I think. Also if helpful I do have one of those html verification reports taken with the Extended testchart of displaycal. Again tho in this report it seems like everything is ready ok but I am no expert on interpretation.
My profile is enabled in the system. If I set the profile in gimp to none and then check use system monitor profile the same banding persists. If I leave the profile selected and check use system monitor profile the banding also persists. I tried Perceptual rendering intent as well as relative. I also tried to remove the black point compensation. Either way the banding seems identical. Even tried looking at the gradient in Geeqie. the banding is less pronounced in Geeqie but still present.
It makes me think something is wrong with the calibration and not a gimp setting. The gradient should be smooth like I get without the profile corrections. Maybe I should have used the auto black point correction setting?
Still seems odd I would assume this issue falls under RGB Gray balance. my delta C’00 is 0.17
and the combinded deta a/b is 0.45 both good numbers according to this verification tho so I am at a loss. Maybe a pure gradient is a terrible test?
So I think I figured out the issue. After some research it seems this gradient issue is actual a issue with the default bit depth of a gimp image file. Apparently 8bit images don’t have enough color information causing these banding artifacts in the gradient. If I create a new image at 16bit all the banding artifacts are gone and I have a nice smooth gradient. So apparently my color profile is fine it is just a bit depth limitation.
Ah, I think I recently experienced the same thing in my hack software. In my linux compile, I was getting significant posterization in the display of a certain image, but it didn’t show up in any of the output files. I pored over my code for a couple of weeks looking for the culprit, finally found it in the display pipeline. I was first down-converting the internal float working image to 8-bit for wxWidgets, then doing the display profile transform, ostensibly to gain performance.
Turns out the 8bit → 8bit display profile transform was where the posterization was introduced. So, I further streamlined that conversion, doing both the float → 8bit and the color transform in the same LittleCMS cmsTransform call. Ta-da, no posterization, and quicker to boot.
yea it makes total sense really as dropping down to 8bit you are losing millions of colors so it makes sense that artifacts would wiggle their nose under certain circumstances even more so in your case doing transforms on the color space.
