Confusion about 16-bit vs. 24-bit

---

Screenshots taken with n132 (and are completely unmodified PNGs straight from the CM7 screenshot function off the Power menu).

16-bit:



24-bit:



A few points of confusion...

- Do the two shots above look identical to you, and appear to both be in 24-bit colorspace? They do to me.

- Why is it that on the device itself, both appear to be in 16-bit color, with heavy banding, despite the difference in framebuffers? Is there something about the OMAP driver that is filtering/dithering or otherwise restricting the colorspace above and beyond the framebuffer itself?

Rodney

Actually got the screenshots to show up. Thanks, photobucket. Word to the wise: don't use picpaste for it. Ironically, they'll show up in preview, but not in the actual post.

Rodney

Very limited understanding of all this, but could you make an img of both and open it in QuickPic? I there there are only a few apps that can display it.

Well, that's kind of my point - the app that I was running when I took the screenshots paints _directly_ to the framebuffer...the only thing standing between it and the actual video RAM is the driver, which is why I'm awfully confused by the exactly-the-same-and-banded-like-16-bit-in-both-cases visuals on the Nook. (I could possibly explain away the both-look-24-bit screenshots by reasoning that they may somehow bypass the driver, but if the colorspace *itself* is 565, how can that be?)

Rodney

Rodney,

I tried the test on my n129 with 6/30 OC kernel and I see no real banding in 565 mode. Cant save screenshot, I get error from the power menu function that y + height must be <= bitmap.height()

How did you get the nook to go into 888 mode for the second screen shot?

Originally Posted by peramikic

Rodney,

I tried the test on my n129 with 6/30 OC kernel and I see no real banding in 565 mode. Cant save screenshot, I get error from the power menu function that y + height must be <= bitmap.height()

How did you get the nook to go into 888 mode for the second screen shot?

The banding is subtle but observable, particularly in the blue bar. (The bars are somewhat "skinny" so it's not as obvious - crank up the brightness to max to help with identification.)

You can get 888 with either the stock (read: non-OC) kernel or with n132+ and the latest Nook Tweaks from the Market.

Rodney

Originally Posted by rhester72

The banding is subtle but observable, particularly in the blue bar. (The bars are somewhat "skinny" so it's not as obvious - crank up the brightness to max to help with identification.)

You can get 888 with either the stock (read: non-OC) kernel or with n132+ and the latest Nook Tweaks from the Market.

Rodney

The test pictures are nice and all, but pictures with large areas of very subtle gradients (lots of background pictures, like clouds and such) become much more obvious, however it's not a big deal for me. I believe only a photophile would care, and I believe dalingrin said the performance increase by going to 16 bit was substantial.

Originally Posted by chisleu

The test pictures are nice and all, but pictures with large areas of very subtle gradients (lots of background pictures, like clouds and such) become much more obvious, however it's not a big deal for me. I believe only a photophile would care, and I believe dalingrin said the performance increase by going to 16 bit was substantial.

My issue isn't with static content as much as it is video...large patches of obviously "off" and blocky color moving around on dark backgrounds is -very- distracting, and makes Netflix almost unwatchable (due to the higher compression levels).

People once thought 16-bit color on the PC was the greatest thing ever - but since only "photophiles" would notice, I invite you to switch your main computer back to 16-bit for a week and see if you notice any differences.

The performance increase for 3D apps was indeed significant. 2D apps...well, show me a 2D app that stresses the GPU and then I'll care. =) In 2D, color depth and quality matter for a lot.

Rodney

Originally Posted by rhester72

The banding is subtle but observable, particularly in the blue bar. (The bars are somewhat "skinny" so it's not as obvious - crank up the brightness to max to help with identification.)

You can get 888 with either the stock (read: non-OC) kernel or with n132+ and the latest Nook Tweaks from the Market.

Rodney

Ahh yes I saw that 132+ includes Dal's OC kernal. BTW there is talk that the GPU drivers are messed up in the release, so maybe you are staying in the same frame buffer even though you change it via Tweaks app.

I looked at the bars both landscape and portrait at max bright and banding is minimal and that's in the 16bit mode. Nothing as terrible as when you start XDA app, ghaaa, now that banding. And it looks like it is really the way software implements it. QuickPic << JustPictures << Stock Galery. Quckpic has that true color mode so it looks like hardware is capable, it all depends on software implementation. Or Quickpic might have a really good dither algorithm that fools us

I also have Chainfire3d installed, so it might have something to do with it

Something weird is going on with the new GPU drivers. SurfaceFlinger is changing from RGB565 to RGB8888 as appropriate when you switch 32bit and 16 in Nook Color Tweaks but I only see 16 bit.

I'm going to revert back to our existing GPU drivers and see what happens.