Converting animation to progressive

[Daniel Low]

Just to throw another possible spanner in the works:

720×480 & 720×486 are generally regarded as non-square pixel frame sizes. The Animation codec is however a square pixel codec, as such the corresponding frame size should really be 640×480 (for 4:3) not 720×480

__________________________________________________________________
Please post back saying what solved your problem. It could help others, and saying ‘thanks’ is free!

[Paul Campbell]

Daniel, won’t I need to seriously scale the animation up if it’s only 640×480 in my 720×480 timeline? Or am I just not getting the jist of your reply here?

[Daniel Low]

You are missing something if you don’t appreciate the difference between square and non-square pixels.

Computers do square pixels, digital video does non-square pixels.

So in order to create an animation on a computer for delivery to digital video, one would render out as 640×480 square pixel and transcode to the digital video format that is at 720×480 non-square (For NTSC), not scaling, just resampling both are 4:3. (For PAL it’s 768×576 square to 720×576 non-square)

Failure to follow this rule will result in circles becoming ovals and squares becoming rectangles.

Without a detailed run-through of your workflow for all your material, it’s impossible to determine where you’re at.

__________________________________________________________________
Please post back saying what solved your problem. It could help others, and saying ‘thanks’ is free!

[Chris Blair]

Paul,

Yes…although this is the reverse of my example, the same thing would occur. Your fields would get reversed. So try swapping the field order (if that’s possible within Final Cut or Compressor) and see what just the 60i looks like. If it looks decent, THEN do your conversion to progressive.

Another workflow suggestion would be to transcode your file to your desired Final Cut codec and in doing so change the pixel size to 720×486, reverse fields and use an interlaced to progressive plug-in. This in theory would fix the jerky motion problem caused by reversed fields, and give you the progressive look you’re going for.

We get high-end SD animation done all the time by a guy that’s really good up near Chicago, and he sends us Quicktimes using the animation codec at 720×486, and they look just fine when imported into our editing system with no change to pixel aspect or resizing of the frame. I do some basic 3D stuff in trueSpace, and just to check I called up it’s quicktime output dialogue. There’s a check box to adjust the pixel aspect for square, rectangular and widescreen even if I select the animation codec.

So perhaps your animatator has already made this adjustment prior to rendering. I also know that Avid has the pixel aspect options using the animation codec with Quicktime export or output.

Hope you get if figured out.

Chris Blair
Magnetic Image, Inc.
Evansville, IN
http://www.videomi.com

[Paul Campbell]

I do understand the difference…I’m just having a bad day I guess. Thanks for the replies. I’ll let you know how it goes.

[Brian Alexander]

It would help if you could throw a 5 second clip online so we can take a look at what you’re seeing.

Also, I apologize if I missed it somewhere but I still didn’t see a solid answer here:

Where did this original animation come from? Was it ingested from a tape source or do you have the original files?
and
What’s the frame rate of the original animation? 29.97, 30, 59.94 or 60?

Is it possible that someone has created a progressive frame without properly de-interlacing the material? Correct me if I’m wrong but you would never be able to de-interlace the video if this were a progressive video frame displaying interlaced media.

Good luck.

[Daniel Low]

Hey Chris

“I do some basic 3D stuff in trueSpace, and just to check I called up it’s quicktime output dialogue. There’s a check box to adjust the pixel aspect for square, rectangular and widescreen even if I select the animation codec. ”

That’s interesting, can you check the box for square pixels if you render out to a DV codec – DV25 for example?

__________________________________________________________________
Please post back saying what solved your problem. It could help others, and saying ‘thanks’ is free!

[Paul Campbell]

Brian (and all), sorry for not being completely forthcoming with my info. I shall tell you everything I know about the origin of the clips:

-Originally delivered to us on a data DVD by a graphic artist (That’s all I know about this part. We simply had files delivered to us on disk. I don’t know what application(s) was used to create them, nor do I know the guy personally. This was farmed out prior to my involvement)

All properties info on the clips comes from pulling up properties in Final Cut Pro, which are:

720×486
Animation codec
Lower field dominance
Frame rate is 29.97

Regarding your question about the possibility of these things being progressive without proper deinterlacing, I have no idea. I’m also not able to put anything online at the moment…I need to find a good site somewhere that will allow me to upload for free (any suggestions?).

Thanks,

Paul

[Daniel Low]

How about https://www.yousendit.com/

By taking a look at it we should be able to figure this out once and for all!

__________________________________________________________________
Please post back saying what solved your problem. It could help others, and saying ‘thanks’ is free!

[Chris Blair]

Daniel Low:
That’s interesting, can you check the box for square pixels if you render out to a DV codec – DV25 for example?

Daniel,

Yes…all the options are available regardless of the format, the codec etc. I think trueSpace is converting the image somewhere before it get’s compressed.

I believe it’s like how you can create an SD widescreen image in photoshop by creating it at 720×486 with a 1.2 to 1 pixel aspect, or you can create it using square pixels at 864×486, then when finished creating it, just resize it to 720×486 (but keeping square pixels). Bring either one into your NLE timeline and they look correct.

I know graphics guys that dislike having to switch back and forth between the pixel-aspect correction feature in Photoshop, so they create all their widescreen graphics using square pixels as noted above, then when it’s all approved, they resize it.

So I think trueSpace is doing something to the image to correct for whatever codec or pixel aspect it ends up being. I don’t know about other 3D animation software, but when I set a project up in trueSpace, I don’t have to tell it the size of the project. It gets adjusted when rendered to whatever format, pixel size, pixel aspect ratio etc. And that’s whether you’re doing any of the many flavors of HD. Everything (including circular elements) come out looking correct as long as you check the right boxes.

If I start thinking about it too much…it makes my head hurt!! So I just render short tests, checking the stuff I think is correct, until the test render looks correct. Then I write it down for that particular format, pixel size & aspect, codec etc.

As an aside, we have 3 VelocityQ editing systems, and if you take a frame grab from the timeline, then open it in photoshop, Photoshop thinks it’s pixel aspect is square, when in fact it isn’t. I don’t know if there’s some sort of metadata that VelocityQ leaves out when it saves the still file (can save as bmp or jpg), but it leads me to believe that some software just isn’t “pixel aspect aware.”

Chris Blair
Magnetic Image, Inc.
Evansville, IN
http://www.videomi.com