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