Hey 
I see there is desire for insights and understanding by reading press articles about 2.3.3 color change.
First, a statement:
What I know:
- What I will explain here
- 2.3.3 change looks bad on my device : Colors are washed out, the response is very far from a 2.2 gamma / sRGB calibrated screen should look like.
What I don't know:
- If the result is bad on every screen. Probably not.
It's known Samsung manufactured at least 2 different Super AMOLED screen revisions, and it's possible that 2.3.3 looks perfect on some screens.
Links:
Issue 15039: Android 2.3.3 screen yellowish
What changed:
In 2.3.3, the screen (framebuffer) driver has been updated.
This screen driver consist of several files, including code that calculate gamma adjustment points and brightness levels dynamically based on a reference gamma table.
Change in 2.3.3 can be categorized in 3 types:
Code and gamma points calculations
1/ A new feature introduced is the ability of the driver to read informations from the screen hardware.
So far, there was no detection at all, just configuration sent.
Now the driver has the ability to ask to the screen: "what are your factory calibration levels for Red, Green and Blue"
2/ Another change is in the driver initialization sequence, supposed to setup the internal screen control hardware calculations for gamma 2.2 instead of something else (not specified)
It has the effect of brightening shadows.
Color temperature change
The updated driver has the ability to use multipliers to adjust the screen temperature on the linear scale.
In theory, it should allow to change red/green/blue levels without altering the color rendition accuracy, despite the complex calculations needed to generate color profiles at each brightness levels.
Today, those Red Green Blue multipliers are fixed in stone, but I'll publish shortly a kernel version + an app so you can control them manually.
It will needed to be treated with care because of potential overheat or fast burn-in side-effects at too high brightness levels.
Different Gamma table (aka Super AMOLED color profile)
Colors calibration for Super AMOLED design has almost no common points with current methods applicable to LCD only.
Calibrating a AMOLED screen requires to setup 255 different hardware correction profiles, one per brightness level.
Instead of that, math calculations, based on a reference gamma table are used to setup responses applied by the screen hardware, that control each single led accordingly.
On a LCD screen it's much simpler as the LCD panel response is always the same: One profile is virtually enough as brightness changes correspond to adjustments of the backlight power.
This is why LCD-type adjustment calibration or color change tools (like the one in CyanogenMod) cannot be used to calibrate Super AMOLED screen.
The gamma table has been vastly updated. It also brighten the shadows compared to previous profiles.
However, Google's previous Gamma table exhibited a purple deviation in dark grays, especially at low brightness settings. This new gamma table fixes the issue.
Source files:
- main driver - calculations
- hardware gamma adjustment points placement
- gamma table (and in the same file: screen initializations sequence)
Commits - source changes:
1/ ARM: herring: panel: Adjust pentile gamma table
2/ s3cfb_tl2796: Add support for reading mtp gamma register offsets
3/ s3cfb_tl2796: Add debug function to read current gamma correction registers
4/ ARM: herring: panel: Add support for reading mtp data
5/ ARM: herring: panel: Update gamma table
6/ ARM: herring: panel: Correct color temperature.
Conclusions
The new driver is properly (I would say: smartly!) written. It implement features exactly how it should be done.
Also, it should work well on each screen revision as it adapt to them.
However, something went wrong in the process.
Calibrating a screen cannot be done
Also, this is a Super AMOLED. Contrast Ratio of it is almost infinite.
Trying to apply exactly color profiles designed for lesser screens, with lower contrasts and gamut cannot work, by design.
However it doesn't mean a Super AMOLED screen is condemned to exhibit washed out or absurd over-saturated colors.
In a similar way, calibrating plasma TVs is not easy but can lead to excellent results.
Kernel for color developers, allowing hardware calibration
In this post
and this one
Yes, a third one too
Yet again another one
write in progress... comments welcome already
I see there is desire for insights and understanding by reading press articles about 2.3.3 color change.
First, a statement:
What I know:
- What I will explain here
- 2.3.3 change looks bad on my device : Colors are washed out, the response is very far from a 2.2 gamma / sRGB calibrated screen should look like.
What I don't know:
- If the result is bad on every screen. Probably not.
It's known Samsung manufactured at least 2 different Super AMOLED screen revisions, and it's possible that 2.3.3 looks perfect on some screens.
Links:
Issue 15039: Android 2.3.3 screen yellowish
What changed:
In 2.3.3, the screen (framebuffer) driver has been updated.
This screen driver consist of several files, including code that calculate gamma adjustment points and brightness levels dynamically based on a reference gamma table.
Change in 2.3.3 can be categorized in 3 types:
Code and gamma points calculations
1/ A new feature introduced is the ability of the driver to read informations from the screen hardware.
So far, there was no detection at all, just configuration sent.
Now the driver has the ability to ask to the screen: "what are your factory calibration levels for Red, Green and Blue"
2/ Another change is in the driver initialization sequence, supposed to setup the internal screen control hardware calculations for gamma 2.2 instead of something else (not specified)
It has the effect of brightening shadows.
Color temperature change
The updated driver has the ability to use multipliers to adjust the screen temperature on the linear scale.
In theory, it should allow to change red/green/blue levels without altering the color rendition accuracy, despite the complex calculations needed to generate color profiles at each brightness levels.
Today, those Red Green Blue multipliers are fixed in stone, but I'll publish shortly a kernel version + an app so you can control them manually.
It will needed to be treated with care because of potential overheat or fast burn-in side-effects at too high brightness levels.
Different Gamma table (aka Super AMOLED color profile)
Colors calibration for Super AMOLED design has almost no common points with current methods applicable to LCD only.
Calibrating a AMOLED screen requires to setup 255 different hardware correction profiles, one per brightness level.
Instead of that, math calculations, based on a reference gamma table are used to setup responses applied by the screen hardware, that control each single led accordingly.
On a LCD screen it's much simpler as the LCD panel response is always the same: One profile is virtually enough as brightness changes correspond to adjustments of the backlight power.
This is why LCD-type adjustment calibration or color change tools (like the one in CyanogenMod) cannot be used to calibrate Super AMOLED screen.
The gamma table has been vastly updated. It also brighten the shadows compared to previous profiles.
However, Google's previous Gamma table exhibited a purple deviation in dark grays, especially at low brightness settings. This new gamma table fixes the issue.
Source files:
- main driver - calculations
- hardware gamma adjustment points placement
- gamma table (and in the same file: screen initializations sequence)
Commits - source changes:
1/ ARM: herring: panel: Adjust pentile gamma table
2/ s3cfb_tl2796: Add support for reading mtp gamma register offsets
3/ s3cfb_tl2796: Add debug function to read current gamma correction registers
4/ ARM: herring: panel: Add support for reading mtp data
5/ ARM: herring: panel: Update gamma table
6/ ARM: herring: panel: Correct color temperature.
Conclusions
The new driver is properly (I would say: smartly!) written. It implement features exactly how it should be done.
Also, it should work well on each screen revision as it adapt to them.
However, something went wrong in the process.
Calibrating a screen cannot be done
Also, this is a Super AMOLED. Contrast Ratio of it is almost infinite.
Trying to apply exactly color profiles designed for lesser screens, with lower contrasts and gamut cannot work, by design.
However it doesn't mean a Super AMOLED screen is condemned to exhibit washed out or absurd over-saturated colors.
In a similar way, calibrating plasma TVs is not easy but can lead to excellent results.
Kernel for color developers, allowing hardware calibration
In this post
and this one
Yes, a third one too
Yet again another one
write in progress... comments welcome already
Last edited:
