-
WHY can I not get a truly raw render?
-
As requested, here are a couple of shots. Premiere Pro CS4’s Program Monitor window, showing uncompressed video, before and after it gets re-rendered as uncompressed video with Media Encoder. It should be obvious which one exhibits the horizontal degradation I’ve repeatedly referenced.
I feel compelled to note once more that it turns out the actual files themselves are not degraded in this fashion. It is instead a perplexing flaw in CS4’s Program Monitor rendering. The same flaw is not in AE, for example.
I also discovered something interesting which may give a clue as to why CS4’s Program Monitor is failing in this manner: If I take the uncompressed video (the one spat out by Media Encoder), line up the image to reveal the horizontal degradation, and then move the entire image upwards one pixel (ie change the vertical Position to 239), the horizontal degradation in the Program Monitor disappears.
-
It looks like pixel aspect ratio is affecting the overall shape of pixels. The slight gamma shift in the two clips is probably with the gamma settings in after effects preferences. QuickTime movies have problems with gamma shift.
It is hardly noticeable and it’s not somethingni would worry about. Butnif you can post the actual rendered out frames then we can use them for our own analysis. Export same frames to bmp at 32bit.
400% is highly critical. What kind of production are you working on? In my experience clients are much less critical than us tech heads and I doubt your client/s will notice the slight gamma shift.
DV resolution foe widescreen is stretched and looks worse on the program than on a tv so don’t get too worked up over the program monitor ifnit looks right when
exported. This is not an error, this is the same across all digital video editors. Calibated tvs with clean realtime output cards is the way to assess grades, never trust the computer screen.
– Jon BarrieJon Barrie
aJBprods
http://www.jonbarrie.net
http://www.suiteskills.com -
> It looks like pixel aspect ratio is affecting the overall shape of pixels.
Certainly. But I no longer suspect the aspect ratio has anything to do with this strange display flaw. It seems to be specifically related to how PPro – the Display Monitor, at least – is interpreting video which requires reverse pulldown to be displayed.
> The slight gamma shift in the two clips is probably with the gamma settings in after effects preferences.[…]It is hardly noticeable and it’s not somethingni would worry about.
I agree it’s hardly noticeable, and certainly less so after MPEG2 has done its inevitable damage. But it still would be nice to be able to nail down an uncompressed export which is not only exactly what I started with but can also be used in some kind of MPEG2 encoder. I mean, before yesterday, I was taking it for granted!
> Butnif you can post the actual rendered out frames then we can use them for our own analysis. Export same frames to bmp at 32bit.
Done. Actually, Media Encoder is busy encoding my movie with the oh so lovely MainConcept codec. (Side note: It’s taking over seven hours to do a two-pass encode – the maximum permitted by any Adobe solution, and I now strongly suspect why. Meanwhile, my other codec gave me its result after 3 hours and six passes. Pity its output turned out to be unusable.) And Media Encoder would not give me the option of pausing one render to make room for another. And of course CS4 lost the ability to simply give me one darn frame. Part of their famously hair-brained overhaul. So I had to render these off with After Effects. Hopefully this did not compromise things.
> 400% is highly critical. What kind of production are you working on? In my experience clients are much less critical than us tech heads and I doubt your client/s will notice the slight gamma shift.
This is a restoration of a movie for my mother. It cannot be purchased, despite being quite old and fairly well known, so I have had to use various sub-par sources to generate a hybrid, including a DVD transfer of a VHS tape. In spite of how it all sounds, the result is rather good. It is very true that my mother is unlikely to notice or even care about subtle inadequacies of quality. But two things. First, this will be playing on an 80 inch projection screen, so anything I can do to maximize the quality (outside of rendering the thing as something besides a standard DVD) is something to aim for. Second, I’ve already invested a lot of time in this project. Theoretically, minor tweaks should add inconsequential work to what I’ve already put into it.
Before:
738_requestbefore.bmp.zipAfter:
739_requestafter.bmp.zip -
You say you are working with a DVD source made from a VHS tape – do you have access to the VHS tape? As DVDs are so highly compressed, you’d be better off recapturing the VHS tape direct to the NLE system using an analog capture card, where you could capture as uncompressed, or at least a high data rate I-frame codec with 4:2:2 color. MPEG-2 for DVD and DV codecs are losing a lot of image info.
Jeff Pulera
Safe Harbor -
If that’d been an option, yes, I’d have done it. But the DVD was all I had.
As it happens… CCE SP can’t deal with 24p video (it shifts the entire frame upwards one pixel and duplicates the second-from-bottom scanline at the bottom, and no tweaking can get around this). I had to go with Adobe’s MainConcept mpeg2 codec, which only allowed up to a two-pass encode. The result was, predictably, rather horrendous. (But at least MainConcept didn’t mess with my scanlines.) So… now I’m rendering the whole thing off as a 1080p Bluray.
-
Using the tried and true method of stacking the two clips/stills on top of each other and setting the top to opacity method difference with a Waveform monitor I see there is no difference in luma or chroma between the two supplied shots. So it’s a trick of the eye and technically there is no difference.
Try it yourself. Photoshop & AE can confirm this method too. But PPro has the waveform monitor to further prove the technical end is a near perfect match. The slight value showing could be in the BMP algorithm or the conversion stage of the before and after. This can happen when blowing up low quality VHS 240/250 scan lines to a higher value as the pixels need to overlap the higher res grid which creates a variable subpixel value depending on which codec is used at export and then the subpixel can be reinterpreted differently as it never completely lived in a pure pixel from the beginnig. But this appears to have 0 RGB value through most of it, the occaisonal value pops up per pixel. Well within legal contrast and would never be noticed on a moderately calibrated TV/projector/plasma/LCD/LED.
740_comparewithdifferenceblackvaluetipping14pointsoff.png.zip
Like I mentioned in an earlier post we can sometimes get too caught up in a minor thing we think is important and end up spending so much time on it only for the end result to look fine or not be any different at all.
Blowing it up to Bluray is not my recommended pathway as the pixels are futher being blown up and most BluRay players can up-res a DVD with internal hardware to a very high quality.
Good Luck.
– Jon Barrie 🙂
Jon Barrie
aJBprods
http://www.jonbarrie.net
http://www.suiteskills.com -
> Using the tried and true method of stacking the two clips/stills on top of each other and setting the top to opacity method difference with a Waveform monitor I see there is no difference in luma or chroma between the two supplied shots. So it’s a trick of the eye and technically there is no difference.
There is, actually. In that particular case, the difference is easier to see up close than it is by studying the waveform. But let’s take a look at a different frame:
The waveform discrepancies are more apparent. And in the image itself, the nature of the borders of objects has been modified visibly. Could be argued that these are still subtle, but the point is that this was supposed to be an uncompressed render – a file format costly in size with the advantage of being the effective substitute for proper frameserving / Dynamic Linking / what have you. And as such, this is a failure.
> This can happen when blowing up low quality VHS 240/250 scan lines to a higher value as the pixels need to overlap the higher res grid which creates a variable subpixel value depending on which codec is used at export and then the subpixel can be reinterpreted differently as it never completely lived in a pure pixel from the beginnig.
This one is tough to buy, because the effect is if anything even more pronounced in frames that have already been rendered as uncompressed.
> Like I mentioned in an earlier post we can sometimes get too caught up in a minor thing we think is important and end up spending so much time on it only for the end result to look fine or not be any different at all.
And it’s worth mentioning again that this kind of problem is indeed minor, particularly in this case where I’m just making some DVD, yet it would be desirable, if at all possible, to get the result one might justifiably expect: the minimization of unnecessary image degradation.
> Blowing it up to Bluray is not my recommended pathway as the pixels are futher being blown up and most BluRay players can up-res a DVD with internal hardware to a very high quality.
90% of my purpose in recreating the project as a Bluray is to defeat the considerable compression artifacting. In fact, that’s the main benefit of Bluray as a whole: Fewer and smaller compression artifacts. (In my opinion.) I’ve already made my fair share of BDMVs out of SD sources, proving what was easy enough to intuit.
In this specific case, the need to take this approach was severely underscored. First, I had a good deal of difficulty with CCE SP, as it ended up being incapable of rendering 23.976 MPEG2 without modifying the frames. This left me with MainConcept 2-pass. MainConcept is trash. There’s no kind way to put it. The resulting encode was essentially unusable. I’ll give it points for not exhibiting the perplexing issues CCE SP had. Anyway, bypassing the whole MPEG2 headache is another 5% of the purpose in going Bluray.
The remaining 5% is that it gives me the opportunity to make the two separate sources (one being full frame, the other 2.35:1) better fit the frame edges. I had been keeping them pixel-perfect since it was just 720×480, but this meant keeping ugly edges, or blacking them out.
-
I’m not sure we’ve all defined our terms completely.
Regarding “uncompressed” — there is a lot of leeway in the video realm for what this really means. 4:2:2 YUV video is termed “uncompressed”, but the chroma samples are 1/2 that of luma samples — that’s compressed.
If you wish to see if Premiere (and NOT output codecs) is changing frame pixels, I would suggest using a truly uncompressed format, such as a TGA frame sequence in and out, and compare that. Premiere, as far as I know, works in RGB colorspace; most codecs for presentation will work in a variant of a YUV space. Something is bound to change a bit in the process. MPEG2 is a very lossy codec (it was designed that way), so it’s not fair or accurate, in my opinion, to judge that output vs. “original” footage.-jeff
-
I had the same issue with loosing resolution in output files, and here is my story:
Upgrade both Premiere and Media Encoder to latest versions, and render with MAXIMUM RENDER QUALITY….
When exporting progressive footage from Premiere to Media Encoder Yu MUST make custom SEQUENCE which is PROGRESSIVE (NO FIELDS), because if you export progressive footage from default interlaced sequence, this thing with deinterlacing is happening….
Try, and you will see a big difference…..
-
Not sure how to do that, exactly. The sequence from which I export claims to be 23.976fps, and the video used in said sequence is all interpreted as progressive. If there are other (well-hidden?) variables I need to be sure to tick, I missed ’em.
Reply to this Discussion! Login or Sign Up