Bugs item #3191771, was opened at 2011-02-25 01:32 Message generated for change (Comment added) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3191771...

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: Pending 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 14: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=64... https://sourceforge.net/tracker/?func=detail&aid=2519970&group_id=64...

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

Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-07-21 18: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 13: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...