Den ultimata guiden till Premiere Pros renderingskvalitet och bitdjupsinställningar

Om du är osäker på Premiere Pros inställningar för Maximum Render Quality (MRQ) och Maximum Bit Depth (MBD), är du inte ensam. Det är ganska komplicerade saker och det hjälper inte att den officiella dokumentationen kan vara svår att hitta.

Så varför ser vi dessa i både sekvensinställningar och i exportinställningar? Och hur påverkar de vår video? I den här artikeln kommer vi att dyka ner i hur och när dessa inställningar fungerar, så att du kan göra det bästa valet för dina egna projekt.

Om du inte har tid att läsa alla tekniska detaljer kan du hoppa direkt till slutsatsen. (TL;DR slå bara på båda inställningarna i både sekvensinställningar och exportinställningar.)

I slutet av artikeln hittar du också de tester jag använde för att visa hur dessa inställningar påverkar exporttider och bildkvalitet. Dessa kommer att hänvisas till under artikeln.

Innehåll

Var hittar vi dessa inställningar?

Du hittar både Maximal renderingskvalitet och Maximala bitdjup inställningar på minst tre olika platser i Premiere Pro:I Ny sekvens dialogrutan i Sekvensinställningar och i Exportinställningar .

Om du skapar en ny sekvens manuellt i Premiere Pro (Arkiv> Ny> Sekvens ), kommer du att se den här dialogrutan.

Om du redan har skapat en sekvens och inte har uppmärksammat inställningarna kan du gå till Sekvensinställningar (Sekvens> Sekvensinställningar ) och ändra dem där.

När du exporterar din tidslinje ser du samma inställningar, en under Video flik och en i den nedre delen av rutan.

OK, med det ur vägen, låt oss se vad som händer när du aktiverar dessa inställningar i din sekvens.

Du kommer att bli varnad

Japp, om du väljer att aktivera någon av dessa två inställningar får du följande varning.

Det här är inte så skrämmande som det ser ut. Men om du tycker att det är en anledning till oro kan du gå till Inställningar för minne och ställa in den på Optimera rendering för minne . Eller ignorera meddelandet helt och hållet och tänk "Jag har massor av RAM" som de flesta av oss gör. Om du inte har en avancerad dator med ett superhögt antal kärnor bör du inte stöta på minnesrelaterade problem med någon av dessa inställningar. Jag har alltid mina minnesinställningar inställda på Optimera rendering för prestanda .

Även om varningen säger att det "rekommenderas" att ställa in detta på Minne , vissa användare har rapporterat att detta kommer att göra deras system mindre stabil. Jag lämnar den här inställningen till standard, vilket är Prestanda .

Vad gör Maximalt bitdjup?

Vid första anblicken verkar det som om Maximum Bit Depth switch tvingar helt enkelt Premiere Pro att återge effekter som stöds i 32-bitars med flyttalsnoggrannhet. Det här är bra eftersom det kommer att minska banding och andra artefakter samtidigt som det håller överljus och supersvart intakt, aldrig klippnivåer.

Omkopplaren för Maximum Bit Depth begär också 32-bitars float från importören, som annars bara är 8-bitars.

Vad säger Adobe?

Det här är förklaringen som Premiere Pro erbjuder dig när du håller pekaren över Rendera vid maximalt djup i Exportinställningarna.

"Återgivning vid maximalt bitdjup förbättrar videons kvalitet men ökar hur lång tid kodningen tar."

Detta kan vara förvirrande. Vad betyder "Förbättrar videons kvalitet" betyda? Denna förklaring är inte heller hela bilden:det gör den inte nödvändigtvis öka kodningstiden . Mer om detta senare.

Av någon anledning finns det inget verktygstips för Render at Maximum Depth i Premiere Pro 15.0, så du är överlåten till din egen tolkning för den.

Varför spelar det någon roll?

Låt oss ta en titt på renderingen av videoramar först. Detta kan göras i 8-bitars per kanal, eller i 32-bitars per kanal. Om du har valt GPU-rendering (CUDA, Metal eller OpenCL) i projektinställningarna kommer det alltid att göras i 32-bitars om du inte har använt effekter som inte är GPU-accelererade.

Om endast programvara väljs i projektinställningarna beror bitdjupet på Render vid maximalt djup växla. Om den är på kommer renderingen att göras i 32-bitars. Om inte, kommer det att göras i 8-bitars.

8-bitars betyder att resultatet av varje beräkning på bilden endast kan ha 256 möjliga nivåer per kanal (RGB eller YUV). Det är inte mycket noggrannhet. Med flera effekter på ett klipp betyder det att vi får avrundningsfel för varje beräkning, med risken att introducera banding och blockering.

I 32-bitars gör vi alla beräkningar med resultat som kan ha mer än 4 miljarder olika nivåer per kanal, så avrundningsfel med flera effekter elimineras helt. Vi kan också lagra nivåer långt över 100 % vitt och 0 % svart.

Här är ett bra test att göra om du vill se skillnaden mellan 32-bitars och 8-bitars rendering. Använd ett klipp med några höjdpunkter nära max.

Använd den gamla pålitliga (och föråldrade) RGB Curves-effekten för att tvinga fram nivåer långt över 100 % vita. (Du kan inte använda Lumetri Color för detta eftersom den klipper nivåer när den staplas.)

Låt oss nu lägga till ytterligare en instans av RGB-kurvor, där vi drar de vita neråt igen.

Eftersom vi renderar i 32-bitars med GPU:n klipptes inte överljuset och bilden ser normal ut. Låt oss nu byta till Endast programvara i projektinställningarna och se vad vi får.

Genom att rendera i 8-bitars klipp klipptes överljuset helt enkelt, och att sänka nivåerna igen gör bara de klippta nivåerna mörkare. Många detaljer går förlorade.

Låt oss nu aktivera Maximala bitdjup växla i sekvensinställningarna.

Det är nästan identiskt med resultatet vi fick med GPU-rendering. Så om du arbetar i programvaruläge bör du definitivt markera rutan Maximalt bitdjup .

Naturligtvis var detta extrema justeringar bara för att göra skillnaden uppenbar. Du skulle normalt inte göra detta. Men det slutar ofta med att vi har mer än en justering på ett klipp. Till exempel kan du lägga till en LOG till Rec.709 LUT som en källklippseffekt, sedan normalisera bilden i tidslinjen och sedan lägga till ett justeringslager med en look.

Det är tre justeringar på ett klipp, och alla mellannivåer som går över 100 % skulle klippas in i 8-bitars, vilket förlorar detaljer. Du kan också börja se banding i gradienter etc. Se till att du renderar i 32-bitars, och dessa problem är obefintliga.

Hur kan du se om ett klipp renderas i GPU-läge eller endast programvara?

Om du har aktiverat GPU-acceleration (CUDA, Metal eller OpenCL) i projektinställningar är det rimligt att anta att du alltid kommer att få den bästa algoritmen. Men det är inte alltid fallet, och det är mer komplext än det först verkar.

Om Endast programvara väljs i Projektinställningar, får du uppenbarligen mjukvarurendering. Men även när du väljer GPU-rendering i projektinställningarna kan vissa av dina klipp renderas med mjukvaruläge . Lägg till en icke-accelererad effekt eller övergång, så kommer en del av renderingen av varje bildruta att göras i 8-bitars, potentiellt klippningsnivåer och introducerar avrundningsfel och bandning.

Sådana icke-accelererade effekter inkluderar vanliga verktyg som Kameraskärpa och Oskarp mask . Dessa är inte skrivna för GPU:n och måste beräknas på CPU:n.

Se upp för den röda renderingsfältet

Återgivningsfältet kan ge dig några ledtrådar om vad som händer. Områden på tidslinjen utan renderingsfält alls har inga effekter, så det du ser borde vara vad du får. Om du har valt GPU-rendering i projektinställningar och du ser en gul renderingsstapel i tidslinjen, vet du också att du definitivt är i GPU-läge, och du är säker.

En röd renderingsstapel är ofta ett tecken på att du renderar i mjukvaruläge , men det är inte en tydlig identifiering. Det kan också indikera att du använder en GPU-accelererad effekt som behöver renderas, som Optical Flow ramblandning för Speed ​​eller Morph Cut övergång. Ja, de måste renderas - därav den röda renderingsfältet - men de kommer att renderas på GPU:n i 32-bitars. Så en röd renderingsstapel gör det inte alltid betyder att du är i mjukvaruläge.

Det visar sig att det inte finns något enkelt eller direkt sätt i tidslinjen att avgöra om en del av din rendering görs i mjukvaruläge. Så, hur kan du ta reda på om ett klipp som utlöser en röd renderingsstapel gör det på grund av mjukvarurendering eller inte?

Först måste du ta reda på om klippen i området med ett rött renderingsfält har effekter på dem. Det är den lätta delen. Om fx märket är grått, det finns inga effekter på klippet. Om den är gul bör du också vara bra, eftersom det betyder att bara de fasta effekterna (Motion, Opacitet etc.) har ändrats.

Om det finns en röd linje under märket har den en källklippseffekt, och om den är lila har du lagt till en effekt på klippet på tidslinjen. När den blir grön betyder det att du har använt en effekt och att du även har ändrat en eller flera av de fasta effekterna. Den korta versionen av detta är att du bara behöver oroa dig för klipp med grönt och lila märken och de med en röd linje under märket.

Du kan kontrollera panelen Effektkontroller för att se om något av dina klipp har en effekt som inte är GPU-aktiverad. Om klippen bara har GPU-accelererade effekter är du bra. Om ett eller flera klipp har en icke-accelererad effekt, kommer en del av beräkningarna att göras på CPU:n.

Om du inte vet vilka effekter som är GPU-accelererade kan du ta reda på det genom att titta på legoklossikonerna i effektpanelen.

Men panelen Effektkontroller visar bara effekter på ett klipp i taget, så det tar ett tag att gå igenom alla klipp. Här är ett snabbare sätt att se alla effekter på alla dessa klipp:Välj de klipp du vill inspektera och klicka på Redigera> Ta bort attribut . Detta kommer att visa alla effekter som har använts på dessa klipp.

Det kommer inte att visa vilket klipp som har vilken effekt, men du känner förmodligen din tidslinje tillräckligt väl för att ha en bra uppfattning om vad som har använts var.

Vad sägs om förhandsvisningsrenderingar?

Dina sekvensinställningar kommer normalt inte att påverka din slutliga export, eftersom panelen Exportinställningar har sina egna inställningar för maximalt bitdjup.

Om du planerar att använda förhandsvisningsrenderingar för export, kommer du att bli glad att veta att om du ställer in förhandsgranskningsfilformatet till något som ProRes 422 HQ kommer att avkoda och rendera dina förhandsvisningar i 10-bitars, även när sekvensen har Maximalt Bit Depth inställt på av. Så det är alltid säkert att använda högkvalitativa förhandsvisningsrenderingar.

Det här är bra, men det betyder också att du kommer att se en synlig förändring i bilden under videoöverlagringar som nedre tredjedelar om du renderar den delen av tidslinjen med maximalt bitdjup inställt på av i dina sekvensinställningar.

Maximalt bitdjup påverkar avkodningen av vissa format

Maximum Bit Depth-omkopplaren begär också 32-bitars float från importören, som annars bara är 8-bitars. Så ett föga känt faktum är att MBD också påverkar hur vissa videoformat importeras/avkodas . Det betyder att det kan påverka vissa videoformat mer än andra – även när du är i GPU-accelerationsläge.

För vissa format, som RED, krävs detta för att få HDR-pixlar. Till exempel är RED RAW 12-bitars, och Maximum Bit Depth väljer mellan att avkoda ramarna på 8-bitars jämfört med att använda hela 12-bitars.

Det finns ingen lista över vilka dessa format är, men redaktörer som använder ProRes bör veta att utan MBD-uppsättning kommer ProRes att avkodas i 8-bitars , även om ProRes-källan alltid är 10-bitars eller mer.

Så när du inte har den här omkopplaren aktiverad i Sequence Settings, kommer dina härliga ProRes-bilder sannolikt att visa banding i Program Monitor och i Lumetri Scopes.

Utan maximalt bitdjup kommer ProRes att avkodas i 8-bitars.

Så om du vill att din programmonitor ska visa något som liknar det slutliga resultatet medan du färggraderar, vill du definitivt aktivera maximalt bitdjup i sekvensinställningar.

Det ofta förbisedda djupvalet i exportinställningarna

Blanda inte ihop Rendera vid maximalt djup inställning med Djup inställning som visas omedelbart under den i Exportinställningar för vissa format. Rendera på maximalt djup kryssrutan hänvisar till noggrannheten i beräkningarna, medan djupinställningen nedan hänvisar till bitdjupet för kodningen.

Alltså Djupet inställningen avgör om den renderade filen ska ha 8-bitars video, 10-bitars eller mer. Så även med Rendera på maximalt djup markerad, och säkerställer att beräkningar görs i 32-bitars, kommer du faktiskt att exportera till 8-bitars video om du inte ställer in den på 16-bitar!

För att säkerställa utdata av hög kvalitet, använd alltid 16-bitars djup när du exporterar till ProRes

Av någon konstig anledning är alla förinställningar som standard 8-bitars – förmodligen ett val av prestanda framför kvalitet – men detta lämnar dig öppen för bandning och blockering.

Eftersom 8-bitars vs 16-bitars värdet inte lagras synligt i filen, kommer 8-bitarsfilen att låtsas att den är 10-bitars för alla smaker av ProRes 422 och 12/16-bitars i ProRes 4444. visas i egenskaper i Premiere Pro och i programvara som MediaInfo.

Det ljuger för dig.

Observera att när Smart Rendering startar har denna inställning ingen effekt. Men om du har en överlagring som ett textlager, eller om du har lagt till effekter som Lumetri, kommer Premiere Pro att exportera i 8-bitars om Depth inte är inställt på 16-bitars. Om du har gjort förhandsvisningar av segmentet och väljer Använd förhandsgranskningar, kommer inställningen inte att påverka utdata.

Observera också att Inställningar för matchningssekvens funktionen i Exportinställningar är inställd på Maximalt bitdjup om din sekvens har detta aktiverat, men djupet är inställt på 8-bitars, vilket gör även denna funktion oanvändbar för ProRes-export av hög kvalitet.

Vad gör Max Render Quality?

MRQ, när aktiv, ger dig skarpare bilder efter skalning eftersom det möjliggör en Lanczos av högre kvalitet interpolationsmetod istället för standardbilinjär. Det är därför det också ökar exporttiden när den är aktiv.

Låter ganska enkelt. Men påverkar det andra saker än skalning? Det kan du ge dig på. Och vilken typ av algoritmer tittar vi på här?

OK, men vad betyder "Bättre skalning" exakt?

För att svara på denna fråga, låt oss lämna Premiere Pro för tillfället och ta en titt på Photoshop istället. Du kanske har sett att Photoshop har flera skalningsalgoritmer att välja mellan. Bicubic, Bicubic Sharper, etc. Och de har alla olika för- och nackdelar.

Varför har vi så många att välja på? För skarp är inte alltid vad du vill ha. Vissa algoritmer är bättre för grafiska element och text, medan andra är bättre för "naturliga bilder". Vissa fungerar bättre när du skalar upp, medan andra fungerar bättre när du skalar ner. Colin Smith på PhotoshopCAFE har en bra förklaring i sin videohandledning.

Tillbaka till Premiere Pro, och "bättre" verkar lika med skarpare. Så det är det första lite felaktiga påståendet i den verktygstipstexten. Den andra felaktigheten är att den bara nämner Skalning, trots att den faktiskt påverkar alla Transform-alternativ, inklusive Skala, Position och Rotation – plus alla effekter som gör Skala, Position och Rotation, som Warp Stabilizer .

Precis som förklaringen för Max Bit Depth, är förklaringen i verktygstipset också fel:det gör den inte nödvändigtvis öka kodningstiden. Om du har aktiverat GPU-acceleration kommer det inte att öka kodningstiden. Se Test 7

När börjar det?

Om du bara har använt GPU-accelererade effekter och har en gul tidslinjerenderingsstapel, eller ingen stapel alls, kommer det inte kick in, eftersom GPU-skalningsalgoritmerna är ännu bättre – och ändå snabbare – eftersom de är klara på GPU:n.

Om renderingsfältet är rött kan det kick in. Mest troligt kommer det att göra det, eftersom du har använt en icke-accelererad effekt. Men det finns några undantag. Precis som alternativet Max Bit Depth kommer Max Render Quality inte kick in om renderingsfältet är rött eftersom du har använt morph cut och inte har renderat ännu. Den övergången renderas på GPU:n, så MRQ kommer inte att slå in.

Och kom ihåg—det påverkar Transformers (även om det bara nämner skalning i exportinställningarna). Så om du inte har skalat, flyttat eller roterat något, kommer det inte att göra sitt. Om du har justerat eller formaterat position, rotation eller skala (inklusive Skala eller Ange till ramstorlek) kan du ha utlöst dessa algoritmer.

Återigen, du kanske skalar utan att inse det. Till exempel Warp Stabilizer introducerar skalning, rotation och ompositionering. Och om du har använt standard Ange till ramstorlek , du kanske skalar utan att veta om det. Naturligtvis, om du matar ut till en annan storlek än din sekvens (säg, exporterar HD från en 4k-tidslinje), så är du definitivt är skalning.

Några fakta som kan överraska dig

Som du har sett är komplexitetsnivån förvånansvärt hög för ett så enkelt mål:Ge mig maximal kvalitet. Det är inte bara komplicerat, utan de olika inställningarna placeras i olika hörn av programvaran – och alla måste ställas in korrekt.

Många av oss kommer att kämpa för att hitta, förstå och tillämpa alla dessa inställningar korrekt.

Men det finns mer. Här är lite information som kanske inte överraskar dig.

Premiere Pro har flera olika skalningsalgoritmer

Adobe beskrev hur och när de olika skalningsalgoritmerna fungerar i ett blogginlägg från 2010.

Här är en översikt som jag gjorde, uppdaterad med algoritmerna som används för uppspelning av hög kvalitet , vilket inte var något 2010.

Du ser normalt inte full kvalitet i programövervakaren

Som du kan se i tabellen ovan använder Premiere Pro en snabb algoritm av lägre kvalitet för uppspelning som standard. Detta gör uppspelningen mindre krävande och kan vara det enda fungerande valet på mindre kapabla system. To see what you’ll get on export, and accurately judge the results, you’ll have to enable High Quality Playback in the Program Monitor settings menu.

With High Quality Playback enabled, Premiere Pro plays and scrubs the image using the same quality that’s used when the Playhead is paused. So you might find that your system struggles and starts dropping frames. In that’s the case, turn this feature off.

Your choices in Sequence Settings don’t matter that much

As we’ve seen (and to make things more complicated), both settings are available both in the sequence and in the export settings. If you take a look at the tests at the end of this article, you’ll see that your sequence settings have no impact on the quality of the exported file .

But if you want to know what you’re exporting, the sequence settings and the export settings have to match. If they’re set differently, the output won’t be the same as what you saw while editing. So I recommend that you keep MRQ and MBD settings matched.

Max Render Quality also affects the way color is rendered

As you’ll see in the Sequence settings, the Composite in Linear Color setting depends on GPU acceleration or Max Render Quality. So if this is on, as it is by default, activating Max Render Quality will also activate Composite in Linear Color when you’re in Software mode. And this will affect how your compositing, cross-dissolves, and color grading will look.

In Software mode, this also makes Premiere Pro blend in linear color for frame blending when you change Speed/Duration.

Max Render Quality affects how some formats are decoded

As we’ve seen, the Max Render Quality setting normally has no impact on our exports in GPU mode, because a superior scaling algorithm will be used on the GPU. But even with GPU rendering, MRQ can improve quality when working with footage that supports fractional resolution (Wavelet codecs, like RED for example), using full-resolution sources instead of a fractional resolution for the export when the image has been scaled down. See Test 14.

According to engineers and developers from Adobe, MRQ affects decisions made by RED, PNG, JPEG, HIEC, HIEF and WEBP importers. And they mention that this list will change over time, as well as what impact MRQ has on them.

Common Misconceptions

There are some statements that you’ll often see in forums, books and articles—even by Adobe evangelists—that don’t hold up to scrutiny. So let’s clear these up.

“Maximum Render Quality only affects scaling”

There are many versions of this misconception, but it usually goes a bit like this.

“Using Maximum Render Quality will not help unless you’re scaling up or down”.

Wrong . It also kicks in if you’re changing Rotation, Position, and other Transforms, or the Warp Stabilizer, which also does some scaling and other Transforms. But it only affects Software rendering. See Test 9

“Maximum Bit Depth doesn’t help if your source or destination file is 8-bit”

Since a lot of source files are 8-bit and we often export to 8-bit codecs, people tend to think that we don’t have to render effects in 32-bit. Here are two common statements.

“You don’t have to check Maximum Bit Depth, because H.264 and YouTube is 8-bit anyway.”

“You don’t need Maximum Bit Depth if your source material is 8-bit.”

Wrong. Even when the source and export are 8-bit, doing the decoding and all the internal calculations at 32-bit accuracy will make sure your consecutive adjustments (say, Lumetri on the source clip and a LUT or tweak on an added Adjustment Layer) don’t introduce clipping, banding and posterization.

This affects both GPU rendering and Software rendering, as you can see in Tests 3, 4 and 5.

Unfortunately, none of the presets in the new Quick Export have Maximum Bit Depth set. So, to get less banding and blocking when exporting using the standard export method, choose the same preset, you should activate MBD.

“When you have GPU acceleration enabled, the settings don’t matter”

This is true for MRQ, but only if your timeline does not have a red render bar due to non-accelerated effects, which forces you into Software rendering. For Max Bit Depth, it’s only true if you haven’t added any effects. See Test 3, 4, 7 and 8.

“The export will match what you see in the program monitor”

Not entirely true. To get WYSIWYG in the Program Monitor during playback, not just when playback is paused, you’ll have to enable High Quality Playback in the program monitor panel menu.

Effects and transitions like Morph Cut and Optical Flow need to be rendered to see the actual result. Also, when you’re rendering previews, you’ll need to render to a good codec, or else the result will not match your output.

If it’s rendered to the default I-frame Only MPEG-2 codec, you’ll get a bad preview compared to ProRes, DNxHR or CineForm codecs, which provide better-quality previews.

So it’s best to use codecs that are so good you can use them for export, enabling Use Previews in the export settings. Ideally, you should use the exact same format as you’ll use when you export your master file to get super-fast Smart Rendering and eliminate re-transcoding.

Render Previews if you’re editing in Software mode. During playback in Software mode, you’ll not get 32-bit rendering. Effects and compositing can look very different before and after rendering.

For example, graphics might get jagged edges during playback, and Linear compositing won’t be applied, which changes the look of blending modes, etc. By rendering your previews, you’ll get to see them in full quality, which is useful if your system can’t handle High Quality Playback.

Summing up

These MRQ and MBD settings affect the video quality at three different stages in the pipeline. The importer/decoder can be 8-bit or 32-bit, the processing of effects and transforms can be done in 8-bit or 32-bit, and finally the exporter can render to 8-bit, 10-bit, 16-bit, etc.

As we’ve seen, where these settings really matter is in your Export settings. Both Max Render Quality and Max Bit Depth have an impact on your image quality, although Max Render Quality mostly only kicks in when you’re in Software mode (which is entirely possible even with GPU acceleration turned on, see Test 11).

It’s hard to be definitive, but in many (most?) cases, leaving the settings on will not affect the export time.

For some sources, MRQ can make a difference even in GPU mode. MBD in export settings can also affect how some formats are decoded, even in GPU mode, most notably ProRes.

And finally, you should always enable 16-bit Depth for formats where this choice is available.

Unfortunately, in both Sequence Settings and in Export Settings, the defaults don’t have these settings enabled, so you’ll have to intervene to get the best quality video in Premiere Pro. The Quick Export has none of these settings enabled, and there’s no way you can change it.

If you want good quality video, always enable Maximum Bit Depth and Maximum Render Quality, and choose 16-bit instead of 8-bit for formats with a choice for Depth.

With all of this in mind, I recommend that you always have MBD and MRQ enabled in your export settings. If you want WYSIWYG, you should also enable both of them settings in your sequences. If your system struggles you may want to turn them off, and see if the exported files still meet your quality standards, knowing that it’s not top quality.

Most of the time, the settings will do nothing at all, but they will kick in when needed, and ensure the best possible quality.

Here’s what I do

You may be wondering what choices I have made, and how I set up my workflow. Here you go.

• I use Sequence Presets that have both settings activated
• The Sequence Presets use ProRes 422 HQ to get high-quality preview renders
• I’ve made a ProRes 422 HQ Export Preset with both settings activated
• The Export Preset also has Use Previews, and 16-bit Depth activated

The export to a master file is very quick if I’ve rendered parts of the timeline where there’s a red render bar, due to Smart Rendering (see Test 1 and 6). Of course, I don’t always have to render, but I sometimes render during breaks or when I’m on the phone, to save time on final export when Smart Rendering kicks in.

I also use Render &Replace for dynamic link comps, titles, MOGRTs etc.

For longer projects I will set up watch folders in Adobe Media Encoder to automatically take my exported master file and output the h.264 versions, using a preset with Maximum Bit Depth and Maximum Render Quality enabled. But for short-form projects I normally just queue these exports, which is fast and easy.

I hope the info in this article enables you to make qualified choices for these settings for future projects. This should enable you to improve your image quality and yield fewer surprises when you export your films.

Testing, testing

In the interests of transparency, here are the tests. (They were run on a 7-year old laptop, so you may laugh at some of the export times.)

Each test was an export of the same timeline with different settings enabled, with MRQ and MBD enabled and disabled, with and without GPU rendering, scaling on/off, etc. Here are the basic sequence settings and export settings.

During each export, I monitored the CPU and GPU usage, and timed every export. After each export, I performed a Difference Mode test, to see if any pixels had different values in the different versions.

My main testing timeline was a minute long and contained a 10-second clip repeated six times. The source file was 1920x1080px, ProRes 422 HQ, 29.97 fps, progressive. (This matched the export, so in the first test, Smart Rendering kicked in, and the export time was very short.) I also did a test with RED RAW footage.

Let me preface this by saying that these tests are not scientific. I had other software running in the background, and I timed the exports using the stopwatch app on my smartphone, so the timing may be off by at least one second, maybe more. But they’re enough for us to see how different settings affect the exported file and the time the export takes.

Test 1:Export to ProRes 422 HQ, No effects

Conclusion:When no effects are added, Premiere Pro uses Smart Rendering on this sequence, regardless of the Maximum Bit Depth value in the Sequence and Export settings. This is indicated by the very low CPU usage. Almost zero processing is going on, and the export is super fast.

Test 2:Comparison of exported files from test 1, Difference mode, No effects

Conclusion:All the files are identical. I could see no difference in the program monitor or in the scopes—the waveforms were a straight flat line. They were also exactly the same size, down to the byte.

Test 3:Export to ProRes 422 HQ, with Lumetri effect (RGB Curve), GPU enabled

The CPU was constantly around 100% on all cores, and GPU usage was between 40-90% for all exports. Only when the export setting is changed does the file size differ, and a fuzzy line shows in the scopes. Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is.

Conclusion:Export settings affect export times, and what algorithm is used. Sequence settings do not affect the exported files, unless you enable Use Previews in the export settings.

Test 4:Export to ProRes 422 HQ, with Lumetri effect (RGB Curve), GPU disabled

The CPU was constantly around 100% on all cores for all exports. When the export setting is changed the file sizes differ, and a fuzzy line also shows in the scopes. Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is.

Conclusion:Export settings affect export times, and what algorithm is used, but sequence settings do not, unless you enable Use Previews in the export settings.

Test 5:Difference mode, with Lumetri effect (RGB Curve)

Conclusion:Premiere Pro uses slightly different algorithms in CPU and GPU mode, so files exported with GPU enabled and GPU disabled are slightly different. The export settings make an impact on the exported file—sequence settings have no influence on the exported file, unless you enable Use Previews in the export settings.

Test 6:Export to ProRes 422 HQ, no scaling

Conclusion:When no scaling is going on, Premiere Pro uses Smart Rendering, and all the exported files are identical.

Test 7:Export to ProRes 422 HQ, with scaling set to 120%

The CPU was constantly around 100% on all cores for all exports. Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is. Files exported with GPU enabled and GPU disabled are slightly different.

Conclusion:Export settings affect export times in Software mode, and what algorithm is used, but Sequence settings have no impact on the exported files, unless you enable Use Previews in the export settings.

Test 8:Difference mode, with scaling

Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is. Only when the export setting is changed does the file size differ, and a fuzzy line shows in the scopes.

Conclusion:Premiere Pro uses slightly different algorithms in CPU and GPU mode. Export settings affect export times, and what algorithm is used, but Sequence settings have no impact on the exported files, unless you enable Use Previews in the export settings.

Test 9:Export to ProRes 422 HQ, with rotation set to 10 degrees, no scaling

CPU was constantly around 100% on all cores for all exports. Files exported with MBD on in export settings are identical (down to the byte) no matter what the sequence setting is. Files exported with MBD off in export settings are also identical (down to the byte) no matter what the sequence setting is.

Conclusion:Premiere Pro uses slightly different algorithms in CPU and GPU mode. Export settings affect export times, and what algorithm is used, but Sequence settings have no impact on the exported files, unless you enable Use Previews in the export settings.

Test 10:Difference mode, with rotation set to 10 degrees, no scaling

All files exported with GPU enabled are identical, no matter what the sequence or export settings are. Files exported with GPU disabled with MRQ off are identical whatever the sequence settings are. Files exported with GPU disabled with MRQ on are identical) whatever the sequence settings are.

Conclusion:Premiere Pro uses slightly different algorithms in CPU and GPU mode. Only when the export settings are changed does the file size differ, and a fuzzy line shows in the scopes. Sequence settings have no impact on the exported files, unless you enable Use Previews in the export settings.

Test 11:Export to ProRes 422 HQ, with scaling at 120% and Unsharp Mask effect at 0%

CPU was constantly around 100% on all cores for all exports. The two files are identical, down to the byte. GPU was not used, even though GPU acceleration was enabled.

Conclusion:Adding a non-accelerated effect to a clip forces Premiere into software only mode for the duration of the clip, even when the GPU acceleration is enabled in Project settings.

Test 12:RED source, Export to ProRes 422 HQ, MBD settings

The test was performed with a 5.5 seconds clip, R3D REDCODE 8:1, 3792x3160px (anamorphic), with Lumetri (RGB Curves), exported to ProRes 422 HQ at the same size. CPU usage was around 50% on all cores for all exports with GPU, and around 30-40% without the GPU.

The four files exported with GPU enabled are identical, down to the byte, and difference mode shows a straight line in the waveform scope. When comparing exports done with and without MBD with GPU disabled , the line is fuzzy. When comparing exports done with MBD with GPU disabled , the line is straight, and the files are identical, down to the byte. When comparing exports done without MBD with GPU disabled , the line is straight, and the files are identical, down to the byte.

Conclusion:The MBD setting in the export settings affects render times and the exported file only in Software mode. The MBD switch in the sequence settings does not affect the final render unless you check Use Previews in the export settings.

Test 13:RED source, Scaled, Export to ProRes 422 HQ, MRQ settings

The test was done with a 5.5 seconds clip, R3D REDCODE 8:1, 3792x3160px (anamorphic), scaled to 120%, exported to ProRes 422 HQ at the same size.

CPU usage was around 60% on all cores for all exports with GPU, about 50% for software exports without MRQ, and around 30-40% for software exports with MRQ. That feels kind of backwards, but that’s what the test showed.

All four files exported with GPU enabled are identical, down to the byte. The files exported with MRQ off and GPU acceleration off were identical, down to the byte. The files exported with MRQ on and GPU acceleration off were also identical, down to the byte.

Conclusion:when you’re in GPU mode, this setting does not matter (unless you have source files that support fractional resolutions). When you’re in Software mode, MRQ in export settings does affect the exported clip, while the sequence setting does not, unless you check Use Previews in export settings.

Test 14:RED source, Scaled to HD, Export to ProRes 422 HQ, MRQ settings

The test was done with a 5.5 seconds clip, R3D REDCODE 8:1, 3792x3160px (anamorphic), scaled to HD size using Set to Frame Size (25.3%) exported to ProRes 422 HQ HD.

CPU usage was 100% on all cores for both exports. The files are not identical at all, and a Difference mode test shows a thick fuzzy line. Surprisingly, the export done without MRQ seems sharper than the one exported with MRQ. But it’s also more pixelated, so leaving MRQ on results in a more pleasant-looking image with less noise.

Conclusion:With MRQ on, Premiere uses the full res image to create the low-res output. Without MRQ, it uses a partial resolution (half-res, quarter-res, etc.) that wavelet-based codecs like RED and some other formats have built-in. Even with GPU enabled, MRQ will affect exports of these formats.

Test 15:Cineform source, Scaled to HD, Export to ProRes 422 HQ, MRQ settings

The test was done with a 5.5 seconds clip, GoPro Cineform, 3792x1580px made from the RED clip.

The clip was scaled to HD size using Set to Frame Size (50,6%) exported to ProRes 422 HQ HD.CPU usage was 100% on all cores.

The clips are almost identical, but not quite (144 bytes difference in size). In Premiere, the scopes show a perfectly flat line, though, so the image quality is exactly the same.

I ran the test again with scale set to 50%, and the two files were identical.

Conclusion:Premiere Pro is probably not using partial resolutions when scaling Cineform clips without MRQ enabled. It may be using partial resolutions only when scaling to less than 50%.

Test 16:JPEG2k source, Scaled to HD, Export to ProRes 422 HQ, MRQ settings

The test was done with a 5.5 seconds clip, JPEG2000, 3792×1580, made from the RED clip.

The clip was scaled to HD size using Set to Frame Size (50.6%) exported to ProRes 422 HQ HD. CPU usage was 100% on all cores.

The files are identical, down to the byte. I did the test again with scale set to exactly 50%, and again those two files were identical.

Conclusion:Premiere Pro does not use partial resolutions when scaling JPEG2000 clips, unless it’s only used when scaling to less than 50%.

Test 17:Sony RAW Source, Scaled to HD, Export to ProRes 422 HQ, MRQ settings

The test was done with a 5.5 seconds Sony RAW clip. The clip was scaled to HD size using Set to Frame Size (46.9%) exported to ProRes 422 HQ HD. CPU usage was 100% on all cores.

The files are identical.

Conclusion:Premiere Pro does not use partial resolutions when scaling Sony RAW clips.