Changes between Version 12 and Version 13 of img2twit Tweet

Timestamp:

05/25/2009 03:43:11 PM (15 years ago)

Author:

Sam Hocevar

Comment:

minor fixes

img2twit

@@ -59 +59 @@
 There is a common misconception that values in an information stream should be bit-aligned. This is not the case at all in `img2twit`: the bitstream can store integer values with non-power of two bounds.
 
-As an illustration, take the example of 16-bit colour coding. There are basically two widespread ways of storing RGB data into a 16-bit word: either using 5 bits per component and wasting the last bit, or using 6 bits for the G value, because the human eye is more sensible to variations of green. The RGB triplet is then computed as ''(((R) * 64 + G) * 32 + B)'', and eg. the green value is retrieved as ''(RGB / 32) % 64''. Though 5-6-5 looks rather balanced, that's 32 values of red, 64 values of green, 32 values of blue: that's actually as many values of green as the other two put together!
+As an illustration, take the example of 16-bit colour coding. There are basically two widespread ways of storing RGB data into a 16-bit word: either using 5 bits per component and wasting the last bit, or using 6 bits for the G value, because the human eye is more sensible to variations of green. The RGB triplet is then computed as ''(((R) * 64 + G) * 32 + B)'', and eg. the green value is retrieved as ''(RGB / 32) % 64''. Though 5-6-5 looks rather balanced, that's actually 32 values of red, 64 values of green and 32 values of blue: twice as many values of green... is this really required?
 
-In this case, `img2twit`'s approach would be to use 40 values of each component, where the RGB triplet is computed as ''(((R) * 40 + G) * 40 + B)'', and eg. the green value is retrieved as ''(RGB / 40) % 40''. This makes the computations a lot slower (modulo 64 is just a bit shift, while modulo 40 requires dividing the whole bitstream by 40). However, it offers better packing and a lot more control over the data representation. For instance, I found that 2 bits (4 values) per colour component was not enough, but that 3 bits (8 values) was more than required. I went for 5 values (2.58 bits).
+In this case, `img2twit`'s approach would be to use 40 values of each component, where the RGB triplet is computed as ''(((R) * 40 + G) * 40 + B)'', and eg. the green value is retrieved as ''(RGB / 40) % 40''. This makes the computations a lot slower (modulo 64 is just a bit shift, while modulo 40 requires dividing the whole bitstream by 40). However, it offers better packing and a lot more control over the data representation. For instance, I found that 2 bits (4 values) per colour component was not enough, but that 3 bits (8 values) was more than required. I went for 6 values (2.58 bits).
 
-One drawback is that this makes the bitstream completely unable to recover from bit corruptions. However, for such small streams I don't care at all.
+One drawback is that this makes the bitstream completely unable to recover from bit corruption. However, for such small streams I don't care at all.
 
 == Point selection ==