Bugzilla – Bug 12634
Explore 18 bit color depth on baby
Last modified: 2011-11-06 23:24:26 UTC
Is this a bug? We're having all kinds of problems making wallpapers look right with our current color depth. Is baby's screen limited to a 16 bit color depth? QVGAlandscapeSkin hard-codes to that: Framework:setVideoMode(screenWidth, screenHeight, 16, jiveMain:isFullscreen()) I was tempted to just ssh to my baby and change it to 24 and see what happened. Maybe it's lucky that I can't get ssh to work...will BAD things happen if I do that?
Yes, for now baby has a 16-bit color depth. The wallpapers, and any other assets that have significant banding, will need to be dithered.
(A bit of background: the screen itself is 18-bit, but using that means moving to 24-bit rendering, which doubles memory and cpu utilization. We can look at an optimization for this later. Noah should know all this.)
The dithering appears to be problematic for several of the wallpapers, including Encore. I guess this is for Noah to figure out, but in discussion late last night on the phone, he cited this as "the single biggest UI problem we're going to have on baby. It's really bad". I'll let Noah comment further.
I should say, I mentioned Encore because that's been identified as the new default wallpaper, and it looks terrible right now, even after being dithered. Noah, just as a sanity check, could you make sure the correct bb_encore.png with dithering has been checked into your assets/ area? I've confirmed that the version I'm using in the firmware is the same as what is in assets/.
We'll only have 16 bits for release, as Dean says we _might_ be able to go to 18 bits as a future enhancement.
That's weird, I don't think it looks terrible to me right now on the device. (What's terrible is the oily film behind the lens, but that will be wiped off...) Can you post a picture of what you see, ben?
Created attachment 5395 [details] sp desktop (with display set to 16 bit) - looks equally bad on baby
There are 2 types of dithering effects I can apply to reduce the number of colors/banding in the gradient: 1. Diffusion 0-100% 2. Noise 0-100% Attaching screen images for reference...
Created attachment 5396 [details] Dither -diffuse
Created attachment 5397 [details] Dither -noise
Created attachment 5398 [details] Encore - updated teal (no dither) test
Created attachment 5399 [details] screenshot of teal encore with mac set to 16bit color
Created attachment 5400 [details] Encore dither test various Try bb_encore_teal_noise2.png first. It seemed to be the closest on my monitor set to 16bit.
Noah, can you checkin the noise2 image as bb_encore.png in the wallpaper section of assets/ ? That's going to be the quickest way to check it out on the device. If you have set the color depth of your PC to 16, that's probably going to be a fairly clear indication of how it will look.
Noah: are you using the 565 plugin that we used for Controller?
Dean - I am using the DepthDither 2.0 plugin same as what was used on the Jive development. Not sure what 565 is? http://depthdither.graphest.com/
Ah, ok, I'm using a different plugin from http://www.telegraphics.com.au/sw/ (5_6_5 dither). But the one you have should work even better and has more control. Good! Use the R5G6B5 setting like in the example on that site, then play with the dither mode that looks best for the given image.
This bug has been identified as one that may not be required for MPQ since it now seems clear that MPQ and MP firmwares will be different. Please comment if you disagree with this assessment. Thanks!
The assets that are using gradients have a dither effect applied them. From a visual asset perspective the problems have been fixed. The original bug is referencing an engineering constraint on the displays bit depth and NOT a graphical but. Please reassign accordingly.
a very long punt of this one, but leaving open to explore using 18 bit color depth
Tom is no longer available to us
Unassigned bugs cannot have a priority.