Export Images

[xeberdee]

When I'm importing a 720P RGB 8bit bitmap 1280x720 image with square pixels into a Full HD 720P project of the same size - should I get the same output pixel for pixel if I export as uncompressed RGB avi from the timeline?

I'm noticing 4:2:2 like artifacts on these exports - shouldn't these exports be pixel perfect.

Am I stupidly missing something here?

[GrassValley_KH]

I could be horribly mistaken here, but I could've sworn EDIUS processes in YUV - which means a "flip"

Still, that should not affect anything that dramatically (artifacts).

Able to zip and attach the BMP file here?

[xeberdee]

Rgb

Hi,

Yes I agree Edius might process in YUV, but I imagine only if I export to UYVY avi. What I mean by '4:2:2 like artifacts', is that the result looks like the attached file. There is some shift, like subsampling or something. Why does it happen on an RGB export if I have my sequence as Full HD, with an uncompressed RGB export format?

'I could've sworn EDIUS processes in YUV' - I can name other NLEs that do the job from RGB to uncompressed RGB without any difference, even if filters & FX etc. are meant to work in YUV this shouldn't have an effect on an in - out - no messing about export - should it? If so why?

I would imagine the uncompressed RGB AVI exporter should do just what it says and process the file as RGB (native) and not convert it to YUV by just placing it on the timeline? But I'm not sure that's what's producing the results.

During the same test trying to export a native uncompressed avi as uncompressed avi caused Edius to crash, so no Post workflow for RGB programs like After Effects for me at the moment.

[7hbg]

I can tell you for sure that EDIUS internally processes everything in YUYV format (4:2:2) regardless of the source. That means that on input everything gets converted to YUYV, all processing is done in that format and only the output is converted to the target format. There are over 40 RGB and YUV formats out there, it would be very hard to process everything native.

The problem I see with your graphic is the size of your text. Your font has a little over one-pixel width/height (the black part). There is a lot of anti-aliasing already in your source. The first thing EDIUS is going to do is to convert/stretch your graphic to fit your project settings. This is where I see most of the problems. What is the size of your original graphic that you put on your timeline? Take a look at the ‘i’ in ‘bitmap’; it is almost gone due to the fact that the source pixels don’t align with the target. Remember, in YUYV all luma is preserved and only the chroma is reduced. So if your source is exactly as your target, then the text would preserve its shape. Are you using ‘Layout’ tool to stretch it or position it? All that will influence your final output.

[xeberdee]

Hi Rob,

Ok, that clears some things up if Edius is allready converting the colorspace on import and using the newly generated YUYV file for all further processing - including export. Either there's something happening in the conversion, or I'm doing something wrong.

By the way - are we talking about a ITU-R BT. 601 or BT. 709 colorspace for 720 projects? What is the code using?

The photoshop generated files are using red at 235 sRGB and black at 16.

I don't use the layout tool because I believe the source is the same as the project - square pixel aspect 1.000 at 1280x720 pixels in a 50 frame progressive project. The text is purposely small for testing reasons.

I enclose a new source/export comparison with 'clean' non-aliased pixels and what I believe to be legal colours. The foiles are of course cropped to show just the interesting information.

[GrassValley_KH]

720 projects use 709 colourspace.

As for a technical explanation of what is going on, I'm not the guy for this - hopefully BH can answer this when he gets back from InfoComm.

[7hbg]

By the way - are we talking about a ITU-R BT. 601 or BT. 709 colorspace for 720 projects? What is the code using?

The photoshop generated files are using red at 235 sRGB and black at 16.

The actual numbers for each luma and chroma parameter are identical for both ‘601 and ‘709 - so there is no difference in calculations (blacks are at 16 and peaks are at 235). The different is in the output, these values map to slightly different colors (so the only time it plays any role is when it is displayed on a monitor).

I enclose a new source/export comparison with 'clean' non-aliased pixels and what I believe to be legal colours. The foiles are of course cropped to show just the interesting information.

Yes, I have looked at your samples and I agree, there is kind of horizontal re-sampling happening there. But according to my test it has to do with how YUV is displayed when luma information is mixed with chroma. Notice in the picture below (source is at the top and output is at the bottom) that with white background the lines preserve it’s shape, as soon as you add color to the background the color spills and distorts the luma information. In YUYV (4:2:2), there is one sample of color for two samples of luma; therefore the distortion due to color will always be 2 pixels wide.





If you duplicate your original test without any color (white, shade of gray or black) in the background, your text will preserve it’s shape.

[xeberdee]

Hi Rob,

I used black on red at 1 pixel because I wanted to see what was happening with back and forward workflow with Edius.

I mentioned 709 because I can see that the HQ codec only has parameters for 601 when using it in 3rd party apps, but if the values are the same for 709 as 601 then that explains maybe why there is no need for 709 settings in HQ export I suppose. There's no mention of which colourspace a 720 project is working in in Edius, but I guess I'll be looking at the correct colours on my monitor (I presume).

I trying to work out why when I look at the UYVY codec in AE or similar, it really adds a lot of luminace/gamma to the original signal, why is that?

[7hbg]

I mentioned 709 because I can see that the HQ codec only has parameters for 601 when using it in 3rd party apps, but if the values are the same for 709 as 601 then that explains maybe why there is no need for 709 settings in HQ export I suppose. There's no mention of which colourspace a 720 project is working in in Edius, but I guess I'll be looking at the correct colours on my monitor (I presume).

Ok, but all I said is that the numbers are in the same range for both ‘601 and ‘709:
Y = 16…235
U = 16…240
V = 16…240
But they represent slightly different colors.

I trying to work out why when I look at the UYVY codec in AE or similar, it really adds a lot of luminace/gamma to the original signal, why is that?

I would create a B&W gradient graphic to see exactly what‘s happening to the signal.
If it is adding any amount of luma to the signal (equally across the gradient), then how much? That could eliminate for example if 16 is added for the blacks, etc. If it is more at one place then another, then I think it could be gamma. But, as I don’t have AE I can’t comment on it.

PS. To create smooth gradient: Place a ‘Color Matte’ on a V or VA track. Open the setup dialog and set colors to 2 and direction to 0.00. Set the first color to: 16, 128, 128 (Y, Cr, Cb) and the second color to 196,128,128. This will create 4 pixels per step gradient across 720 pixel wide screen (SD). If you are doing it in 1280x720 project then use the same numbers just change the direction to 90.0 or 270.0, and that will produce a nice top to bottom gradient.

[GrassValley_BH]

Rob addressed what I was going to say (yes, it's 4:2:2)... as for luma changes, EDIUS assumes "full range" conversion, meaning 0,0,0 = 0 IRE.

Some other applications compress the range making 16,16,16 = 0 IRE.

ProCoder (full, not Express for EDIUS, sorry) has a filter for colorspace shrink/expand that can compensate for differences.

[xeberdee]

To summarise: By "Yes it's 4:2:2" you mean that the software is not designed to process anything from import to export in 4:4:4, and all 4:4:4 material will inherit 4:2:2 artifacts because of the conversion to the UYVY codec?

Also the internal UYVY conversion used for output of 601 & 709 signals, will assume full range and effectively expand luma values on monitor, for content not captured or created by Edius?

Have I understood this correctly?

[GrassValley_BH]

Yes, your understanding is correct. EDIUS's native "working space" is 4:2:2. However, some processes like keying will use a larger space.

But, for the most part, you can assume that everything will be in 4:2:2 space, as that's what it hits on import and export as you said.

[xeberdee]

Ok thanks for clearing this up everybody.

I realise that Broadcast traditionally means 4:2:2 and that most camera material is in the colorspace, but 4:4:4 is native for IT, graphics or animation.
Lots of the stuff I do from time to time contains lots of G & A, and ends on the web. The problem is if I want to edit small sections of RGB renders in Edius to build backgrounds or textures including video for output back to RGB apps etc. G & A gets degraded into 4:2:2, and it's a pity because some of the effects like motion blur are great for this kind of work. I would rather see 4:2:2 expressed as 4:4:4 than 4:4:4 expressed as 4:2:2, and wait for renders.

I do use After Effects, so it's not an issue, but it would be nice to get software support of 4:4:4 and hardware output in 4:2:2 with Edius.
Clipping is much easier in an NLE and Edius offers some great features with output.

Is 4:4:4 software processing on a wish list for anybody else?

Of course, there's no way that realtime performance should suffer in any way :)