User:Nrp/Weekly updates/20080628: Difference between revisions

Revision as of 00:46, 26 June 2008

Uploaded the v4l and colorspace branches to the git repository on my server
Debugged some silly colorspace mistakes
First attempts at YUV -> HSV direct conversion. It seems nobody has come up with these formulas before. I'm probably just going to approximate it, but it will still involve faking trig with ints.

Merged colorspace branch back into master
starting using cProfile to figure out what was being slow. The conclusions: pygame inits the olpc display to 16bits per color, so blitting the 8bit surfaces to 16bit display surfaces takes additional time. The main thing slowing down my RGB -> HSV conversion is actually finding the max and min of 3 values in each pixel (r, g, b), which actually takes 23ms on a 640x480 image. This doesn't sound like much, but keep in mind that to run at 30fps, each frame has to take less than 33ms to process and display. It takes around 22ms to blit and flip a 320x240 image, so processing each frame has to be a LOT faster. I feel like blitting shouldn't take that long. Perhaps there is some way to fix it.

@@ Line 14: / Line 14: @@
 == Wednesday ==
 * Merged colorspace branch back into master
+* starting using cProfile to figure out what was being slow.  The conclusions:  pygame inits the olpc display to 16bits per color, so blitting the 8bit surfaces to 16bit display surfaces takes additional time.  The main thing slowing down my RGB -> HSV conversion is actually finding the max and min of 3 values in each pixel (r, g, b), which actually takes 23ms on a 640x480 image.  This doesn't sound like much, but keep in mind that to run at 30fps, each frame has to take less than 33ms to process and display.  It takes around 22ms to blit and flip a 320x240 image, so processing each frame has to be a LOT faster.  I feel like blitting shouldn't take that long.  Perhaps there is some way to fix it.