[GEM-dev] gempixutils.cpp questions/confusion

[Johannes M Zmoelnig]

james tittle wrote:
> heya,
> 
> ...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...

no.
it works perfectly but you have to know, that "image" is the 
destination, whereas the data passed to the "from"-function is the 
source (thus the naming)

fromUYVY(uchar*pt) means: take the data that is stored at "pt" and 
convert+copy it into the image's "data".
this means: "pt" must not be "data" but it should be an memory that is 
allocated by someone else.

the only weak point is: the image-dimension cannot be stored in "pt", so 
we have to provide it somehow else: i chose the xsize+ysize-fields in 
imageStruct, as we are not doing resizing (yet) and it makes the lines 
shorter.
i admit that this is bad practice.


but from scratch:
suppose you have image-data of dimension "w h", stored as YUV420P (which 
is YV12 in fourc) at destination "*p", but you want it to be RGBA.
what you first do is set-up your destination "image":
<snip>
image.xsize=w;
image.ysize=h;
image.setCsizeByFormat(GL_RGBA);
</snip>
then you convert the "raw"-data ("p") into the destination-image with 
image.fromYV12(p);


> 
> ...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...?

i think i've set the default to RGBA (or BGRA this is) to make sure i 
reserve a bit more memory, just in case....

> 
> ...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?

is it clearer now (i was interrupted when writing the part above and 
don't want to re-read it...) ???


> 
> ...or perhaps this is a huge hiccup from trying to have different 
> default colorspaces on different platforms?

actually it shouldn't be to much of a problem (apart from the RGBA vs 
BGRA thing)

> 
> ...also, imageStruct.fromYV12 should probably accept shorts instead of 
> char's:  pdp at least uses shorts for it's yv12...

this what we have overloading for !!!!
just make another(!) class-member fromYV12 that takes shorts instead of 
uchars (i mean, just because of pdp i don't want to break a consistency; 
fromYV12(uchar) is already used on linux to decode some movies


> 
> 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 ;-)

oh it's just fine....

mfg.a.sdr
IOhannes