[GEM-dev] [ pd-gem-Bugs-2972166 ] pix_crop, pix_resize don't "refresh" when they should
SourceForge.net
noreply at sourceforge.net
Fri May 7 10:51:35 CEST 2010
Bugs item #2972166, was opened at 2010-03-17 21:12
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_id=64325
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_crop, pix_resize don't "refresh" when they should
Initial Comment:
If you use a pix_crop on a pix_film:
[pix_film]
|
[pix_crop]
when [pix_film] has auto off, if you send floats into any of [pix_crop]'s inlets, the texture won't change accordingly until you move to another frame in [pix_film] (i.e. send a number to its right inlet or enable auto mode)
I don't know whether this is an issue with pix_film or pix_crop.
This does not happen with [pix_image] in conjunction with pix_crop, so it's probably pix_film.
Then [pix_resize] has a similar issue:
if you have:
[pix_film]
|
[pix_resize]
OR
[pix_image]
|
[pix_resize]
when you send a [dimen( message to pix_resize to change the target size, it won't change until the input pix changes. In the case of pix_film it won't change until the frame changes; in the case of pix_image it won't change until you load another image!!!!!!!
This seems somewhat similar to what happens with [pix_crop], however in this case it does apply to [pix_image] too, so it would suggest an issue in [pix_resize] rather than [pix_film] or [pix_image].
I haven't done intensive testing, so it may apply to more pix objects. I don't even know if the problem may be in [pix_texture].
I attach a simple test patch for convenience. You'll need a myimage.jpg image file and a myvideo.mov movie file.
And now a nastier thing, possibly related:
1) Open the attached patch, create the gemwin and click on the open messages to [pix_film]s
You see the four images, twice the image and twice the video
2) Disconnect the upper [pix_image] and [pix_film] objects both from their input and output
3) move the [pix_film] on the right to the render chain on the left and connect it
You would expect the video to appear but no: the jpeg image reappears, though the [pix_image] is even disconnected!!!!
This is probably the same bug described above.
Try all the viceversa's
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2010-05-07 10:51
Message:
you can use [pix_separator] to workarund.
fgmasdr
IOhannes
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2010-03-17 23:18
Message:
With pix_film, if you have to change a crop or resize of the image while
not changing the frame, even sending the same frame number again won't
work: the cropped or resized image won't be refreshed until pix_film
actually goes to a different frame. So it is not "workaroundable"
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=2972166&group_id=64325
More information about the GEM-dev
mailing list