So when/how do you sort through your source footage to determine the best takes to import to your RAID? It sounds like Premiere Pro wants you to import everything to your RAID and then just import what you need into your project.
I’d like there to be a way where you can do something like this:
1) Copy all your footage from the memory card to an archive drive (or maybe 2 archive drives)
2) Transfer only the best shots (including setting in/out points) to your RAID
3) Import those files into Premiere Pro
Sounds like you’d need to do step #2 using the operating systems file manager, or using the camera manufactures supplied footage viewer. I understand that Premiere’s Media Browser will allow you to sort through the footage, add Meta data, in/out points, but it won’t allow you to transfer the selected footage from one storage location to another. I don’t like filling our expensive RAID up with bad takes or long takes where I only actually need a few seconds.
Premiere looks to be a robust application, so maybe I’m missing something?
Posted by Mitch L. on 05/16 at 06:02 AM
Mitch,
Yes, you’ve pretty much summed up the major file management “issue” (if you want to call it that) when dealing with formats natively in Premiere Pro. Wherever the files exist when imported is where they stay.
It really depends on the format you’re using. With something like P2 or XDCAM EX, for example, after offloading cards to an archive drive, I’ll usually use the manufacturer’s utility (P2 Viewer and XDCAM Browser, respectively) to log footage and then pre-select anything I might want to work with in Premiere Pro. Both of these tools use a two-pane approach where you can browse your original offloaded folders, and then set up a new folder structure elsewhere and drag clips from the original folders into it. This is also a good way to merge material from multiple cards. Presumably, you’d place this new folder on your RAID or working drive; the result is just what you want/need when you access the new folder structure from Premiere Pro.
The problem, though, is that while you can select just the shots/takes you want, you can’t limit the amount of material from a given shot. I’m not aware of any of the manufacturers’ utilities or any third-party utilities that will do this without some sort of transcode or rewrap; this is what FCP’s Log and Transfer is doing, and there is no analog to that in Premiere Pro. I’ve actually used the Adobe Media Encoder in this way, though: occasionally, I’ll import DVCPROHD P2 clips into AME, mark ins and outs, and use QuickTime DVCPROHD (Premiere Pro ships with this) to losslessly create trimmed, self-contained files for editing. Premiere Pro handles these natively using the same importer and decoder that it does to handle the original P2 clips. It’s not perfect for every workflow, but it is an option.
For material like Canon DSLR (H.264), Premiere Pro doesn’t provide “smart” editing or encoding, and neither does AME. However, a simple free application like MPEG Streamclip does, and I’ve used that to chunk up the H.264 MOVs into smaller pieces—it will cut at GOP boundaries, so no re-encoding occurs. It will even batch process, so it can make quick work of this task. Since they’re simply self-contained files, you can just copy the ones you need at the OS level and paste them to your RAID.
In a perfect world, we’d have one ubiquitous, cross-platform tool that would work with all the tapeless formats, letting you offload, make archives, log clips, make your selects, and move them to your edit drive. To my mind, this is the major “miss” with the workflows for all tapeless formats. I’d love to see a tool that did all this; it seems to me that, given Adobe’s capability to work with all these formats natively, they could cook up a pre-post-production application to address this. The other tools in the suite—OnLocation and Bridge—really don’t fit the bill, but merging them together along with Premiere Pro’s backbone would be a welcome workflow tool.
Hope that helps a bit.
Posted by .(JavaScript must be enabled to view this email address) on 05/16 at 08:32 AM
These are the things I’ve been trying to express to my editor friends, but man they can not let go of FCP. Maybe I should start telling producer who will then tell them it’s more cost effective.
Posted by .(JavaScript must be enabled to view this email address) on 05/16 at 12:07 PM
This is going too far.
All recent articles, the last 9 in the main page, but there are more, are about Adobe After Effects and Premiere Pro, and how wonderful they are.
What´s going here?.
Is Adobe a sponsor of PVC now?.
I hope PVC keeps being a balanced and neutral site.
I agree Adobe stuff is great, but all these articles are focusing too much on them.
There are lots of articles that could be written about Media Composer 5.5, Lightworks, Scratch, Resolve, and the others.
Please, stop selling us Adobe.
Flavio G. García
Posted by La Moviola Digital on 05/16 at 12:34 PM
I disagree. As a long time Final Cut Pro user (and Adobe After Effects, Photoshop, Illustrator) I’m very interested in Premiere. The more details the better.
My dream would be if someone wrote an article titled “Premiere for Final Cut Pro Users”.
Posted by Mitch L. on 05/16 at 04:04 PM
My mind can fully withstand the selling too.
Informative Piece. Thanks.
Not at all impressed by the denigration of transcoding though.
I wonder what will happen when Adobe tries to sell “native” to all of the ProRes transcoders?
As a pro and a Cineform user I didn’t have problem wrapping my mind around that time-consuming process, given all if the major benefits it provides that are certainly not at all bestowed on footage that is simply accelerated by Mercury, etc.
Certainly, things like Premier’s open timeline, etc. are great but as the writer points out, I can still use Cineform on selected clips in a mixed-format timeline.
I love Cinform’s converting my 8bit files to 10bit, thus answering the problem of degradation in post due to heavy compositing, etc. Plenty of other things that are not answered by merely increasing the speed of native files.
But please excuse me. I need to do some transcoding, while I’ll go out for something to eat. And more transcoding tonight too, while I’m asleep. When I wake up I’ll have footage that looks superior, edits on a slower laptop like butter, allows heavy composting without breaking down, better color correction, etc. etc.
Posted by wsmith on 05/16 at 05:32 PM
I don’t think you’re footage will ever look “superior” when transcoded. The footage is still going down a generation (you’ve made a copy of it).
But yeah, I like how well ProRes responds on a Mac. But maybe that’s because we’re not used to how well Premiere responds to all footage (transcoded or not).
I can’t wait to give it a try. (we’re still using CS4)
Posted by Mitch L. on 05/16 at 08:06 PM
It’s refreshing to see a site that actually gives coverage to Premiere, considering almost everywhere else seems to be in love with Final Cut and not even mention Premiere, despite the last several versions being bounds ahead of FCP.
Posted by .(JavaScript must be enabled to view this email address) on 05/16 at 09:08 PM
Mitch L,
OK, “superior” is subjective. What I mean to say is that it’ll look superior when heavily manipulated in post. As the writer points out, this is a weakpoint of editing natively (codecs that were simply not developed with heavy post in mind, in the first place).
However, footage transcoded to Cineform but before it’s been hammered in post looks every bit as good as the original. I strongly reject any notion that the picture is in anyway degraded. Not one iota and that is indeed the professional opinion of many credible, veteran pros who have look at it seriously.
Standardized, computer-based, Picture Quality Analysis (PQA) tests have shown that Cineform’s quality is “visually lossless”.
(I’ve heard that they’re working on “mathematically lossless” compression” too).
Certainly, Cineform’s wavelet-based compression scheme is definitely technologically superior to the macro-block compression scheme used by the majority of cameras - even most pro cameras.
When you refer to “how well Premiere responds to to all footage…, I trust you do understand how that performance is highly dependent on the computer’s performance specs.
I can work on footage that’s absolutely pristine compared to the original footage and do it on an older laptop. (Cineform’s playback engine doesn’t rely on the GPU at all and its wavelet compression is very easy on the CPU).
In my own opinion one has only two real choices when it comes to maintaining highest PQ throughout the rigors of post that shine above all other codecs: No codec at all with uncompressed OR wavelet based.
I’m just a guy who’s found he can work at very high quality without needing to in some “native” codec requiring a relative super computer and an expensive graphic card.
Soon I’m going to get off my butt and build a new liquid-cooled Wintel box to replace the one I built 5 years ago. It’ll be a screamer and I won’t scrimp on the GPU either.
I’m just glad to know that I’ll still be able to transcode certain source clips to Cineform for inclusion onto Premiere’s open timeline, along with various other media formats in the same project. I definitely want my 8bit clips transcoded to 10bit.
Finally, I was a bit disappointed to see another review of Premiere that doesn’t say anything about its multicam editing performance.
Posted by wsmith on 05/17 at 10:24 AM
Thanks for the civil discussion, everyone.
wsmith: You make valid points, but let me clarify a few things…
At no point do I think I’m willfully denigrating transcoding, particularly to a higher-quality intermediate codec such as Cineform. In fact, I’d advocate for this, especially when dealing with H.264 media for the quality and performance reasons that you point out—I cannot dispute how damaging that codec can be. If you’ll notice, most anywhere I mention transcoding, I’m talking about “not waiting” for it to happen. My biggest gripe about transcoding, is that it is a massive time-and-space sinkhole—you alluded to this fact in your first comment. For situations where utmost quality and performance is desired, obviously, transcoding is a given factor that you just accept. But for many users, being able to import and work directly with these files is a great workflow—not all of us are making movies.
My main goal here was just to demonstrate how the transcoding or rewrapping process you might otherwise be mandated to use isn’t strictly necessary. I work natively with AVCHD and DSLR footage regularly, and it’s really not too bad even in color correction when you’re given good source footage. The shooter I work with is experimenting with the Technicolor CineStyle profile in his Canon 7D (http://www.technicolor.com/en/hi/cinema/filmmaking/digital-printer-lights/cinestyle); this results in a very flat contrast that responds much better to grading. With an adequate (and then some) computer, the performance issue with CS5.5 is pretty much not a factor.
I guess I can’t really find fault with Adobe letting you work this way with this type of footage—it’s the camera manufacturers that made these design decisions, after all—but I will submit that it would be nice to see the flexibility of an optional simple transcode/ingest process in Premiere Pro. I just don’t want to be hamstrung into having to do that—that flies in the face of native format support.
Regarding your comment about multicam editing: again, this wasn’t intended to be an inside-out review of Premiere Pro, so the lack of commentary on this subject wasn’t just a brushing over. Rather, it’s a look at one particular facet of post-production within Premiere Pro. I do use multicam in Premiere Pro, and if you want my two cents, here it is: it works, but it needs some help. Four angles is limiting, it’s sort of a pain to set up, and it has some annoying quirks that make it more frustrating to use than it really should be. I do several 2-5 camera shoots during the course of a year, and each one has been edited in Premiere Pro, from version 2 through CS5.5. I’ve got a five camera shoot coming up in a couple weeks that is going to entail both DVCPRO HD, AVCHD, and likely HDV. I don’t question that CS5.5 will be able to handle it, but I suspect by the end of the edit, I’ll really want it to be over with! There’s really not much more to be said about it; do you have any particular questions?
Thanks again for your comments.
Posted by .(JavaScript must be enabled to view this email address) on 05/20 at 05:36 AM
Mr. Brougham,
Thanks for taking the time share your thoughtful views re my comments.
I’m just trying to help those people laboring under the misconception that transcoding makes a copy of the original and that the copy therefore must be degraded in quality. The evidence seen by many pros and the reputation of Cineform and Prores, for example is quite solid. I don’t make movies. The high quality and ease of editing make it appropriate for anything I produce.
As I said, I doubt all of the many ProRes converts thinking about coming over to Adobe from FCP will be eagerly abandon ProRes in favor of native. They don’t think transcoding is a degradation at all.
Premiere users should remember that when HDV long GOP MPEG hit market, it was Cineform’s codec, licensed by Adobe and built-in as a project preset, performing a transcode to Cineform on ingest. People didn’t complain that their quality was in any way being degraded.
They probably thought that since they didn’t have to go buy a third party plugin to edit HDV (and that the transcode was happening on ingest) they thought they were editing natively.
A lot of people could have been a lot happier editing video coming out of the prosumer cameras over the last several years - without the need for screaming computers had they just gotten over the false notions re transcoding. Many, like me, did a long time ago.
Personally, I think Adobe made a mistake in not acquiring Cineform, if they ever considered it.
I really don’t have any questions re multicam other than what Nvidia card is up to the task of 4 simultaneous streams?
Re the four-stream limitation and annoying quirks: I hope more writers expose this in detail. Adobe listens to people like you more than they listen to me.
Thanks again for your time and your insights here.
Posted by wsmith on 05/21 at 10:03 AM
OK, so there’s some bad info on the supposed benefits of transcoding from 8 bit to 10 bit here. Here’s the fact: Transcoding from 8 bit to 10 bit will do one thing, and one thing only: Increase your file size.
That’s the short version. If you need more info, keep on reading.
FCP users need to re-learn and understand a few things: Premiere Pro works directly from the source file, and that is the best data you can get. It’s the original, and nothing can be better. Period! Saying anything else tells me you believe in magic. That’s OK, but it will not help you as an editor.
Transcoding it to 10 bit will not magically increase the bit depth of the material. It will just put those levels that used to be 0-255 into a 0-1023 grid. But there will be no pixels with the value 1, 2 or 3 (or 17, 18 19) in the 10 bit file. You will get pixels with levels 0, 4, 8, 12, 16, 20 etc., but none in between. So when pushing this in post in 32-bit, you get EXACTLY the same result at when using the original.
Here’s the reason why so many people get this wrong: It doesn’t work this way in FCP! FCP (until FCP X I presume) tricks you into working in 8-bit color with 8-bit footage, and to work in 10-bit color with 10-bit footage. Premiere Pro is MUCH smarter. It lets you work in 32-bit color space no matter what bit depth your footage has!!! Yes, that’s 32 bits per color, floating point. The Gold Standard of color processing!
So when color correcting or compositing 8-bit material in Premiere Pro, you will still get those in-between pixel values that you want to get from working in 10 bit. And they will be more accurately represented because of the 32-bit color space.
Of course, to retain as much as possible of the perfect colors you get from working in 32 bit with your 8-bit files, you need to export to 10-bit or higher. But even when going back to 8-bit your quality will beat (or at least match) everything you can get from converting your files first.
So the misconception here lies in the fact that people do not understand the difference between shooting in 8-bit and editing in 8-bit. Pushing 8-bit material in 8-bit (that’s FCP) will not give you a good result. Pushing 8-bit material in 32-bit (Premiere Pro, DaVinci etc.) will look as good as that footage can ever look.
No need to fill up your hard drives with large transcode files. Just use the original - it truly is the best you can get.
(Of course, if you transcode from an inter-frame codec to an intra-frame codec, like MPEG to Cineform or ProRes, it will also play back smoother on a slow PC or Mac, but that’s not what was discussed above).
Shameless plug: More on this in my upcoming book: The Cool Stuff in Premiere Pro. 
Posted by .(JavaScript must be enabled to view this email address) on 05/22 at 05:55 AM
Mr. Leirpoll
You said: “(Of course, if you transcode from an inter-frame codec to an intra-frame codec, like MPEG to Cineform or ProRes, it will also play back smoother on a slow PC or Mac, but that’s not what was discussed above).”
I certainly did make the case re ‘ease of editing’ - as the other leading reason for transcoding). However Cineform, unlike ProRes is not an intra-frame codec.
Cineform is a wavelet based scheme, and completely unlike intra-frame. In the opinion of many technically-minded pros, wavelet is superior to macro-block schemes. The entire frame is compressed at at once rather than by blocks of the frame.
To further argue for the superiority of wavelet schemes, consider that leading high-end cameras are embracing wavelet. RED uses wavelet. Silicon Imaging’s SI 2K camera, which was used for Slumdog Millionaire (Oscar for best cinematography) and now, “127 Hours”, uses Cineform to acquire internally. GoPros sport cameras will begin using Cineform now that GoPro owns them. (not sure what they were using until now). I’m not saying that one should transcode macro-block-compressed material to a wavelet scheme simply because those high-end camera use wavelet. I’m just bolstering the notion that wavelet is intrinsically superior. Ergo it is also better for post even if material was acquired via a macro-block scheme, in-camera.
I personally observe that many aspiring video pros just want to be purists and they desperately (and, if I may say it, perhaps neurotically) want to “be pure and deal directly with the source.”
Many pros have been willing to devote some mind-share to transcoding to a superior editing codec. Doing so certainly meet their expectations and their customer’s needs.
And what about 3D post? Editing 3D natively is some time off in the future and that’s primarily due to the increased computer horse-power that is required. Transcode it to Cineform and 3D is not a problem. But you’ll have to swallow your purist pride and transcode. Pros will happily transcode to Cineform and they will probably continue to use it after it is ‘native’. Unless that ‘native’ 3D editing also increases 8bit,4:2:0 to 10bit, 4:2:2 and also makes it easier to edit without an even faster machine than is required to edit 2D natively right now!
Again, let’s see what the reaction is when Adobe tells longtime FCP users that they should adopt Premiere Pro to enjoy the benefits of native editing and they can thus abandon transcoding to ProRes as obsolete!
Finally, I want to say that “native” is all good. The Mercury engine’s acceleration is all good. The GPU utilization is all good. And transcoding is also all good. Don’t let the word “transcoding” unnecessarily be your bête noire. Cineform’s technical info is on their site for those who are not afraid.
Posted by wsmith on 05/22 at 11:09 AM
(Due to my correctly entered captcha code not being accepted, I needed to copy my original post and close this page and then recall it to paste my post. During that process certain important points I was making were inadvertently deleted.)
Here they are:
Your first statement: “Transcoding from 8 bit to 10 bit will do one thing, and one thing only: Increase your file size.”
The many ProRes and Cineform devotees out there don’t happily suffering dramatically larger files sizes without getting a lot of benefits in return. The statement is glaringly false.
As with uncompressed, which, increasingly, people are adopting via Blackmagic workflows for example, transcoding does indeed require more drive space. That’s a small price to pay and a trivial matter for pros who want high quality and ease of editing
I’ve never used FCP. I’m sure I don’t labor under the false conceptions/confusion re how it works compared to Premiere that you describe.
Notwithstanding your technical summary I think this has all been boiled down by the entire industry as a simple truism that most people can more easily grasp: 10 bit holds up better in post (even if the footage was acquired by an 8bit camera.) That simple truism is undisputed by the entire pro industry and more casual users don’t need to accept anything more than that. 10bit source hold up better than 8bit source in post. 8bit files transcoded to 10bit hold up better in post.
You said: “Premiere Pro works directly from the source file, and that is the best data you can get. It’s the original, and nothing can be better. Period!”
Arguably, in the eyes of many the most credible pros in this industry, having a visually lossless, 10bit, 4:2:2 file is far better than an 8bit, 4:2:0 file, period.
Important: You have never heard - nor will you ever hear - that transcoding to ProRes or Cineform has in any way degraded the quality of their footage or that their highly discerning customers have ever complained. I challenge you or anyone else to credibly dispute this simple statement of fact. (unless, perhaps, they transcoded to Prores or Cineform from uncompressed…) Even then I would doubt a serious complaint has ever been raised.
You said: “Of course, to retain as much as possible of the perfect colors you get from working in 32 bit with your 8-bit files, you need to export to 10-bit or higher. But even when going back to 8-bit your quality will beat (or at least match) everything you can get from converting your files first.”
I have to ask: When your 8bit file degrades during heavy compositing in an 8bit, multi-generational post workflow, how is it file ever going to be rescued by simply exporting it to 10bit? Nay, transcoding 8bit to 10bit, posting it in 10bit and exporting as 10bit is only logical workflow.
You said: “Transcoding it to 10 bit will not magically increase the bit depth of the material.”
I beg to differ. The chroma is interpolated up from 4:2:0 to 4:2:2. and the whole data structure is spread across a bigger space/grid. Technically there is no real increase in available colors but the bit depth of the whole thing is certainly increased. Increased bit depth is what makes transcoding so worthwhile.
(Note: Again, the system refused to accept my correctly entered captcha code so I again copied my addendum here, recalled this page anew, and pasted it in. I think the captcha code is timing out or something)
Posted by wsmith on 05/22 at 12:27 PM
wsmith said: “Cineform, unlike ProRes is not an intra-frame codec”.
Well, on Cineform’s web pages, it seems like it is. It’s described as a “Full-frame Wavelet compression”. No inter-frame compression is mentioned, so I still believe that Cineform is an Intra-frame codec (meaning it codes each frame individually, without looking at previous or coming frames). Wavelet, yes - Inter-frame, no - ergo intra-frame. But that’s not really what I wanted to comment.
Wavelet codecs are great! No question about that. So if your camera system can record in Cineform directly, by all means do so. And if you do 3D work, Cineform is THE way to go.
If transcoding your other material in some strange psychological way makes you happier, then keep on doing it, wasting time and hard drive space while I’m already editing in real-time from the original.
Do you need to transcode to Cineform for normal 2D editing in Premiere Pro. Absolutely not! Only if your hardware is too slow. I work natively with DSLR footage and XDCAM-EX routinely, and never had a problem with performance. (I have a four year old quad core with 8 GB RAM and a good Nvidia card. Not a High Performance system at all, but it does the job).
If I understand you correctly, you still seem to argue that transcoding to Cineform will magically make your images look better after post: “wavelet is intrinsically superior. Ergo it is also better for post even if material was acquired via a macro-block scheme, in-camera”. That’s correct if you mean that it’s easier on the hardware, and your hardware is not up to the task. But if you still mean that it will give you a better quality image, it’s just wrong. It can never be better than the original. No such magic. My apologies if better image quality was not what you meant.
BTW: I would definitely transcode my material if _not_ doing so slowed me down in any way. Luckily, it doesn’t.
I think my point of view can be summarized like this: Transcoding does no good unless it’s needed. And working in 2D in Premiere Pro means there’s no need.
Posted by .(JavaScript must be enabled to view this email address) on 05/22 at 12:31 PM
wsmith said: “I have to ask: When your 8bit file degrades during heavy compositing in an 8bit, multi-generational post workflow, how is it file ever going to be rescued by simply exporting it to 10bit? Nay, transcoding 8bit to 10bit, posting it in 10bit and exporting as 10bit is only logical workflow”.
I never said anything about 8-bit multi-generation workflow. That’s an entirely different case. I was talking about single-generation 32-bit editing in Premiere Pro. Only that.
Your comments are starting to look pretty nasty to me, so I will keep this short. You are certainly entitled to believe that up-ressing your chroma and transcoding to 10-bit will do some magic. But why don’t you just test all this and see for yourself?
It’s easy: Use an 8-bit source file. Do some color correction to it natively in Premiere Pro. Then transcode to 10-bit Cineform, and do the exact same color correction (copy and paste). Now export both to Cineform. Put these two exports side-by side in a larger image and try spotting the difference. Then do the ultimate test: Put one upon the other and set the uppermost to Difference mode. If all you see is black, you’re looking at identical images. If you see any gray or white, there are differences.
Please post your results, so we can all be educated.
Posted by .(JavaScript must be enabled to view this email address) on 05/22 at 12:47 PM
For those who want to know more about transcoding, spend 9 minutes watching Jason Levine on Adobe TV.
http://tv.adobe.com/watch/premiere-pro-cs5-feature-tour/staying-native-or-going-intermediate-transcoding-and-premiere-pro-cs5-/
Posted by .(JavaScript must be enabled to view this email address) on 05/22 at 01:17 PM
Don’t know if Shane Hurlbot, ASC, is pro enough to count for wsmith, but here’s at least one person telling us that his images look better in Premiere Pro native editing than in the competitors systems. He specifically mentions it looking much better than ProRes. He does not specifically mention Cineform, though, but at least the editor that did the comparisons (Jacob Rosenberg) has access to Cineform.
http://tv.adobe.com/watch/shooting-and-editing-hdslr-video-using-adobe-tools/shane-hurlbut-on-using-adobe-premiere-pro-cs5-to-edit-act-of-valor/
http://tv.adobe.com/watch/shooting-and-editing-hdslr-video-using-adobe-tools/shane-hurlbut-on-using-adobe-premiere-pro-cs5-to-edit-dslr-footage/
Posted by .(JavaScript must be enabled to view this email address) on 05/22 at 01:53 PM
Sorry you perceive any nastiness. Not intended and I’m sure that if we were face to face in a group in this discussion, I am certain neither you or anyone present would feel the same way. I’m just offering what I feel is valid pushback. If we both need to expound further to make ourselves more clear and precise, then I say by all means! I did say “neurotic” but I was referring to the aspiring masses. No nastiness here, I promise.
Re your first response: Fair point re intra-frame schemes. To be more precise, I should make the following distinction: Intra-frame compresses the entire frame but in macro-blocks of pixels - until all macro-blocks are compressed, whereas wavelet does the whole frame all at once. I believe that the word “intra” was first coined to describe certain MPEG compression schemes. I guess I just make a subconscious mental distinction between intra and wavelet.
Like the other Cineform devotees I do indeed believe that I get a picture every “visual-bit” as good as the original and that the quality is better maintained throughout post. I really don’t think many would denied that.
Who needs a copy is that better than the original? to I do dispute that nothing can be as good as the original. Our experience in this digital domain that we work in proves digital copies can be every bit as good. I know I can output an uncompressed file from a compressed file (no matter what the originating file’s quality) and the uncompressed copy is every bit as good. To all eyes that look at it.
I also understand know that their can be degradation of digital copies that are copied digitally - due to less I/0 precision, i.e. lower bit depth.
You see, increasing the bit depth provides higher I/O precision of a file constantly going through compression-decompression during post, even if that post isn’t multi-generational. The lower precision I/O of 8bit files leads to far more degradation post than with 10bit files.
You said: “BTW: I would definitely transcode my material if _not_ doing so slowed me down in any way. Luckily, it doesn’t.”
I’m puzzled as to why if it provides no other technical benefits.
You then said: “I think my point of view can be summarized like this: Transcoding does no good unless it’s needed. And working in 2D in Premiere Pro means there’s no need.”
I strongly disagree and I must say that an awful lot of credible people in this industry agree with me. Transcoding to 10bit Cineform or ProRes most certainly does bestow very real technical benefits.
No need to test this myself; I’ve read it all as performed by other pros and third-party testers. I’ve seen credible computer based PQAs (Picture Quality Analysis, for those who don’t know). I’ve heard the many credible and successful pros extol its technical virtues.
Without needing Mercury and fancy GPUs, or even 64bit (which I only upgraded to within the last year) I’ve personally made money with Cineform, with some pretty discerning and demanding customers. Steady customers, I should add.
Posted by wsmith on 05/22 at 02:11 PM
wsmith said: “No need to test this myself”
I thought as much…
wsmith said: “You see, increasing the bit depth provides higher I/O precision of a file constantly going through compression-decompression during post, even if that post isn’t multi-generational. The lower precision I/O of 8bit files leads to far more degradation post than with 10bit files”.
I know of no workflow in Premiere Pro that is not multi-generational and still has the file “constantly going through compression-decompression”. Please tell us which specific workflow or set-up would do this. I’m writing a book on this software, I use it for all my films, in fact I’ve used it since version 1.0, and I’m an Adobe Certified Expert in Premiere Pro, so I would really, seriously like to know!
The Premiere Pro workflow that would make sense in a production environment where files are sent from system to system, a true multi-generation workflow, would be this:
1. Edit 8-bit source natively in Premiere 32-bit color, export to a 10-bit file
2. Import that 10-bit file in the next system,and edit in 10-bit or (preferably) 32-bit
3. Export to 10-bit again
4. Etc.
Still, the first generation edit (from source files) gains nothing at all by being transcoded to 10-bit. Only when doing multiple generations can 10-bit give any quality benefits with 8-bit source material.
Posted by .(JavaScript must be enabled to view this email address) on 05/22 at 02:34 PM
You said: “I thought as much…” Indeed, I told you as much. I’ve seen all the tests I need to see. I’ve seen the test that conclusively demonstrates how Cineform 4:4;4 RAW is every bit the visual equal of HDCam SR. I saw the awards they’ve garnered for quality and innovation. I doubt anyone ever got fired for adopting Cineform instead of native.
Now to your technical questions:
Anytime video is being displayed in post the video is very quickly decoded (cannot be displayed unless decoded). Then, as quickly as the cursor moves past that particular point in the timeline, that video behind the cursor is re-encoded.
The video is constantly being un-encoded for displaying and then quickly re-encoded after displaying it is no longer required. Increased I/O precision of 10 bit files will allow a 10 bit capable monitor to receive a 10bit video file in all of its glory as the file is being played or scrubbed. The I/O precision is a big factor in accurate 10bit display, of course. So there’s your non multi-generational post scenario that doesn’t involve an export to another system.
You said: “Still, the first generation edit (from source files) gains nothing at all by being transcoded to 10-bit. Only when doing multiple generations can 10-bit give any quality benefits with 8-bit source material.”
See above.
See also: Arthur C. Clark, who famously said “Any sufficiently advanced technology is indistinguishable from magic.”
And that prompts me to observe the following: When you have a transcoded video file that looks every bit as good as the original to 20/20 humanoid vision, and holds together better in heavy post, displays more accurately and edits multiple streams like a hot knife cuts through warm butter, then yes, I’ll continue to believe in certain kinds of technological magic.
Posted by wsmith on 05/22 at 06:55 PM
wsmith said: “Anytime video is being displayed in post the video is very quickly decoded (cannot be displayed unless decoded). Then, as quickly as the cursor moves past that particular point in the timeline, that video behind the cursor is re-encoded”.
You can’t be serious? Do you actually think that the video on your timeline goes through the graphics card and monitor and back to the timeline? I really hope you’re joking. This is so wrong I don’t know where to start. You seriously need to read about how digital video is processed in a PC or Mac. This is just far out.
I can assure you that my DreamColor monitor gets a 10-bit image from the Nvidia card when I edit my 8-bit source in 32-bit color space. The proof lies in the lack of banding.
You continue to argue that Cineform is great. Yes it is, but that doesn’t mean we should always use it. Use it when your editing experience or quality gets better. In all other cases, it’s a waste of time.
Yes, in a multi-generation workflow, a 10-bit output file is needed AFTER editing the 8-bit source. That’s another story.
Before you argue any further, please do me a favor. Sit down with Premiere Pro (free trial available) on a system with one of the approved Nvidia cards and just try some of this stuff. You will be amazed when you see that it just works, and that the image quality is the best you can ever get.
Did you watch the video with Jason Levine above at all? I think he explains this quite clearly.
Posted by .(JavaScript must be enabled to view this email address) on 05/22 at 09:33 PM
Not sure how we got off on this particular sidetrack and I may not be an expert on exactly what goes on inside the guts of a PC but the video is on the hard drive, gets called, gets decoded, is displayed. And if processed in any way, the modified file is written back to the drive.
Those are all I/O operations that are not multi-generational. The more precise the files (10bit versus 8bit) the more accurately a monitor can display the data. Degradation can happen here due to faulty I/O hardware, poorly written I/O drivers, etc. Importing files into/out of Premiere (or any NLE) is also an I/O operation and subject to the degree of I/O precision, which corresponds to the file’s bit depth.
I think my illustration re feeding a 10bit monitor with a 10bit signal is a valid one. I/O precision of the file is important if you expect the monitor to display at its full potential.
You may be able to convince others that one can work on a file at 8bit in post, perform heavy compositing, and then just export it as clean 10bit. Either video is 10bit or it’s not. It’s either 4:2:2 or it’s not. I’m sure some kind of floating magic can be invoked to display it as if it were 10bit.
I just watched the video by Jason Levine and admit to learning something not learned in the other many videos, print reviews and by hanging out on their site for a fair amount of time. It interpolates chroma up to 4:4:4. I also hear about this “32bit float” that you reference. I want to see exactly what that means technically. Some way to interpolate the color up for display purposes, I assume. All of the assorted video clips on a timeline need to be homogenized to a highest common denominator, in order for the open timeline concept to work, I again suppose.
However, apparently, the bit depth of the file itself isn’t being boosted; only the color sampling is.
Does not negate the fact that working on 10bit files is more precise and more display-accurate, (on a 10bit monitor.) I think you are misinformed re your monitor getting 10bits from an 8bit file - notwithstanding any 32bit “float” and interpolation of color up to 4:4:4.
You said: “You continue to argue that Cineform is great. Yes it is, but that doesn’t mean we should always use it. Use it when your editing experience or quality gets better. In all other cases, it’s a waste of time.”
I never said we should use it all the time. I’m just pushing back on Adobe’s apparent marketing effort to deprecate it - on technical grounds, as obsolete. As I said, it’ll be quite interesting to see if there’s a similar deprecation of ProRes if/when Apple also gets on the ‘native’ bandwagon. And what about the DNxHD users? Are they all going to go native so willingly? Digital intermediate users are going to need convincing re quality.
You said: “Use it when your editing experience or quality gets better. In all other cases, it’s a waste of time.” (I assume you mean “when you want a better editing experience or quality.”)
That seems like an endorsement but I’m left unclear on why, in your view, it might provide better quality than is available natively. Achieving better quality wouldn’t be a waste of time for me. Transcoding only to achieve quality equal to native would indeed be a waste of time. But I don’t think Premiere’s interpolating chroma is the same as working on a 10bit file or displaying true 10bit. Levine’s video don’t explicitly say that.
I’ll be happy being able to continue using Cineform on certain clips, in a mixed media timeline containing other formats. Having active metadata and Firstlight-like nondestructive color correction would be nice too. That’s addictive.
Interestingly, CS5.5 supports RED R3D files natively. Inasmuch as that is wavelet, I assume that Adobe has included a separate processing pipeline just to handle those wave files (When Cineform is installed as a plugin, Cineform needs to replace Premiere’s processing pipeline so that wavelet files can be processed.) That’s a very different engine than one designed for processing macro-block schemes. I wonder if there are now 2 separate pipelines in Premiere?
Funny re getting a trial version of Premiere to try out. I have as many as 4 simultaneous licenses in the past and have used it since the very beginning. I’ll skip the trial and just go for it when I build the new box. It is what it is and I’ll just go with it. I know I can always use the Cineform plugin if I wish.
I’m sure the new version of Premiere is amazing in that it “just works”. Cineform and the other intermediates have allowed me and others to “just work” work for quite a while now - without Mercury and native. That was my main point here and that transcoding can still be a very technically worthwhile process and by no means is it a waste of time. Nor just a creator of unnecessarily big files that serve no legit technical purpose.
The next new corporate account I open, with an owner who wishes to have copies of productions on their laptop to review, I know Cineform, not native is what I’d have to advise. When their in-house people wish to make editorial changes on their laptops, cross-platform Cineform is the only real practical answer right now. Been there, done that in the past and it’s like butter on middle of the road corporate windows laptops. If I work on a film, it’ll naturally be Cineform.
Personally Adobe is hyping native when that concept should be deprecated as inferior. Aside from the wavelet schemes used by certain high-end cameras internally, none of the acquisition codecs are truly up to the task of advanced post production in the way that Cineform is. And it’s really a pretty comprehensive workflow solution, not just a codec.
I think I’ve offered valid counter-arguments to Adobe’s deprecation of intermediates. I appreciate your insights on the matter.
Posted by wsmith on 05/23 at 09:36 AM
Dear wsmith: You just don’t get how everything you throw at Premiere Pro will be processed in 32-bit, making that 10-bit transcode of yours totally redundant. Your questions show that clearly. That’s OK. You can continue to believe in magic. I just wish you could stop making false statements about something you don’t understand.
I do hope that everyone else reading this are willing to read about the 32-bit color space and native editing workflow and actually understand it, instead of arguing against it without knowing what it is.
Oh, well. Back to work. Today: Color correcting in 32-bit float!
Posted by .(JavaScript must be enabled to view this email address) on 05/23 at 10:08 AM
Well, please tell me where this technical info is. I haven’t seen anyone else around here or other sites I visit talking about this. Honestly this is the first and only time I’ve heard the universally and technical accepted superiority of 10bit over 8bit deprecated.
I devote more than a fair amount of attention to the latest developments. Nobody around this site, for example, that I’m aware of,has similarly deprecated 10bit, the wisdom and utility of transcoding 8bit to 10bit, or extolling the supposed virtues of “32bit floating point” color at all, let alone so much so as to suggest that working in 10bit is suddenly passe.
You are the first to tell me this, my friend. Any references? Do I have to buy the book in order to learn all about this?
I may not be a computer scientist re all the exact internal workings of the PC. My info on that may be hazy but I understand video editing and codecs enough to have earned a living as a pro for years.
I’ll believe what you and Adobe are selling if it’s all shown to be true. Sorry but I haven’t arrived there yet.
One would think that this big advancement would have been more loudly proclaimed by Adobe marketing people at NAB. I didn’t hear anybody even mention it.
Posted by wsmith on 05/23 at 10:33 AM
I just watched Chris Meyer’s excellent video on “32 floating point color” in After Effects, created in 2007 but highly informative. It only references various creative uses, working with HDRs, or rescuing lost highlights.
http://www.lynda.com/After-Effects-training/hot-looks-using-floating-point-in-after-effects/483-2C.html
Posted by wsmith on 05/23 at 10:55 AM
(Yikes—looks like I started a food fight!)
wsmith: Check out Karl Soule’s post about how this pertains to Premiere Pro (CS5, but applies to CS5.5 as well):
http://blogs.adobe.com/VideoRoad/2010/06/color_subsampling_or_what_is_4.html
Posted by .(JavaScript must be enabled to view this email address) on 05/23 at 11:02 AM
This post by Karl Soulé might be even more relevant:
http://blogs.adobe.com/VideoRoad/2010/06/understanding_color_processing.html
Posted by .(JavaScript must be enabled to view this email address) on 05/23 at 11:09 AM
As it happens I’m reading Soulé in this link at the moment. I’ve seen his writing around here but have not seen this one here.
http://blogs.adobe.com/VideoRoad/2010/06/understanding_color_processing.html
Posted by wsmith on 05/23 at 11:16 AM
Todd Kopriva of Adobe has been attempting to post, so the following is from him:
**************************
Jarle has done a good job of laying out some technical details here, but I think that things are getting a bit muddled on this comment thread. (Comments on a blog post are not a good way to have a threaded conversation, in general.)
If you want to continue this conversation on the Premiere Pro user-to-user forum, come on over:
http://forums.adobe.com/community/premiere
We spend a lot of time over there talking about the details of color processing, as you can see from threads like this:
http://forums.adobe.com/thread/825920
****************************
Posted by .(JavaScript must be enabled to view this email address) on 05/23 at 11:32 AM
Here is another blog post by Mr. Soulé. Below is a verbatim transcript of questions my by other readers:
Question:
“I used to use Premiere cs4, and I would convert my 5d footage to Cineform Avis for ease in editing. Now that I have cs5, Converting does not speed up the editing anymore so I asked the techs at Cineform if there was any reason to convert. They told me that when color grading it’s best to start with Cineform because the 4:2:2 is better to color grade with in Premiere. Is this not the case? I would love to remove this step from my workflow.”
Answer by Soulé:
“Cineform is still an excellent codec, and I still use it when I need to work both inside and outside of the Adobe Production Premium suite. I also LOVE the color controls and look-up tables (LUTs) available in First Light, and those color changes show up immediately in Premiere Pro.
Since Premiere Pro can do the upsampling to 4:4:4, 32bpc right in the timeline, it’s not a crucial step, but it can still add value to your pipeline.”
Question:
“Hi Karl
This was the kind of information I was looking for as I’m tired explaining why it’s not necessary to transcode to 4:4:4 whatever your footage codec is.
In fact grading is codec-independent as we grade images not codecs or file-formats.
It’s like adding effects on a old K7 output or burn the music on a CD first…your effects board doesn’t bother the source material, K7, CD, SACD…it just takes the sounds as is regardless it is 16khz/8bjts, 44khz/16bits or 96khz/24bits…”
This last question seems to miss the point Soulé makes in the above response: He says he “LOVES” the realtime color correction, LUTS Cineform provides as Premiere plugin. Non-destructive too. All made possible by Cineform’s active metadata. You must transcode to Cineform to get that - if you need or want it.
Posted by wsmith on 05/23 at 11:38 AM
Thanks, Colin.
I also was going to post the links to Karl’s articles, but it looks like those have been found without my help.
Posted by Todd_Kopriva on 05/23 at 11:39 AM
Mr. Brougham,
Thanks but I’m a bit wary. The mods will deprecate transcoding to a superior editing codec and boosting 8bit to 10bit as obsolete even more so over there…
Adobe can do message control over there more easily. Am I allowed to vigorously challenge “native” editing over there?
Actually I feel I’ve had my say here and have made quite valid counter-arguments re.
If I come over there, can learn all about how 32bit color rendering has made working in 10bit in post is now obsolete? I need to learn about how transcoding to 10bit is now a huge waste of time and only creates much bigger files.
Posted by wsmith on 05/23 at 12:01 PM
I wouldn’t worry about being censored; the forums are actually user-to-user forums, and while they do exist on the Adobe site at-large, they’re more moderated by users like you and me. I can tell you from first-hand experience that you can make a lot of racket without fear of retribution; I’ve been known to complain quite loudly about a few things that I don’t like 
That all said, don’t be surprised if you don’t find too many sympathetic ears/eyes; I suspect the vast and growing majority of Premiere users are abandoning intermediate codecs, at least for standard post-production work (e.g. not 3D, etc.) because they find little benefit to using an intermediate. I’ll not hazard which is better or worse—there is proof and opinion on all sides of the debate—but I would definitely suggest doing your own tests with camera originals and transcoded versions. Don’t buy the hype, regardless of where it comes from, until you are able to prove it to yourself. I think that is the only way you can settle on whether you are correct or feeling some sort of placebo effect… and regardless of how that shakes out, you may still have valid reasons for converting the files.
Whatever way it goes, rest assured that the files you want to edit will work just fine in Premiere Pro; I believe that’s where I was going with all of this 
Hope to see you the forums…
Posted by .(JavaScript must be enabled to view this email address) on 05/23 at 12:15 PM
Thanks, Mr Brougham,
I’ve already subjectively native v. intermediate (Cineform) and have firmly arrived at my conclusion a long time ago. Otherwise I wouldn’t have been able to offer such plausible pushback to the misbegotten notion that intermediate is a complete waste of time and only creates large files.
As I said, time will tell how successful Apple is if they too begin to deprecate transcoding to ProRes and extol native. Or if the DNxHD users will just walk away from that in favor of whatever native camera format they shot with.
Posted by wsmith on 05/23 at 12:50 PM
Hmm.. very interresting… Hope its gonna work fine
Posted by Jake001 on 06/07 at 08:38 AM
Premiere Pro CS5.5 ships with more than 160 sequence presets (see the category folders at right), each designed for a specific flavor of footage. Strictly speaking, any supported format can be edited in any sequence preset - but more on that later.
As an editor, you’re probably not always working with footage sourced from a video camera. Premiere Pro’s native format support capabilities have you covered. Have a PhotoJPEG QuickTime from a stock footage website? Import, and edit. Captured an analog tape to an uncompressed AVI using a third-party capture card? Import, and edit. Got an image sequence rendered from a 3D animation program? Import, and edit. The list at right gives you an idea of just how many file types (video and others) are supported.
