[Pierre Jasmin]

For those who keeps the score:

I reported the following bug to Premiere 4.0.0
“If you trim the begining of a clip in your edit timeline, then Premiere CS4.0.0 returns the wrong current time value to plug-in. There are workarounds, for Twixtor since often you need anyway to create a new sequence if you want to make the sequence longer, you simply need for now to make the in-point edit inside the nested sequence. Hopefully it will be fixed in 4.0.1 dot release”

Pierre

[Pierre Jasmin]

For those who keeps the score:

I reported the following bug to Premiere 4.0.0
“If you trim the begining of a clip in your edit timeline, then Premiere CS4.0.0 returns the wrong current time value to plug-in. There are workarounds, for Twixtor since often you need anyway to create a new sequence if you want to make the sequence longer, you simply need for now to make the in-point edit inside the nested sequence. Hopefully it will be fixed in 4.0.1 dot release”

Pierre

[Pierre Jasmin]

Crap!… Quick test and looks worst then what you describe actually, as in “new last second bug in Premiere CS4″… let me see what I can do this week (if I can actually lie to Premiere so it returns the proper values). That said, do you see this with Quicktime movies, AVI or what (with fields, no fields) – so I can test all cases…

Pierre

[Pierre Jasmin]

Crap!… Quick test and looks worst then what you describe actually, as in “new last second bug in Premiere CS4″… let me see what I can do this week (if I can actually lie to Premiere so it returns the proper values). That said, do you see this with Quicktime movies, AVI or what (with fields, no fields) – so I can test all cases…

Pierre

[Pierre Jasmin]

Assuming you have the latest version:

1) I just tried it in CS3 and not able to recreate
2) Is this something you see in CS3 as well?
Either way maybe send us a premiere project at techsupport@revisionfx.com

Pierre

[Pierre Jasmin]

Assuming you have the latest version:

1) I just tried it in CS3 and not able to recreate
2) Is this something you see in CS3 as well?
Either way maybe send us a premiere project at techsupport@revisionfx.com

Pierre

[Pierre Jasmin]

For the most part yes.
One can always invent an image sequence which will fail, for example fast moving in all directions tiny black dots on a white background, … or special problems like helicopter blades which have subsampling problem by definition at standard frame rates…

The worst I have seen in the near impossible category was a bunch of acrobatic extreme bicycle bunched together so you can see through the bicyle wheels other stuff moving. Trying to roto the inside of a bicyle wheel might be an unhuman task.

Pierre

[Pierre Jasmin]

For the most part yes.
One can always invent an image sequence which will fail, for example fast moving in all directions tiny black dots on a white background, … or special problems like helicopter blades which have subsampling problem by definition at standard frame rates…

The worst I have seen in the near impossible category was a bunch of acrobatic extreme bicycle bunched together so you can see through the bicyle wheels other stuff moving. Trying to roto the inside of a bicyle wheel might be an unhuman task.

Pierre

[Pierre Jasmin]

The most common limit in terms of an automatic process for this technology at large (not just us) comes from having part of a shot that goes one way and another region that goes the other way and under the other, which is not uncommon when you have camera motion combined with some action. It is a problem because at some point from a frame to another you end up with large occlusions — areas of the image that are visible in a frame but not in the next one…

If you need a rule of thumb which is 90% of the time right, that would be if a pixel travels more then 5% of an image size on a frame then you are in potential trouble zone and that’s when typically the “guidance” methods we offer such as: input of mattes separating “layers” of motion basically, and the input of point tracking data (for example will help large pans) and rotosplines (for example to disambiguate for Twixtor edges of a rotating object) become your friend if you are willing to spend the time doing it.

Pierre

[Pierre Jasmin]

The most common limit in terms of an automatic process for this technology at large (not just us) comes from having part of a shot that goes one way and another region that goes the other way and under the other, which is not uncommon when you have camera motion combined with some action. It is a problem because at some point from a frame to another you end up with large occlusions — areas of the image that are visible in a frame but not in the next one…

If you need a rule of thumb which is 90% of the time right, that would be if a pixel travels more then 5% of an image size on a frame then you are in potential trouble zone and that’s when typically the “guidance” methods we offer such as: input of mattes separating “layers” of motion basically, and the input of point tracking data (for example will help large pans) and rotosplines (for example to disambiguate for Twixtor edges of a rotating object) become your friend if you are willing to spend the time doing it.

Pierre