heya,
...I think this is mostly directed to Iohannes...
...I was trying to use pix_colorreduce the other day and it didn't do anything: then I looked at the code and realized that on OSX, the YUV render loop is commented out and isn't doing anything...and, like the comment says, it crashed when uncommented...then I poked around and found out that imageStruct.fromUYVY() is just doing a memcpy(): it isn't recognizing that it needs to switch the colorspace to RGBA...
...so then I realized I don't really know how this auto-colorspace switching is supposed to work? In this example, the pix_film is naturally opened to yuv colorspace...
...now, having looked a bit more thru the comments, am I correct in understanding that the format is set from the incoming image? This is how it seems to be trying, and I don't think would ever work: it's just asking someone to make a copy of themself...
...getting more confusing: on creation, [pix_film] first sets m_pixBlock.image.setCsizeByFormat() to GL_BGRA_EXT...then it switches it to GL_YUV422_GEM; I guess this happens because pix_filmDarwin has m_colorspace = GL_YCBCR_422_GEM in it's creation? And then [pix_colorreduce] sets tempImage.setCsizeByFormat(GL_RGBA) on creation...?
...hmm, I guess I just need your explanation on how you think it's supposed to work :-) Seems to me that we'd have to tell it what space to switch to, and that it would be easier/more reliable to know what space it's switching from?
...or perhaps this is a huge hiccup from trying to have different default colorspaces on different platforms?
...also, imageStruct.fromYV12 should probably accept shorts instead of char's: pdp at least uses shorts for it's yv12...
jamie
ps: looking at the cvs commits, Iohannes first started working on this in may of 2003! Sorry it's taken me so long to see it as a problem ;-)