A doozey! Why one flickers and the other does not...

Posted by Cheesenightmare 
A doozey! Why one flickers and the other does not...
August 05, 2006 11:07PM
Hi all - I run a Final Cut Pro group in Sydney Australia and I just can't wait to get some feedback on the little X-file I got from one of my members (name of Jim85)

First, here's Jim85's Pic



Now Here's a very similar (in size and resolution) pic



Bring both onto a DV Pal Timeline in final cut and the blue car gives us substantially more flicker on a monitor. What's more reducing the blue car in size makes for horrendous "saw toothing" of near-horizontal diagonal lines. It quickly becomes unusable.

De-interlacing the picture reduces the quality substantially for the Blue car...but only partially for the red car.

Flicker filter does fix the issue. But rather than purchasing a fish i want to buy the fishing rod, if you know what i mean.

That is to say I am fascinated by the cause of this. I have seen it before in a Logo (png)

So...

Is there something inherent in the .jpegs? Can stills be 'Interlaced' or 'Progressive"?

What the difference between these pics, except for apparently bad driving in one and the chick-magnet qualities of the other. (jokes)

Seriously...

One thing I did notice i that the blue car has non-square pixels. Would this account for what i am seeing.

OK you LAFCPUGroupies! Throw em on your timelines and tell me what you think smiling smiley

Doug_

www.sydneyfcp.info



Post Edited (08-05-06 21:24)
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 01:04AM
im no expert, but the porsche is a MUCH softer orginal picture, which may account for less jaggies in the DV realm?
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 01:07AM
Well, in making a DV timeline, the first thing I notice is that the blue car pic needs rendering...RED bar. The Red car gets me a green render bar. For the life of me I never understand why some pictures need rendering and others don't. Well, they both do...but one won't play in realtime while the other will. Anyone know why that is.

Second, yes, I do see the horrible interlacing that the blue car has, especially on the striping. And the picture of the red car is squished. I guess due to my NTSC timeline. Making a PAL one.

Interesting...on the PAL timeline the Red car now needs rendering, and the blue car doesn't. AT ALL. Dark green render bar above the clip instead of a bright green one. Same interlace issue with the blue...and same squished image on the red.

BUT...don't use JPEGS if you can help it. NOT AT ALL. Tiffs or PNGs...jpegs are highly compressed files and you lose a lot of image data.
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 01:34AM
I dropped the 2 JPG files into a DVCPro - PAL sequence (720x576). I get a green bar on both pics with no interlacing issues at all (change the view size in the Canvas to 100% & the interlacing on the blue car disappears on the Computer Monitor).

- Joey



When life gives you dilemmas...make dilemmanade.

Re: A doozey! Why one flickers and the other does not...
August 06, 2006 01:49AM
100%...will you look at that.

This reminds me that you should never ever judge the quality of ANYTHING on the computer monitor. Hook up a TV to see what you are really getting. This is why:

Shane's Stock Answer #2: Blurry playback

ONLY JUDGE THE QUALITY OF YOUR MATERIAL ON AN EXTERNAL NTSC MONITOR, OR AT LEAST A TV.

1. Disable overlays on the canvas
2. Make sure you've rendered everything (no green bars at the top of the timeline

[docs.info.apple.com]

DV footage requires large amounts of data and many computations. In order to maintain frame rate and be viewable at a normal size, only about one-fourth of the DV data is used in displaying the movie to the screen. However, the DV footage is still at full quality, and is best viewed thru a TV or NTSC monitor routed thru your camera or deck.

Shane
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 02:13AM
The blue car picture is 720:576 (Photoshop) which should drop into a PAL timeline with little or no management. Of course, circles will not come out round if you do that because FCP will assume non-square pixels.

The red car picture is 760:504 which will take significant management before it will drop into any timeline--and it may leave visible black bars. I have no idea what FCP will do to a picture that far off.

That will also increase the softness of the picture, so the red car will get worse.

Koz

Re: A doozey! Why one flickers and the other does not...
August 06, 2006 02:18AM
Alright - Thanks so much for your responses so far. The ball is rolling smiling smiley

Here's my thoughts on the replies thus far...

____________________

"Author: wayne granzin

im no expert, but the porsche is a MUCH softer orginal picture, which may account for less jaggies in the DV realm?"

Good thought, but the results are the same on an uncompressed 8 Bit timeline.

_____________________

Author: Shane Ross ()
Date: 08-05-06 23:07

"Well, in making a DV timeline, the first thing I notice is that the blue car pic needs rendering...RED bar. The Red car gets me a green render bar. For the life of me I never understand why some pictures need rendering and others don't. Well, they both do...but one won't play in realtime while the other will. Anyone know why that is."

I think I might have figured out that much at least - ye olde PIXEL ASPECT RATIO! You can actually change the pixel aspect ratio by open the clip properties and right clicking on the Pixel aspect ratio - when you change it, you can see your rendering requirements change.

"Second, yes, I do see the horrible interlacing that the blue car has, especially on the striping"

Excellent...me too. I'm cancelling the optomitrist appointment tongue sticking out smiley


"BUT...don't use JPEGS if you can help it"

The original problem was with a tiff - I just converted to Jpeg for net friendliness and because it didn't affect this issue at hand - the jaggedness.

(But as an aside, in my opinion, sometimes Jpegs are the way to go - they look great on a Pal/NTSC Monitor and can be much friendlier on a slower machine. Sometimes the imperceptible difference is an excellent compromise)

____________

Author: grafixjoe

"...no interlacing issues at all (change the view size in the Canvas to 100% & the interlacing on the blue car disappears on the Computer Monitor)."

Yes indeed - changing to 100% does make it look all good on a computer monitor.


Many's the time I have had to explain that fit to window Versus 100% thing. And yet it aint that.

...Play the finished product on a Monitor.

Kind of flickers a little - a bit like the sort of flickering that you get when something is a little too high res.

Now reduce the scale to 50% (Jim85 wants to do Picture in Picture you see)

Have a look at that on a Monitor to witness on the true face of ugly.

To make a horror move, simply scale from 50% to 100% over about three seconds - instant R rating - its that bad.

And yet, the red sports car doesn't suffer nearly so much from the scale reduction.

__________________


Honestly, the advice I would have given is "Jim85, make sure your resolution is at around 72 dpi and your picture dimensions are around 720 x 576"

And he has - and yet both these pictures match that description approximently.

So hence the term "doozey" - a term i do not throw around lightly...

The reason I am going to such great lengths to solve this is because it is a problem that i am seeing in forums the world over. People all have theroies and yet people still ask the question - It must be one of the most asked questions out there.

Hopefully, by providing these two concrete examples and challenging people to drag them onto a timeline and make them work, we will have a concrete solution.

Thank you so much for your help so far, I really appreciate the time and effort.

Doug_

www.sydneyfcp.info



Post Edited (08-06-06 00:22)
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 02:31AM
More responses:

_________________

Author: Kozikowski

"The blue car picture is 720:576 (Photoshop) which should drop into a PAL timeline with little or no management"

Not a bad theory...and yet the opposite is true...The red car wins hands down.


__________________

Author: Shane Ross ()

"100%...will you look at that.

This reminds me that you should never ever judge the quality of ANYTHING on the computer monitor. Hook up a TV to see what you are really getting."

Very true indeed. And examining the canvass/viewer at 100% was one of my first steps. But the issue is on the monitor. Flickering like a...really flickery thing.

And scale down the clip, and things get worse...the mystery deepens...

__________________

By the way - please consider that this is not just a DV issue. I get the same results on an 8Bit uncompressed timeline...interesting hey?
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 05:02AM
it reminds me of a problem one of my prof. gave me with after effects

he gave me a very large image that wouldn' precisly scale to a timeline, wen viewed on a comp monitor and spicifcly and ntsc display the image would get this flickering effect as the program would try to adjust the sclaing and data into them imag,e and when the image movied all these odd sclains of glimmers and light would flicker as they crossed the lines of interlacing.

i think this is a similer problem, has anyone tried scaling down teh image in say photoshop to the exact size of the timeline and seeing if that helps?

if not give it a try

if yes, well, even the majestic bald eagle can flyinto a window cleaned with windex


-wait what?



Amateur Teacher
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 06:26AM
Most still images will flicker if you put them in an interlaced sequence and view on a video monitor. Why? Well if the image contains fine horizontal detail then those pixels will appear on only one of the two fields within a frame so they are being shown for 1/50th sec and then not shown for the next 1/50th sec (in PAL). That shows up as flicker.

If you scale the image down then the problem becomes worse because it becomes more likely that some parts of the image will only appear on one row of pixels and hence produce more flickering. The flickering can be reduced by smoothing this fine detail out so it is spread vertically to the neighbouring pixels, which is just what FCP's Flicker Filter does.

So how come the red car doesn't flicker? Simply because the red car image is so much softer to start with so the pixels aren't as defined as they are on the blue car image. It's not connected with DV vs uncompressed codecs, square vs non-square pixels, file format or DPI (which incidentallly FCP doesn't understand or care about).

Martin Baker
www.digital-heaven.co.uk
Unique plug-ins and tools for Apple Pro Apps



Martin Baker
[www.digital-heaven.co.uk]
Unique plug-ins and tools for Apple Pro Apps
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 07:53AM
Hey there Martin,

As far as i am concerned you are perfectly correct.

I considered you answer and tried it out on several different pictures. I am convinced you are the, as they say, man. Thanks for your well expressed insight.

I think what I really had to get my head around was that it is somewhere between the detail in the red car picture and the detail in the blue car picture that the detail threshhold of interlaced SD video exists.

Now, I'm satisfied smiling smiley

One question. Final Cut Pro doesn't understand or care about DPI? Could you explain that. In my experience DPI directly influences

a) the time/processing power it takes FCP to process a still in a sequence and
b) the scale to which it can withstand being 'blown up' to.

Thanks again,

Doug_
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 09:54AM

<<<Final Cut Pro doesn't understand or care about DPI?>>

It's a concept problem. Dots (or pixels) Per Inch is a measurement of printing resolution--as in ink on paper. It gives you tools to determine very accurately how large an image is going to appear on the printed page.

That doesn't work in video because you can't determine how large the video screen is going to be. 720 by 480 (in standard NTSC television) is going to fill the screen no matter if I'm watching on my 12" iBook or my 70" Plasma Panel.

Open an image in Photoshop and Launch Image, Image size. In an unmodified Photoshop the dialog panel will open up with a top half in straight pixels and the bottom half with Inches and Pixels per Inch. The top half is video and the bottom half is printing press. You can use whichever one you like (people publish tools for getting between them), but you're invariably going to run into the concept problem that video is only paying attention to the top of that panel.

Koz

Re: A doozey! Why one flickers and the other does not...
August 06, 2006 12:24PM
Yep Koz is right. DPI matters only when you scan an image or print it out and FCP does neither of these things, so it doesn't need to handle DPI.

A 1600x800 image at 72DPI and a 1600x800 image at 400DPI will behave exactly the same in FCP. The only thing that FCP cares about is the pixel dimensions of an image.

Martin Baker
www.digital-heaven.co.uk



Martin Baker
[www.digital-heaven.co.uk]
Unique plug-ins and tools for Apple Pro Apps
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 12:34PM
> A 1600x800 image at 72DPI and a 1600x800 image at 400DPI will behave
> exactly the same in FCP.

Isn't there a caveat to this: Overlarge files will misbehave in FCP? This is the reason for scaling images down to 72dpi before working.
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 02:37PM
>>> 100%...will you look at that.

This reminds me that you should never ever judge the quality of ANYTHING on the computer monitor. Hook up a TV to see what you are really getting. <<<

...hence, one of my favorite LAFCPUG.org mantras:

"ALWAYS use an external NTSC (or PAL in this case) Reference Monitor. NEVER use the Computer as a reference for output."

- Joey



When life gives you dilemmas...make dilemmanade.

Re: A doozey! Why one flickers and the other does not...
August 06, 2006 04:14PM
> A 1600x800 image at 72DPI and a 1600x800 image at 400DPI will behave
> exactly the same in FCP.

>Isn't there a caveat to this: Overlarge files will misbehave in FCP? This is the >reason for scaling images down to 72dpi before working.

Isn't something scanned at 400 DPI going to have more detail than something scanned at 72DPI?

That would be a good reason that they misbehave in FCP...after reading Martin's Analyis of the red car versus the blue car...not because of the DPI per se but because of the detail the High DPI scan brings to the party.

Also, i think the "Make sure that you watch on a Monitor" statements are already well heeded on this thread. Its on the monitor that the issue shows up.

Doug_

www.sydneyfcp.info



Post Edited (08-06-06 14:17)
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 05:56PM

<<<Isn't something scanned at 400 DPI going to have more detail than something scanned at 72DPI?>>>

Let me hit it this way. The video system (in the US) has 480 visible scan lines top to bottom (yes, I know the 486 thing. Work with me here.)

Any image you bring to the party is going out to the client 480 shining points of light (pixels) tall, it doesn't matter if you scanned it at 2K x 4K and 800 dpi.

Everything gets resampled to end up 480 on the screen. If you start out with a picture *smaller* than 720 x 480, Final Cut has to make up new pixels as it goes--blowing up the picture to fit. Those pictures can look like serious trash.

You can go up to 4,000 by 4,000 pixels before Final Cut gives up. Coming down is a lot more graceful than going up, plus a larger image lets you pan, tilt, and zoom without the image falling apart.

Another trick:

Open an image in Photoshop. Option-Click-Hold in the thin file size window at the bottom of the image. Those first two numbers are the actual pixel count in the image.

We have been known to create graphics at 1440 x 1080 (double both ways) and then rezise to 720 x 480 with the Constrain Proportions turned off. This lets us create graphics where circles are round and the slight softening during the resizing gets rid of the sparklies.


Here's something I don't know. Most times Final Cut will try to resize the image to fit the screen. Sometimes, it imports the image original size and lets you zoom and pan around. I don't know the difference.

Koz

Re: A doozey! Why one flickers and the other does not...
August 06, 2006 06:37PM
>Everything gets resampled to end up 480 on the screen.

At what point does the resampling happen?

I would have thought that something scanned at a higher DPI will withstand being blown up better than something scanned at a lower DPI - provided the resampling happens during the scaling up process and not, for example, during the import into final cut process.

Doug_
Re: A doozey! Why one flickers and the other does not...
August 06, 2006 08:22PM

<<<At what point does the resampling happen?>>>

It has to happen at the timeline because If you do Item Properties in the Viewer from the Bin, it's the same size as the import.

Nothing survives being blown up. If your graphic didn't have at least 480 vertical pixels, then Final Cut is going to have to make them up which always looks terrible. This is assuming you want the graphic full frame.

A good way to know this is going to happen is that Option-Click-Hold trick. If those first two numbers aren't 720 by 480, then Final Cut is going to have to do picture management at the import step and you may not like that.

The DPI number does come into play at the print end--at the scanner. If you scan the image at 4,000 DPI, then a really really tiny portion of the scan is going to fit on the video screen--whichever part 720 x 480 represents.

Here's another photoshop trick. File, New, and create a rectangle on the screen that's 640 x 480. when it arrives, double click on the magnifier tool (but don't use the tool for anything).

Leave it open.

Then open up a graphic you intend to use in the video. Double click on the magnifier tool. The difference between the sizes of the two graphics is the amount that Final Cut is going to have to mess with the picture to fit.

The 720 non-square pixel thing comes into play, too, but 640 will get you into the ballpark really fast. If the graphic is really tiny compared to the 640 x 480 rectangle, then Final Cut is gong to have to blow it up.

Koz

Re: A doozey! Why one flickers and the other does not...
August 06, 2006 10:13PM
Thanks Koz, I hope you stick with me on this cos I'm almost there but not quite.

First you said:

>It has to happen at the timeline because If you do Item Properties in the Viewer from the Bin, it's the same size as the import.<

but then you say:

>If those first two numbers aren't 720 by 480, then Final Cut is going to have to do picture management at the import step and you may not like that.<

So does the resample happen at the timeline, or at the import stage? Those two statements above seem contradictory to me.

The way I figure it , an image with resolution 150 dpi will have twice the information as one with 75. So a 720x576 (Pal Size) image at 75 DPI will not withstand scaling up. But a 720x576 image at 150 DPI should comfortably scale up to around 200%

Unless of course it is resampled to 72 dpi on IMPORT.

Am i completely wrong?

Is DPI not even a factor in resolution? Does everything resample down to 72 DPI on import and only picture dimensions matter?

Thanks again all

Doug_
Re: A doozey! Why one flickers and the other does not...
August 07, 2006 01:39AM

Once upon a time in Washington, the Bureau of Bathrooms and Showers decreed that there could only be two kinds of bathrooms; NTSC and Printing Press.

The shower wall in a Printing Press bathroom could be as large and have as many tiles as the owner could afford.

The shower wall in an NTSC bathroom could only have 720 tiles side to side and 480 tiles top to bottom no matter how big the bathroom was.

It came to pass that a powerful movie producer was being forced to sell his house in the Hollywood Hills. One too many of his cult movies failed to find a cult willing to pay to see it. This producer had a Printing Press bathroom and had increased the number of inches in the shower and decreased the size of the tiles until he could see the entire Sistine Chapel ceiling with enough tiles left over for the Rectory decoration from St. John the Divine in NY.

The producer was settling down into his 1000 sq. ft. 3-bed 1-bath in Culver City when he noticed he now had an NTSC bathroom. "This," he said in his best producer voice, "Sucks."

"I want my Sistine Chapel back."

"Well," said the long suffering assistant, "I don't think you can get 12 apostles, Jesus, and a long, skinny dinner table into 720 tiles, not to mention the angelic host from St. JD's."

"Not to worry," exclaimed the producer used to making snap decisions. "We'll just rip out the wall and make it bigger. That will do the trick. More inches is always better."

"Well," said the assistant, now hiding behind a clothes hamper. "The tiles in an NTSC bathroom will just get bigger. They are required by law to always be 720 wide and 480 tall no matter how big or small the shower wall is. Inches don't mean anything in an NTSC bathroom.

So after the producer settled down from his tirade, he just made do with the simple pictures he could do with the tiles he had until he could gather enough money to move into a house in Malibu with a new HiDef bathroom.

Koz

Re: A doozey! Why one flickers and the other does not...
August 07, 2006 02:24AM
Koz, you've truly got a gift for explaining. You shold do kids movies on the finer points of rocket surgery winking smiley
Re: A doozey! Why one flickers and the other does not...
August 07, 2006 03:49AM
Koz.

You have moved me to tears.

That was, is, will probably forever remain the most articulate forum reply I have ever recieved and if you don't mind, I will tell it to my children before bed time if i ever have any and Hi-Def still hasn't caught on in Australia by then.

Live happily ever after, sir.

Doug_
Re: A doozey! Why one flickers and the other does not...
August 07, 2006 04:10AM
I'm not going to try and top Koz's superb story but Doug, you really got to forget about DPIs of files in FCP!

I think you're confusing scanning an image at a higher DPI (which will produce more pixels and allow you to zoom into the image without degredation), with the DPI value of a file (which FCP doesn't use or care about).

When you scan an image, the DPI value is stored in the file, so it can be printed out again at the right size. However, just changing the DPI value of a file will make absolutely no difference within FCP because this information gets ignored anyway. So your 720x576 image at 150DPI will behave just the same as a 720x576 image at 72DPI (assuming it is the same file and you've just changed the DPI value in Photoshop).

Martin



Martin Baker
[www.digital-heaven.co.uk]
Unique plug-ins and tools for Apple Pro Apps
Re: A doozey! Why one flickers and the other does not...
August 07, 2006 05:24AM
Yeah. I am still reeling from Koz's reply smiling smiley

But I fully undersand now. Its funny because I have been an advanced user of FCP for a few years now and this is such a fundamental concept which I made an assumption about years ago and its always 'sort of' worked but at the back of my mind i knew something about my assumption wasn't quite right.

Your collective contributions have cleared this right up for me.

Thanks again everyone.

i owe you all a



smiling smiley

Doug_

Re: A doozey! Why one flickers and the other does not...
August 07, 2006 09:09AM
And that's a damn good beer - from a small boutique brewery right near me in Fremantle! Great place for lunch if any of you ever make it over here.
Anonymous User
Re: A doozey! Why one flickers and the other does not...
August 07, 2006 02:21PM
Okay, I just have to ask...

What is the origin of "Cheesenightmare"?

debe

Re: A doozey! Why one flickers and the other does not...
August 07, 2006 05:17PM
<<<gift for explaining.>>>

Thanks.

Painting with words.

<<<You have moved me to tears.>>>

If you can't focus on the monitor any more, we haven't gained anything here, have we?

<<<i owe you all a >>>

What are the tags for an image?

Koz

Re: A doozey! Why one flickers and the other does not...
August 08, 2006 08:22AM
>What are the tags for an image?<

For the beer one, you type:



Doug_
Re: A doozey! Why one flickers and the other does not...
August 08, 2006 08:25AM
Oh! And the name cheesenightmare? I have wonderful visions if i eat cheese and go straight to sleep. The stronger the bettter...blue cheese, parmasen, jarlsberg. I'm sure I'm not the only one smiling smiley

D_



Post Edited (08-08-06 06:25)
Sorry, only registered users may post in this forum.

Click here to login

 


Google
  Web lafcpug.org

Web Hosting by HermosawaveHermosawave Internet


Recycle computers and electronics