PDA

View Full Version : annoyance/bug should be fixed in 2.5..



jakob
03-15-2003, 07:27 AM
Greetings,

I found an annoyance/bug in 2.5 that should be fixed, please.
This same thing was true in Aura 1.0, fixed in 2.0, now it's
back in 2.5.

This is hard to explain, so bear with me. I'll try to be brief, too.
After loading (in fields) a video file, in 2.5.
Notice how the image goes "up and down", as you step through, field by field?
It should NOT do this.

While working , if you were to slide stuff around, till some it
were going "down and up", instead of "up and down"... then export
to interlaced video, you've got a visual problem.
You've got jaggies, and an apparent lowering of resolution.

This is not true in 2.0. Do the same thing in 2.0 and the fields
*do not* go up and down.

Hope that's understandable.

later,
ed

paulfierlinger
03-15-2003, 09:25 AM
ed,
I have a question to you in connection with this. When you playback an animation with the project window set at 75%, do you see a loss of antialiasing? Does anybody see this?

Paul F.

jakob
03-15-2003, 12:39 PM
Originally posted by paulfierlinger
ed,
I have a question to you in connection with this. When you playback an animation with the project window set at 75%, do you see a loss of antialiasing? Does anybody see this?

Paul F.

I think that's a function of the proxy rendering.
I can see the rez drop when the window is set to any % .
Just click on the "remote control" slider and watch the rez drop.

I don't think this has anything to do with the problem
I stated above.

paulfierlinger
03-15-2003, 12:53 PM
Well, that's when I see the slight shift up or down in the frame. At 100 % all is fine. This started only after a certain period -- I don't know exactly when and so far it has baffled the developers. It seems that it might have more to do with windows than Aura. My wife had it doing that on her computer for a while and then it just didn't happen any more -- same for dhomas trenn and a couple of other people.

Paul F.

paulfierlinger
03-15-2003, 12:54 PM
Oh, I forgot, it has nothing to do with proxy, which I don't use.
PF

jakob
03-15-2003, 01:18 PM
Oh, so it ends up on the final product does it?
I assumed just the preview, or...?

My problem ends up on the final output.

paulfierlinger
03-15-2003, 01:24 PM
No, in my case it shows only in the preview and only by remote control. When I scrub on the timeline it doesn't show up at all.
PF

jakob
03-16-2003, 08:58 AM
I guess I thought I might get a response from someone from newtek.. Paul??

I'd upload a couple of still frame examples...... but I don't know where??

Anyone, try this:
In 2.5, load (in fields) a video file,
In the timeline, slide the entire video to the right, one field.
Now "stretch" the video one field to the left, (use repeat)
Essentially you're increasing the length by one field.

Save it (interlaced), then compare it to the original.

I think you'd see a difference if you use a Toaster or not.

Someone, try it please.. tell me what *you* see..

sierra
03-16-2003, 09:45 AM
I think my problem may be along these lines so here goes.

I made a project that was not fielded. It is a scene that scrolls for many frames. When the scroll plays back in Aura, it looks just fine. When I take it into Premiere, the trees in the scrolling scene jitter like crazy, so do the clouds, so do the bushes and the hills against the sky (these are hand drawn frames, not video).

Is the problem that I should field the project? Does it matter if I do odd or even for Premiere?

A second question while I'm within eyeshot of Paul...

I'm convinced I need a Video Toaster to put out my animations for video and TV. (short animated children's poems 2-5 minutes each). My husband thinks I may be able to get by with the new Premiere which we now have. I admire your stuff. More than that I admire the spirit of your work. (Your Public TV show was wonderful Maggie Roars). My question: do you and Sandra use VT?

Third question for anyone--I used to get e-mails from this forum. No longer. Was it discontinued? Thanks so much. Sierra

paulfierlinger
03-16-2003, 10:23 AM
sierra,
it sounds like you need to field your pans. For NTSC it's ODD. The problem is that Aura doesn't do this too well yet. Either you have to open your project as ODD fielding and proceed to draw and paint twice the amount of pictures (nonsense, really), or draw in a FRAME project and when finished, field it. The way to do that is to save out your entire pan (scroll) scene as a picture sequence (the best is to create first a folder to hold these) and then open a new project window as odd fielded. Under file go to import /Sequence and load it as Odd first and PreLoad. You'll see that your timeline now shows two frames for each frame number. Then proceed to render these into Premier the way you'd render anything else. If you still see a bit of shimmering, you must start over again but experiment with MB (motion blur) on your KeyFramer at the same time as you create the camera pan. If there is still shimmering, change your drawings. It takes a lot of trial and error at the beginning but once you discover the best settings for your style, you can stick to it. Aura 3 will surely have this improved.

No, we don't use VT, although I now wish we did own it -- we use DPS/Velocity (also very professional), but I understand that for our kind of work Premier is just as good, provided that you have a decent video card.

I'm sorry we're doing this to Jakob's thread -- if we are going to continue, perhaps we should start a new thread under Fielding or something like that. Thanks for your kind words about the Maggie animation.

Paul F.

sierra
03-16-2003, 10:55 AM
Thanks a million, Paul.

Sorry Jakob. I'll try Paul's ideas then start a new thread on fielding.

Sierra

edmellnik
03-16-2003, 05:13 PM
I have been fighting with this too. I load a clip in frames.
when I save, it looks like it has changed the order of the fields.

Cant figure it out.

THe older auras were much more straight forward and did not have this problem.
Please Newtek - FIX this.

ed :(

jakob
03-17-2003, 07:13 AM
Originally posted by sierra
Thanks a million, Paul.

Sorry Jakob. I'll try Paul's ideas then start a new thread on fielding.

Sierra
No problem, start a thread and I'll be happy to join you there..

In the mean time, I plan on keeping this thread near the top.

I don't want anyone to think my problem merely the fielding being out of order,
which is a *temporal* problem.
I know what that is, and I know what it looks like.
It is not the problem I describe above,
which is a *positional* problem.

Here's one more description:
The fields are out of register... positionaly.[sic?]

thx,
ed

SBowie
03-17-2003, 07:27 AM
Originally posted by jakob

After loading (in fields) a video file, in 2.5. Notice how the image goes "up and down", as you step through, field by field?
It should NOT do this. Wow- this is a complex and wide-ranging thread. I'll try to add a few remarks...

Really, I think it *should* " go "up and down", Ed. Successive images displayed along the timeline represent variously odd or even fields, and in the normal course of events one of these would be drawn from part of the image which is 'higher' than the next, in alternating fashion.


Originally posted by jakob

This is not true in 2.0. Do the same thing in 2.0 and the fields
*do not* go up and down. Field handling has varied in different versions - really enough to get a little confusing trying to keep them all straight. But I don't find any problems with the current usage. Now, this may be masked by the fact that I ordinarily work with RTV's (which actually behave slightly differently on saving than do AVI's and other file formats). Still, though I have noticed what I think is a problem with saved AVI's in 2.5b, it is not a field issue.

jakob
03-17-2003, 07:59 AM
Originally posted by SBowie

Really, I think it *should* " go "up and down", Ed. Successive images displayed along the timeline represent variously odd or even fields, and in the normal course of events one of these would be drawn from part of the image which is 'higher' than the next, in alternating fashion.


Yes I agree they should go up and down, but *only* when it's
saved as an interlaced video clip.

NOT, when it's on the timeline, to be worked on...
This worked properly in 2.0!



Originally posted by SBowie
I think[/I] is a problem with saved AVI's in 2.5b, it is not a field issue.

This is a problem for anyone that works with video, rtv or not. Anything interlaced...

ed

SBowie
03-17-2003, 09:13 AM
Originally posted by jakob
Yes I agree they should go up and down, but *only* when it's
saved as an interlaced video clip. NOT, when it's on the timeline, to be worked on... This worked properly in 2.0!
ed Why not? Each successive field on Aura's timeline (in a fileded project) represents variously the odd or even field info (stretched x2 on Y) from the original. So, for example, if I had a mythical lense of sufficient quality, and shot a still image of a brick wall 480 bricks high, the first field on my timeline would show the topmost brick (stretched vertically X2) as the first two pixels at the top of the Y axis. The second field on the timeline would show the second brick from the top occupying the same two pixels (0 and 1). If I scrub through these two frames on the timeline, naturally there will be apparent motion.

I'm truly not trying to dismiss your question, Ed, just to understand it and clarify how Aura is handling things. I have to run out just now, but will try to pursue it further a bit later. If it's any comfort, I have no trouble at all importing or exporting any fielded format with silky smooth playback in 2.5b. More in a bit .... (I want to deal with your "offest video by one field" question also in this thread.)

SBowie
03-17-2003, 12:15 PM
Originally posted by jakob

I don't want anyone to think my problem merely the fielding being out of order, which is a *temporal* problem. I know what that is, and I know what it looks like. It is not the problem I describe above, which is a *positional* problem. I agree, exactly. Here's my attempt to explain what you're seeing.

Having moved the imported fields (on the Aura timeline) one frame to the right, you have not altered the field order as far as playback goes when you export the file. The fields are still in the same sequence, and you will not get the "flashing" typical of a file with the fields reversed. What you will see, though, is a 1 video line (Y axis) shift, which results in a relatively subtle (compared to flipped fields) comb effect.

Let's take an example. You import a short DV sequence into a 720x480 even project. Then you shift it one field to the right along the Aura timeline, substituting something else at the outset to make up for it (and cutting one field at the end to retain an even number of fields.)

What has just happened, and how will it affect your exported video?

Before the shift, the image data from line 0 (frame 1) of your source material was displayed (stretched vertically X 2) at the uppermost scanline line of position 0.0 (an even field) on the Aura timeline. When you moved it laterally (by 1 field's duration) things changed.

Consider each field, video line by video line. When you export after this shift, the data which previously appeared at line 0 of your source video *now* appears at line 1, part of the odd field of frame 1. The original info from line 1 (the second line) of the source frame 1 (which on import -- before the shift -- appeared as the top line of position 0.1 on Aura's timeline) is now the top line of position 1.0 on Aura's timeline, and on export will provide the image data for line 0 of frame 2 in the output.

Although this sounds very much like a field-order issue to describe, it's different. The best way I can state it is that the sequence of fields is still correct order, but being off 1 field laterally results in an unwanted Y-dimension displacement of each single video line on playback -- the nefarious comb effect I mentioned earlier... not as exaggerated as a field-order issue but still quite annoying. In a field-order error, the fields play back in the wrong sequence. In this case, they are play back in the wrong place on the screen.

Gee this is hard to explain. You're correct, it's "spatial", not temporal. In any case, a simple way to bypass the issue is to perform any necessary shifts in even numbers of fields.

jakob
03-17-2003, 12:31 PM
>Why not?
(excellent description deleted)


>I'm truly not trying to dismiss your question, Ed, just to understand
>it and clarify how Aura is handling things.

No problem. I want things clarified, too.
How would you explain the difference between 2.0 and 2.5?

<snip>


>(I want to deal with your "offset video by one field" question also
>in this thread.)

It's actually the same question/issue.

I am going to attempt to attach an image with two brushes below,
for an example.
Both brushes are from an interlaced *still* frame.
The top one is "normal", the lower is "offset" by one field.

See the difference? It's very dramatic on an interlaced screen.

All I'm saying is if you are sliding video down the timeline
to create a transition or whatever. You have a 50/50 chance
of landing on the wrong field an getting the results shown.
Of course, this shimmering effect will vary depending on
the original source.
So sometimes it's not as apparent as others, but it's there.


You replied before I completed my response:
>Gee this is hard to explain. You're correct, it's "spatial", not
>temporal. In any case, a simple way to bypass the issue is to
>perform any necessary shifts in even numbers of fields.

Good, you see it, you explained it.
Now I'd like it fixed.
Why should I have to worry if my video clip lands on an
even or odd field?

This problem was fixed in 2.0, now it needs to be fixed in 2.5.

thx,
ed

SBowie
03-17-2003, 01:08 PM
Originally posted by jakob
>How would you explain the difference between 2.0 and 2.5? One half? Sorry, just kidding. TBH, it's so long since I used 2.0 -- I know field-handling has changed several times in recent years -- I just don't recall how it was done earlier.


Originally posted by jakob

I am going to attempt to attach an image with two brushes below, for an example. Yeah, that's it - I knew exactly what you meant.


Originally posted by jakob

Of course, this shimmering effect will vary depending on
the original source. So sometimes it's not as apparent as others, but it's there. You're right, it is, and also that with certain combinations it seems more evident.


Originally posted by jakob

You replied before I completed my response:[/i]

Sorry. I..'..m t..y..p..i..n..g r..e..a..l..l..y s..l..o..w n..o..w :D


Originally posted by jakob

Good, you see it, you explained it. Now I'd like it fixed.
Why should I have to worry if my video clip lands on an
even or odd field?

This problem was fixed in 2.0, now it needs to be fixed in 2.5.

Are you sure it wasn't doing this in 2.0, too? I can remember puzzling over this problem myself in a LW compositing I did I did eons ago. I'm not saying I can't think of a way to circumvent it ('cos I think I can), but I'm not the guy to fix it. (And I had such a hard time explaining it that I'm not sure my "solution" would work anyway!) Anyhow, you sure gave my brain a workout today! In the meantime, do your changes to layers in pairs, whether stretching, trimming, sliding, whatever, and you'll have no issues.

jakob
03-17-2003, 02:54 PM
Originally posted by SBowie


Are you sure it wasn't doing this in 2.0, too? I can remember puzzling over this problem myself in a LW compositing I did I did eons ago. I'm not saying I can't think of a way to circumvent it ('cos I think I can), but I'm not the guy to fix it. (And I had such a hard time explaining it that I'm not sure my "solution" would work anyway!) Anyhow, you sure gave my brain a workout today! In the meantime, do your changes to layers in pairs, whether stretching, trimming, sliding, whatever, and you'll have no issues.

I'm absolutely sure about 2.0..
You and I had this same disscusion, only about 1.0... way back when
Then, 2.0 came out and it was a moot point...

I know you can't fix it. but I'm hoping someone at Newtek will acknowlege the problem and put it in the "things to fix" list.

I'm just happy that someone else sees' it ,too.

Thanks Steve..

later,
ed

edmellnik
03-20-2003, 05:43 PM
This is rediculous.
Aura is unusable if you cant import a video clip and save it back as an RTV without this strobing effect.

Ed

SBowie
03-21-2003, 07:43 AM
Of course you can. For starters, if you're working with frames rather than a fielded project, there is no issue whatsoever.

(Many use fielded modes unneccesarily, since lot's of things don't require it. This has the effect of doubling the amount of processing time for no reason.)

When working with a fielded project, if you don't screw up the field order by offsetting segments by odd numbers you'll have no problem. It would be nice to see this addressed, but it's a significant overstatement to say it makes Aura "unusable."

jakob
03-21-2003, 08:09 AM
Originally posted by edmellnik
This is rediculous.
Aura is unusable if you cant import a video clip and save it back as an RTV without this strobing effect.

Ed

Well, I wouldn't say it's unusable... :)

But, something should be done to make results more predictable.
Our friends a Newtek need to do one of two things.

Revert to the way the fields were handled in 2.0.
or
Add a "Frame Snap" so that you could only move clips in
full frame (two field) increments.

"Increase Layer Length" should "snap" also.

In the mean time, be careful......
and you know where to look, if you get "un-explained" jitter.

later,
ed

SBowie
03-21-2003, 08:57 AM
Originally posted by jakob

Our friends a Newtek need to do one of two things.

Revert to the way the fields were handled in 2.0....
Can you refresh my memory on how that worked?

(I'm down a few 1000 PPM on my caffeine levels at the moment :-p)

jakob
03-21-2003, 09:08 AM
Originally posted by SBowie
Can you refresh my memory on how that worked?

(I'm down a few 1000 PPM on my caffeine levels at the moment :-p)

Simple.
When fields were loaded, they were loaded at the same verticle level.
IOW, your image did not go "up and down" when single stepping through the fields.

edmellnik
03-21-2003, 11:09 AM
I am not working with fields. I am just trying to load frames from an RTV clip and then save it as an RTV clip and all I get is a strobey effect.
ed

SBowie
03-21-2003, 12:13 PM
Originally posted by edmellnik
I am not working with fields. I am just trying to load frames from an RTV clip and then save it as an RTV clip and all I get is a strobey effect.
ed Aura is clearly capable of doing this. Please let us know your :

- RTV type (Toaster 1 - 480 lines, or Toaster 2, 486 lines)

- Aura Project mode

- operations performed within Aura (surely you're not simply loading RTVs and re-saving them as RTV's for fun :)

edmellnik
03-21-2003, 12:33 PM
I am using 720 by 480 rtv clips,
Project is set to none, but have tried all combos,
Importing as frames, touching up a few dropout spots on bad frames and resaving as a 720 by 480 RTV.
ed

SBowie
03-21-2003, 02:56 PM
Originally posted by edmellnik
I am using 720 by 480 rtv clips,
Project is set to none, but have tried all combos,
Importing as frames, touching up a few dropout spots on bad frames and resaving as a 720 by 480 RTV.
ed So you are using the older, T[2] format clips? Or were these from DV? In any case, here you go - the following all seem to work correctly:

To import 480 line EVEN field to a '480 NONE' project: in the Import Sequence popup panel, select "Full Frame".

To import 480 line EVEN field to a '486 NONE' project: in the Import Sequence popup panel, use Full Frame, 480 lines (Even) to 486 lines.

If you would prefer to load into a fielded mode, and would like to to conform your RTV's to T[2]-style 486 line usage: use a D1 (720x486 ODD) Aura project mode, and when importing the 480 EVEN footage use the ODD First, 480 lines (Even) to 486 lines options.

edmellnik
03-21-2003, 03:24 PM
I am not sure what you are getting at.
I have captured footage with T2 at 480 to make it DVD compatible. I load (or Input sequence) in Aura as frames into
a project that is set to NONE.
I save the clip.
It is strobed.

VT Aura should be able to work with VT clips.
480 or 486 should not make a difference unless I am missing something.
ed

SBowie
03-21-2003, 04:17 PM
Originally posted by edmellnik

VT Aura should be able to work with VT clips. Yep, but I think I see the problem here.


Originally posted by edmellnik

480 or 486 should not make a difference unless I am missing something.
ed It can make lots of differences, depending on what you are doing.

The 486 line files are normally odd-first, while 480's are generally even first - excluding progressive modes, of course. Still, as you point out, since you are simply loading and saving it shouldn't matter, but then we didn't know that before (you might have been loading 480's into a 486 project, for example.)

However, I have been playing with this trying to duplicate your problem (since I had already tried loading and saving the older '480 line EVEN first' RTV's without issue) and discovered something interesting....

AFAICS, NONE of the 480 line record options in the Capture panel are actually recording 480! Almost every one I tried, including progressive and laced RTVs, as well as M-JPEG, actually saved at 486, not 480. The only exception was DV. I've little doubt this is related to your troubles, but will have to play with it a bit further to figure out what's happening and decipher a workaround for now.

BTW, were you capturing as Progressive, or Laced for your DVD purposes?

edmellnik
03-21-2003, 05:30 PM
I was capturing 480i.....
but now that you mention it I did notice that when I load it into Aura that it said it was a 486i....

I think I was planning to ask newtek if this was a AUra bug....
but if I have been capturing all along in 486i .....
and saving in 480i Maybe thats the problem.

I was not aware that 486 was odd first and 480 even.
In any case since it is all supposedly one integrated system you would think I would not have such a hard time.

I guess the question is....when I capture at 480i - am I capturing really at 480i an if so which field is first.
and if I am really capturing at 486 when I chose 480 - is the fielding different?

OR
Is Aura reading it wrong.

Never had this problem with 1.0.and by the way, thanks for your time on this.

ed

SBowie
03-21-2003, 07:20 PM
Originally posted by edmellnik

but if I have been capturing all along in 486i .....
and saving in 480i Maybe thats the problem. My tests indicate it's certainly part of it. It's deceptively complex when you start to examine it.


Originally posted by edmellnik
I was not aware that 486 was odd first and 480 even. In any case since it is all supposedly one integrated system you would think I would not have such a hard time. ed Agreed. It's wonky, no doubt. The question is, is it Aura or the Toaster, or just a disagreement between the two. More below.


Originally posted by edmellnik

I guess the question is....when I capture at 480i - am I capturing really at 480i an if so which field is first.
and if I am really capturing at 486 when I chose 480 - is the fielding different?

OR

Is Aura reading it wrong.Strange as it may seem, at one time Aura did report 480 files as 486 - by design! This was changed awhile back. Hmmm...

Anyway, no, it really appears that although you set Capture to 480, it's grabbing 486 in some formats. I think some of the problem can be attributed to the change in RTV formats betwen T1 and 2, but like I said, it's surprisingly complex. Actually, that'll be another avenue to check out -- I bet capturing in a mode that does provide a real 480 would sidestep the problem.

Do, as I suspect, the core Toaster modules assume all 480 line files to be even first? The 486's that are grabbed even when you select a 480 mode for RTV are definitely odd first. Load those into a '480 None' Aura project, save, and send 'em back to a DDR, lo and behold it plays them with flipped fields.

If you load them into an 'even' Aura project , then save, you wind up with one of two problems - flipped fields if loaded as Odd first, or the odd comb effect discussed elswhere in this thread if loaded as Even first...

I'm going to spend some more time on this, but not tonight :-p

SBowie
03-22-2003, 06:58 PM
OK, after hours of effort, I figured out WHAT it's doing when swapping from 480/486 ODD to 480 EVEN and how to repair the output file so it plays perfectly ... now I just need to figure out why :-p

(When I get right down to bedrock I'll type it all out.)

jakob
04-01-2003, 09:32 AM
Originally posted by SBowie
OK, after hours of effort, I figured out WHAT it's doing when swapping from 480/486 ODD to 480 EVEN and how to repair the output file so it plays perfectly ... now I just need to figure out why :-p

(When I get right down to bedrock I'll type it all out.)
I look forward to reading it...:)
I'd like to add one more aspect to this problem.

Let's assume we're working with 2.5 in T[2] mode... odd first.
Load a T[1] RTV, or Flyer clip, they're both even first.
Save out a RTV. Plays fine in T[2], field order is correct.

Although it WILL have the visual aberration described earlier in this thread.

Throw it in project with other T[2] footage.
Render out a single DV file.
(actually , any interlaced format will do)
Or a single RTV for TMPEnc.
From TMPEnc render a mpeg2, and burn a DVD.

You will now find, the single shot that was run through Aura 2.5 will
play in the wrong order.... in the DV file and the DVD.

I was working on a graphic sampler hat was a mix of
Flyer, T[1}, and T[2] files.
Man, I had a hell of a time trying to figure out why the fields would flip in the middle of a single RTV.
Please note, I know how to keep that from happening, NOW.
But I shouldn't, and other users shouldn't have to....

NewTek, please fix.


later,
ed