[GEM-dev] gempixutils.cpp questions/confusion

james tittle tigital at mac.com
Sat Dec 18 00:15:50 CET 2004


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 ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1885 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20041217/a297757a/attachment.bin>


More information about the GEM-dev mailing list