[PD] processing images with GEM?
IOhannes m zmoelnig
zmoelnig at iem.at
Mon Jan 21 16:07:16 CET 2008
matteo sisti sette wrote:
>> I don't have a camera to plug in and double check, but I never noticed
>> this inverted problem before. You can always re-invert the numbers if
>> you need to ;-)
> Yes of course it is stright-forward to correct the inversion.
> But I was wondering if there may be some weird platform-dependence in
> the involved objects that may cause the y coordinate to work in one
> sense or the other in different computers/os's??
> Because it would be really really strange that it were just an error
> in the patch and you never noticed before - I mean the cursor moves
> down when the object moves up, and you mention having used it in
> workshops for years.
> I was just curious if it may be some platform or version dependency.
the problem is, that some pix-sources (platform dependent!) supply the
images with (0/0) in the upper-left corner, whereas others (0/0) is the
lower-left corner (like openGL expects it).
for performance reasons, Gem does not put the images "right" when it
retrieves them, but tries to flip the image on the texture, once they
are uploaded. this often makes things behave weird (e.g. mixing 2 images
will make one of them upside-down, even though the look "normal" when
so, sometimes the upside-downness is not respected by certain
pix_objects (it seems like [pix_blob] is one of them), this is a bug and
should be fixed.
finally, i am wondering how much the penalty would be to manually flip
the images when retrieving them (this would involve one additional copy
of the entire image, each time it is pulled from the source) - this will
just magically fix a lot of weirdness...
More information about the Pd-list