Premiere Frameserves SD in Rec 709?

[koberulz]

I'm using Advanced Frameserver to frameserve SD footage into an AviSynth script running SD2HD. Frameserving as YUY2. I get a color shift unless I add "input601=false" to the SD2HD script.

Does this mean if I frameserve SD content for SD output purposes I need to convert from 709? Or is there a way to get it to output in 601 in the first place?

[sneaker]

You only need to convert if YUV colors if you want to achieve are different than input. People usually do this when converting between SD and HD because players typically assume 601 colors for SD and 709 colors for HD. If your input is 601 SD and your target is also SD then you usually don't change colors at all.

I get a color shift unless I add "input601=false" to the SD2HD script.

You have to be very careful when trying to assess the output colors of an AviSynth() script. Some software like e.g. VirtualDub will typically assume 601 even for HD content. When you make screenshots or compare VirtualDub preview to your original file in a proper player like MPC-HC they might look different but when actually encoding and later playing they might look identical. For testing(!) add an extra line to the end of the AviSynth script: either ConvertToRGB(matrix="Rec709") (for scripts with HD output like in this case) or ConvertToRGB(matrix="Rec601") (for scripts with SD output). Remove the line before the actual encoding, it is only to get a proper preview.

[koberulz]

The shift is visible when importing the resulting AVI file into the Premiere project, dropping it onto the same sequence that was frameserved to create it, and turning that layer on and off.

[poisondeathray]

PP with SD sequence frameserving out with afs uses 601 in Adobe CC (probably CS6 too) . You can verify with avisynth and controlling the RGB conversion as sneaker suggested

If you're using SD2HD on the AVI signpost out of PP, that means you're upscaling to HD, so that script will convert in YUV 601=>709 using colormatrix . Everything is correct up to that point

But what you do from there is a lot of question marks - how did you convert to "resulting AVI" , what other conversions, how it was interpreted in premiere (what codec, did it treat it as RGB or YUV) , or did you frame serve back into PP etc...

[koberulz]

<blockquote>how did you convert to "resulting AVI"</blockquote>Video->Fast Recompress
Video->Compression->Lagarith YUY2
File->Save as AVI

what other conversions

None.

how it was interpreted in premiere (what codec, did it treat it as RGB or YUV)

Not sure how to determine this.

I ran color bars through the process, and scoping the result shows yellow shifted towards green, which is what I noticed in VDub in the first place.

Step by step to produce the attached frame:
1. Dropped color bars into my PAL SD sequence.
2. Frameserved as YUY2 with Advanced Frame Server.
3. Ran this:

AVISource("signpost.avi")
SD2HD(interlaced=true, OutputWidth=1920, widescreen = false, ScaleMethod=2, iHmax=2, iVmax=2)

4. Opened in VDub. Fast recompress to Lagarith AVI, YUY2.
5. Imported resulting AVI to Premiere.
6. Dropped AVI onto PAL SD sequence above the original color bars.
7. Scaled HD version to frame size, allowing direct comparison with the original SD bars in the letterbox area.

As you can see, they're not the same.

EDIT: Running the reverse, from HD color bars through HD2SD, results in a color shift in the other direction.

EDIT 2: To create Blu-Rays from Premiere sequences, I've been frameserving to an AviSynth script which I run through MeGUI. Had to add a 601->709 conversion to that script to prevent a color shift.

[poisondeathray]

This is one of those "gotchas" . PP doesn't treat lossless YUV codecs like lagarith in YUV mode as YUV , and they typically get rec601 treatment when imported into PP . So you can use the "wrong" colors as you have been doing a workaround (but you have to be careful if you plan to use that in other programs). Or another option is the Rec709 UT Video variant will get 709 treatment (but still be treated as RGB). Commonly used near lossless codecs like cineform, prores get treated properly and also as YUV ; but they are not truly lossless

[koberulz]

That would explain HD->HD or SD->HD color shifting, but how does that explain HD->SD shifting? Surely it goes out as 709 (HD source), gets converted to 601, then comes back as 601 and imports correctly? The initial input is a PNG sequence created from an After Effects comp, an MJPEG AVI, and a TS file. Is it ballsing those up as well? Surely at the very least it shouldn't have color-shifted its own color bars?

Is there a way to force Premiere to interpret it correctly?

I've actually switched to UT Video for my VHS restorations, as they'll need to be accessed on a Mac. I use Lagarith for everything else (including VHS intermediates) out of habit though.

I'm not sure what you mean about being careful using the wrong numbers as a workaround? Forcing HD to convert from 601 to 709 makes the colors correct, does it not? Or were you referring to something I overlooked?

[poisondeathray]

That would explain HD->HD or SD->HD color shifting, but how does that explain HD->SD shifting? Surely it goes out as 709 (HD source), gets converted to 601, then comes back as 601 and imports correctly? The initial input is a PNG sequence created from an After Effects comp, an MJPEG AVI, and a TS file. Is it ballsing those up as well? Surely at the very least it shouldn't have color-shifted its own color bars?

In that last case, the frameserver goes out as 601, even HD , at least in CC

But if you had RGB assets like a PNG sequence, then you should be frameserving RGB. Problem solved. If you had mixed YUV , RGB assets then it can get tricky

You can also diagnose what is going on at each step, by using avisynth and CONTROLLING the RGB conversion to "SEE" what is going on (see sneakers post) , and make adjustments. So direct output from frameserver, check what is being served. You maybe also want to check other things like levels, for example is something being clipped, or other conversions going on? Do this for EACH step, each stage. Because BAD things can happen when you just assume something is working as it should be. That's how you learn what is going on. All this PP behaviour has been explained before in other threads. Search for my old posts.

Is there a way to force Premiere to interpret it correctly?

No , not for 601 vs. 709. There is no a switch or toggle . Different input formats can get treated differently

I'm not sure what you mean about being careful using the wrong numbers as a workaround? Forcing HD to convert from 601 to 709 makes the colors correct, does it not? Or were you referring to something I overlooked?

I mean you have to DETERMINE what you actually have, especially if you use other programs. If you were to use that script with the fix into another program, you'd get the wrong colors (you're using "2 wrongs" to make a right in premiere) . You have to keep track of your fixes, because if another program handles lagarith YUV as YUV (e.g. avisynth, x264) , then you'll get the wrong colors there.

Also, I mentioned commonly used lossless YUV codecs are not "lossless" in PP - because they get converted to RGB . So that also means if you had superbright/superdark values (<16 or >235 in YUV) , they will get clipped . Also there will be rounding errors (conversion between YUV <=> RGB is lossy in most cases, unless it's done with higher bit depths). Depending on your source material or project specifics, this might be important.

For 8bit YUV422 , uncompressed "UYVY" will get completely lossless treatment in PP . This is the "magical" fourcc byte arrangement for 8bit 422 in PP (and actually most Windows NLE's) that gets complete passthrough and YUV treatment. But something like "YUY2" (also uncompressed YUV422, just different slightly different arrangement) will get clipped and treated as RGB

[koberulz]

you're using "2 wrongs" to make a right in premiere

I don't think you're understanding.

Premiere sequence -> Frameserve -> AviSynth matrix conversion -> MeGUI -> x264 -> Blu-Ray disc.

It never goes back into Premiere. Colors are correct when the disc is played on TV. From what you're saying, it's converting my source MJPEG to 601, and then it stays at 601 all the way through the process until the AviSynth script converts it to 709, which is correct.

[poisondeathray]

you're using "2 wrongs" to make a right in premiere

I don't think you're understanding.

Premiere sequence -> Frameserve -> AviSynth matrix conversion -> MeGUI -> x264 -> Blu-Ray disc.

It never goes back into Premiere. Colors are correct when the disc is played on TV. From what you're saying, it's converting my source MJPEG to 601, and then it stays at 601 all the way through the process until the AviSynth script converts it to 709, which is correct.

Initially you said you were re-importing an AVI and switching the layer on/ off , ie. back into premiere to check

MJPEG might get converted differently depending on how you have it setup (each asset might go through slightly different handling, and if you have other operations such as RGB filters)

Just check each step to see if/when something goes wrong. You should take control of the conversions to verify what is going on. Everything should make sense. Read my old premiere posts if you're lost. If you still have questions post the specific details of a specific case. Details are important

[koberulz]

MJPEG might get converted differently depending on how you have it setup

Different input formats can get treated differently

Are there settings somewhere for this? Is there a way to get it to treat YUV files as YUV?

But if you had RGB assets like a PNG sequence, then you should be frameserving RGB.

...good point. Force of habit. Still leaves the YUV MJPEGs and TS files though.

In that last case, the frameserver goes out as 601, even HD , at least in CC

I'm not sure what 'that last case' refers to here.

Is there anything in particular I should be reading? I'd imagine you have a lot of posts about a lot of things, and page load times are in excess of two minutes so searching through could take a while.

[poisondeathray]

Are there settings somewhere for this? Is there a way to get it to treat YUV files as YUV?

Unfortunately, no settings adjustments ; same with 601 vs 709 . You just have to know that different formats can get treated differently (same with other NLE's) . As a general rule , native camera formats get YUV treatment, and I listed a few intermediates above .

A simple way to test this in premiere is use a full range YUV source, and look at the waveform. If it's clipped, that indirectly indicates that it's been converted to RGB.

But if you had RGB assets like a PNG sequence, then you should be frameserving RGB.

...good point. Force of habit. Still leaves the YUV MJPEGs and TS files though.

If you're frameserving out with afs, it's still using 601 - you still might have to make adjustments after , depending on what the output formats were

But before that, on the timeline, you might have to make adjustments too, depending on what the TS is (TS can hold a variety of different formats, it's just a "container"), and how the mjpeg is handled. That's what the "mixed" format comment was alluding to

In that last case, the frameserver goes out as 601, even HD , at least in CC

I'm not sure what 'that last case' refers to here.

"the last case" refers to the last case in the quote - shifting it's own color bars. Regardless if you have SD or HD going out, afs seems to use 601 . You can verify this yourself with reading the signpost directly with avisynth and temporarily using ConvertToRGB24 with either 709 or 601 as sneaker suggested . But afs isn't really part of premiere, it's a 3rd party project, so it's not really pp's fault if there is a shift when using it. I already listed the "god mode" format, which is UYVY for 8bit YUV422. That gets passed through in/out losslessly when using a YUV timeline

Is there anything in particular I should be reading? I'd imagine you have a lot of posts about a lot of things, and page load times are in excess of two minutes so searching through could take a while.

I don't know? If you have a specific question regarding a topic, then that's what you read up on. If something doesn't make sense, then just do the simple tests with avisynth to verify, or ask if you can't figure it out.

[koberulz]

If you're frameserving out with afs, it's still using 601

So AFS converts to 601 regardless of source?

you still might have to make adjustments after , depending on what the output formats were

What do you mean? What sort of adjustments, and why would it depend on output format?

But before that, on the timeline, you might have to make adjustments too, depending on what the TS is

AVC.

and how the mjpeg is handled.

In what sense?

The MJPEG and AVC are together in one sequence. The PNG sequences are different sequences (main content and menu animations, respectively, for a DVD/Blu-Ray).

I already listed the "god mode" format, which is UYVY for 8bit YUV422. That gets passed through in/out losslessly when using a YUV timeline

You'd need hundreds of GB just for a couple of hours though, right?

[poisondeathray]

If you're frameserving out with afs, it's still using 601

So AFS converts to 601 regardless of source?

It looks like that. I don't use it much, just quick tests . You can check yourself.

you still might have to make adjustments after , depending on what the output formats were

What do you mean? What sort of adjustments, and why would it depend on output format?

Primarily I meant HD vs SD destination outputs. e.g. 709 vs 601 . But if you had other programs you'd have to know how they "behave". For example lagarith in PP . Basically you need to be aware of how something is treated end to end .

But before that, on the timeline, you might have to make adjustments too, depending on what the TS is

AVC.

Most types of AVC in TS should be treated as YUV in PP, but there are exceptions

and how the mjpeg is handled.

In what sense?

The MJPEG and AVC are together in one sequence. The PNG sequences are different sequences (main content and menu animations, respectively, for a DVD/Blu-Ray).

There are different mjpeg variants, but they can be handled differently in PP. I haven't fully nailed down the pattern or done comprehensive tests (I almost never use mjpeg) but sometimes you can get full range decoding, sometimes limited. Sometimes 601 , sometimes 709 (when converted to RGB for display). Sometimes actually converted to RGB on the timeline, sometimes treated as YUV. It partially depends on container (mjpeg in MOV are sometimes handled slightly differently than AVI) . AE's mjpeg handling is at least partially influenced by installed VFW codecs, I mentioned that in your other thread. Switching out mjpeg decoders produced different results. So that might partially explain why the results are so varied in PP too

If the PNG sequences are completely separated, then you can treat those differently or do whatever it takes to make them work in the end

Mixed assets can be tricky, because different formats can be treated differently. Sometimes it's a bit of a chore getting everything acting the way it's supposed to .

I already listed the "god mode" format, which is UYVY for 8bit YUV422. That gets passed through in/out losslessly when using a YUV timeline

You'd need hundreds of GB just for a couple of hours though, right?

It will take same space as uncompressed "YUY2" from vdub.

[koberulz]

It will take same space as uncompressed "YUY2" from vdub.

I've never used uncompressed anything.

How do I figure out what it's doing to the MJPEG? I'm assuming there are no superbrights or superblacks, and it doesn't have color bars...

If AFS converts to 601 for everything, is it as simple as using AviSynth to convert back to 709 before doing anything with HD footage?

[koberulz]

It will take same space as uncompressed "YUY2" from vdub.

I've never used uncompressed anything.

How do I figure out what it's doing to the MJPEG? I'm assuming there are no superbrights or superblacks, and it doesn't have color bars...

If AFS converts to 601 for everything, is it as simple as using AviSynth to convert back to 709 before doing anything with HD footage?

[poisondeathray]

How do I figure out what it's doing to the MJPEG? I'm assuming there are no superbrights or superblacks, and it doesn't have color bars...

I guess you can try making bars encoded with MJPEG, but it won't necessary help because there are slightly different MJPEG variants. In that case, I would just decide what you think it's supposed to look like for each video source type, and test the output of the frameserver . Really there are only 4 common variations 709/601 and full vs. limited range. But mjpeg has some other issues like field order / swap field as seen in your other thread.

If AFS converts to 601 for everything, is it as simple as using AviSynth to convert back to 709 before doing anything with HD footage?

It's not necessarily that simple; if you have it the way you think it should look in PP, then it might be as simple as that... just check it

BUT...keep in mind some assets work in YUV, some in RGB. This is what I mean by "tricky" with mixed assets timelines - Some get 601 treatment (e.g some SD sources, some "lossless" yuv codecs regardless of HD or SD, some get 709 treatment for the preview (eg. UT 709 variant, some native HD camera formats) . But that's for the preview - that doesn't necessarily mean that's what you get on export. Different export formats can get treated differently too. And that is separate issue from the frameserver. ie. what you "see" in the premiere program monitor preview isn't necessarily exactly what you're going to be getting out of PP, let alone the frameserver even if you "fix" the 601.

The bottom line is preview the export and check. If you have batches of same source formats (e.g. if all your mjpeg video have the same characteristics, from the same batch of source, then run that through test for the afs output before editing. Do the same for the TS series. One set of videos might need a workaround even before you edit - that's a way better /faster/ easier workflow than trying to fix edited parts at the end afterwards)

[koberulz]

what you "see" in the premiere program monitor preview isn't necessarily exactly what you're going to be getting out of PP

*bangs head on desk repeatedly*

I guess you can try making bars encoded with MJPEG, but it won't necessary help because there are slightly different MJPEG variants. In that case, I would just decide what you think it's supposed to look like for each video source type, and test the output of the frameserver .

MJPEG->Premiere->AVS matrix conversion, YV12 conversion->x264->Blu-Ray looks right, flicking between the finished disc and the broadcast source. Minus the conversion, reds looked a touch orange. No idea how it plays with an HD2SD conversion as the AVS step, then back into Premiere and out as MPEG2.

I only caught the initial color shift because a solid yellow area turned slightly green, and I've seen a lot of that yellow in Photoshop, After Effects, and Illustrator. It was a text overlay created in AE, the rest of the footage looked fine. Even looked the same flicking between them in Premiere, it was just the text that was visibly changing. And yet the vectorscopes looked completely different. So it's not quite as easy as 'see what looks right'.

All the MJPEGs are from my BlackMagic Intensity.

[poisondeathray]

I guess you can try making bars encoded with MJPEG, but it won't necessary help because there are slightly different MJPEG variants. In that case, I would just decide what you think it's supposed to look like for each video source type, and test the output of the frameserver .

MJPEG->Premiere->AVS matrix conversion, YV12 conversion->x264->Blu-Ray looks right, flicking between the finished disc and the broadcast source.

Then that seems like what you should be doing for the MJPEG sources. But how are you playing the finished disc, and broadcast source?

I only caught the initial color shift because a solid yellow area turned slightly green, and I've seen a lot of that yellow in Photoshop, After Effects, and Illustrator. It was a text overlay created in AE, the rest of the footage looked fine. Even looked the same flicking between them in Premiere, it was just the text that was visibly changing. And yet the vectorscopes looked completely different. So it's not quite as easy as 'see what looks right'.

All the MJPEGs are from my BlackMagic Intensity.

But the text overlay is RGB PNG sequence right? not the MJPEG source. Overlay operations in PP occur in RGB (only those frames with an overlay get converted to RGB) . But RGB assets in PP should look correct on the timeline , and on RGB out. That's the one thing that is super consistent RGB in/out. But when you have YUV export or add in another variable like AFS, you have more areas where stuff can go wrong. That's the underlying major cause of these headaches, all the variations in YUV<=>RGB conversions.

Frameserver adds another level of complexity. With simple RGB bars or YUV bars, either SD or HD - YUY2 served out needs RGB conversion with 601 to look correct. That's why I'm saying it's serving 601 out. But those are known starting bars. Known colors. With different assets (like MJPEG which can have variable treatment) , it's not always clear what you have.

[koberulz]

Then that seems like what you should be doing for the MJPEG sources. But how are you playing the finished disc, and broadcast source?

That's what I've been doing for Blu-Ray, but now I need to make a DVD.

I'm playing the Blu-Ray on my Blu-Ray player, and the broadcast through my cable box. Both connected via my amplifier to the same input on the same TV.

But the text overlay is RGB PNG sequence right?

Yes.

not the MJPEG source.

Sorry, skipped a step. The overlay is on an SD Lagarith/UTVideo source, and I'm trying to upscale that. The MJPEGs I'm trying to downscale.

Overlay operations in PP occur in RGB (only those frames with an overlay get converted to RGB)

Isn't it also converting the Lagarith/UT source to RGB anyway?

[koberulz]

I'm getting a color shift in the PNG overlay, too...

It contains, in part, a logo I have in an .eps file, which is largely a shade of yellow that, in Illustrator, is apparently 255:230:0. If I use Instant Eyedropper to get an RGB reading, it's 255:232:65.

According to Photoshop, it's 245:229:69, or 255:231:80.

In After Effects, it's 31,740:31,097:0. Which...seems wrong. Instant Eyedropper gives 250:243:74.

In Premiere, the AE comp's PNG sequence comes in at 247:242:0, but the EPS file dropped straight onto the same sequence is 247:245:22.

Apart from Instant Eyedropper being evidently unreliable, what's happening here? It definitely looks more gold than yellow in PS.

[poisondeathray]

Some of those values are way off.

What are your AE project settings ? Color managed ?

Some file types and formats can have embedded ICC or other color tags, or metadata - which govern how they are interpreted in various programs . Even "PNG" can have a "gama" tag which can make it look different in say firefox or AE, than something like vdub

[poisondeathray]

Isn't it also converting the Lagarith/UT source to RGB anyway?

Yes, but lagarith in YUV will get 601 treatment (assuming you're actually using lagarith YUV422 ; it might be you're inadvertently using lagarith RGB ) , UT fourcc "uly2" will get 601 treatment by UT fourcc "ulh2" will get 709 treatment . If you consistently used "uly2" for the UT clips, then they should all be ok and consistent.

[koberulz]

Some of those values are way off.

What are your AE project settings ? Color managed ?

By far the biggest shift is in Photoshop, where I'm literally just opening the same EPS file.

The working space for the AE project is PAL/SECAM. Depth of 16 bits, which might explain the 30,000+ RGB values?

[poisondeathray]

Yes, 16bpc will explain RGB values not 0-255, but I was looking at the photoshop vs AE differences in 8bit (for example 245 vs 255 in Red channel). When you have differences more than 1 or 2 per channel (in 8bit) it usually means messed up color management or wrong matrix from YUV<=>RGB conversion. +/- 2 can be "normal" for YUV/RGB conversion rounding errors. But a vector like eps is always RGB. That's why I suspected color managment issues

Have you used color management before ? You're in for a world of hurt if you don't have it setup correctly end to end, that includes interpreting/tagging all assets, managing exports and using software afterwards that can use color management as well. Your monitor needs to be ICC calibrated or you "see" the "wrong" colors. I doubt afs is even compatible with color management. My strong advice is don't use it unless you know what you're doing

[poisondeathray]

I'm assuming you want it to look like PS's "gold" , not "yellow" ?

You can probably salvage the AE portions by disabling color management and re-exporting those sections as a PNG sequence to a different folder, then replace the assets in the PP project. Make sure they are named the same convention, same names, just different folder and you should be able to right click, replace

When you have color management enabled, exports will be tagged with color information. When disabled, there is no management and for a format like PNG, it will default to sRGB with gamma of 2.2. That's what you usually want because most programs can handle those types of PNG sequences consistently . The only "semi-common" exception would be linear workflows (but you typically wouldn't be using PNG for that, you'd be using a more appropriate format like EXR)

[koberulz]

Hmm. The EPS shows up in AE with an embedded profile of 'none', and isn't color managed in Illustrator, but Photoshop seems to be converting it to the current working space (even though I have 'preserve embedded' selected). In CMYK, even though the EPS appears to be RGB (it's not a file I created). If I check the 'ask on opening/pasting' boxes I get a 'rasterize EPS' dialog that didn't show up before, asking to select between RGB, CMYK, etc. No option to choose an actual profile though.

Instant Eyedropper being so far off the software's own color picker is what makes the least sense.

[poisondeathray]

Just decide on how you want it to look. All the discrepancies are from color management. If you disable color management everywhere it will look the same everywhere.

In AE, you can make the color manipulations if it's not already "correct" or what you want it to look like. In a non color managed project, export a PNG sequence , do the replace, and you should get exactly what you want in PP . Then when you use afs , you might have to do the 601=>709 workaround afterwards

[koberulz]

I'm assuming you want it to look like PS's "gold" , not "yellow" ?

I want it to look correct. I'm not sure which is correct, but I think it's yellow. It's yellow everywhere except PS, so I was assuming yellow was right. I only have vague recollections of ever seeing it, and I'm 99% sure it was yellow.

Turning off color management in AE doesn't look like it does anything. Instant Eyedropper shifts to 247:242:24 from 250:243:77. After Effects itself reports 31,740:31,097:3,084 (the extra blue compared to last measurement is from checking 'Preserve RGB' in the EPS's color management in AE).

Not sure what 'linear workflow' means, haven't heard of EXR before.

[poisondeathray]

In PS you have color management enabled so it will convert to CMYK . You should be working in sRGB for everything . You shouldn't have preserve RGB checked, that's only for color management

In AE, you can temporarily shift to 8bpc to get the corresponding 8bit value equivalents.

When I say turn of color management, that means working space "none" too. ie. the default AE setup. Those default settings affect other things behind the scenes, including not tagging exports so other non color managed programs interpret it more consistently

Color management ONLY works if you have everything setup properly, including the display.