You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
Real-time PVRTC1 encoding is an interesting problem. The first pass computes endpoints by computing per-block RGB bounds, the second computes modulation. I really wish colorB's blue channel had 5 bits (vs. 4) - 4 bits for blue leads to slightly blue tinged ramps and more banding.pic.twitter.com/FqVRtYiYNs
My real-time encoder isn't using the punchthrough mode bit or the transparent mode bits, either. Even with fully opaque textures, cleverly using these mode bits would reduce error. But I would then have to do expensive error calculations during transcoding.
It seems like not having the same number of bits for each channel is just asking for the hue to get shifted around whereas saturation and luminance changes are less noticeable.
The blueish hue shift is quite noticeable on really low saturation content.
Back in my scanner driver life I noticed that image processing worked a lot better in HSL and a lot faster in RGB, so I put in an option to do speed or quality.
Found a potential solution for better PVRTC quality: Precompute the best mode bits to use for all possible (5,5,5) ETC1S block colors and 3-bit intensity table indices. Just a few bits per entry so the table isn't too large. (I'm transcoding from ETC1S encoded pixels, not RGB)
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
