[GEM-dev] [ pd-gem-Bugs-3191771 ] pix_movement treats a duplicate frame as black in Mac OS

[SourceForge.net]

Bugs item #3191771, was opened at 2011-02-24 16:32
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3191771&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: osx
>Status: Closed
Resolution: Duplicate
Priority: 6
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_movement treats a duplicate frame as black in Mac OS

Initial Comment:
Consider:

[pix_video]
 |
[pix_movement]

Expected behavior: When pix_video produces a duplicate frame (i.e. doesn't grab a new frame), one may expect any of these two:
A - (best) pix_movement won't generate a new image
B - (acceptable) pix_movement will generate a black image since it's comparing two identical frames (actually the same frame)

Observed behavior in Linux:
- I'm almost sure it's A

Observed behavior in Mac OS:
- pix_movement treats the duplicate frame as if it was a black frame; so it will compare the current frame with a completely black frame, outputting an image with a lot of "false movement".

Not sure about Windows, I seem to remember it works fine just like in Linux; or it may be behavior B; surely not like Mac OS.

This has been known for a long time but I couldn't find it in the bug tracker and it is not fixed, so I thought I would report it.

Note that it is not just a matter of failing to detect that the new frame hasn't been grabbed. That would explain behavior B described above, flickering to black. What's happening is much wronger: duplicate frames are treated as black frames which causes the output to flicker to almost-white.

----------------------------------------------------------------------

Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-08-16 05:53

Message:
actually, what i've written above (below?) is wrong, the YUV handling is
fine (apart from weird behaviour, that it leaves color information intact
which gives you "ghost images" in the no-movement zone)

the real issue is, that the pix-manipulation is done in-place in that the
"newimage" flag is not properly set.
this makes it a dupe of #1939029, #2519970
and can be solved by inserting a [pix_separator] object after the
[pix_video].

https://sourceforge.net/tracker/?func=detail&aid=1939029&group_id=64325&atid=507079
https://sourceforge.net/tracker/?func=detail&aid=2519970&group_id=64325&atid=507079

----------------------------------------------------------------------

Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-07-21 09:25

Message:
ack.

the problem seems to be only the YUV handling, so a quick fix is to switch
the colorspace e.g. by using [pix_grey] just before [pix_movement]

----------------------------------------------------------------------

Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-05 04:51

Message:
I'm raising priority as this renders pix_movement almost useless in Mac OS,
and it is a pretty basic object. Hope this is ok

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3191771&group_id=64325