Trent Piepho wrote: > > On Wed, 28 Mar 2001, Colin Shaw wrote: > > converting from say RGB888 to YUV420 where the space spanned by the result > > is significantly smaller than that of the original. It would appear that > > this lookup table would require about 2^24 entries and would only map to > > 64 possible YUV420 colors. Do you apply granularity to the RGB888 > > pointers so that it doesn't hog so much memory? Are there any obvious > > shortcuts that I am overlooking? > > The standard way it to use 9 tables of 256 entries, one for each combination > of (R, G, B) with (Y, U, V). Then you do something like > > Y = R_to_Y[R] + G_to_Y[G] + B_to_Y[B]; > U = R_to_U[R] + G_to_U[G] + B_to_U[B]; > V = R_to_V[R] + G_to_V[G] + B_to_V[B]; > > So instead of one table lookup, in a huge table, you do 9 lookups plus a few > additions. For more accuracy you would probably want to use fixed point > arithmetic. You don't need all 9 tables either, as some of them will end up > being the same. I actually benchmarked these two versions a while ago, and it turns out that on a reasonably new PC (K6/PII or up), fixed point arithmetic is quite a bit faster than tables - It turns out that a fixed point multiply is a lot quicker than a memory access (especially when taking the heavy cache usage of image processing into account). On older PCs (Pentium/K5/etc) the table version is quicker. -justin
