Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VirtualDub, VDubMod & AviDemux

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th April 2021, 00:12   #41  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
Quote:
Originally Posted by kolak View Post
Try applying very heavy curve and then real 10bit data and 8bit will show difference.
Thanks. Will check that some day. But because off the timeline issue cineform is out of the race anyway.

Last edited by Hotte; 8th April 2021 at 00:20.
Hotte is offline   Reply With Quote
Old 8th April 2021, 00:14   #42  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
Quote:
Originally Posted by kolak View Post
Edius preview surface is 8bit anyway, so you never will see proper 10bit data in its GUI preview.
Are you sure ? This is the workgroup version where you have the 8bit/10bit Preview option. Cant imagine that the 10bit is pure fake preview.
Hotte is offline   Reply With Quote
Old 8th April 2021, 00:25   #43  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
Quote:
Originally Posted by poisondeathray View Post
One bizarre issue with some DCT based codecs like DNxHR/DNxHD and prores to a lesser extent is severe noise on some types of patterns like small checkers. It's not subsampling related (4:4:4 is affected too). Official Avid and ffmpeg implementations are affected. I've reproduced it on other patterns, other colors, other grid sizes. You can see some of the disussion here starting around post 672 . x264 (also dct based) , cineform (wavelet based) are unaffected
https://forum.doom9.org/showthread.php?p=1855173
I fear if I dive into this, no codec will be left for me. So I am probably doing better to keep my eyes a bit shut
Hotte is offline   Reply With Quote
Old 8th April 2021, 00:39   #44  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by Hotte View Post
That sounds coherent. Edius does all sorts of ProRes exports.



I tried that just for fun. 4K V210 uncompressed export is nothing less than crazy, not feasible with larger projects. No improvement, TL-perf is bad. I suspect Edius hates the cineform codec ;-)
I meant to encode DNxHR from it in ffmpeg.
kolak is offline   Reply With Quote
Old 8th April 2021, 00:41   #45  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by Hotte View Post
Are you sure ? This is the workgroup version where you have the 8bit/10bit Preview option. Cant imagine that the 10bit is pure fake preview.

It's not really preview. It's switching whole engine to work in 8bit to gain performance.
In order to have 10bit preview you need some card- BM/AJA or GV one. GUI is always 8bit. 99% sure
kolak is offline   Reply With Quote
Old 8th April 2021, 01:01   #46  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
Quote:
Originally Posted by kolak View Post
I meant to encode DNxHR from it in ffmpeg.
That sounded like a good idea.
Sorry to tell you, that there is practically no difference between an uncompressed V210 > DNxHD
and a Canopus HQX > DNxHD

Both where generated using ffmpeg and the fine Haze is in both. Strange - isn't it ?
It also shows how good Canopus HQX is. It is such a pity it is an 8-bit compressor outside!
Hotte is offline   Reply With Quote
Old 8th April 2021, 01:10   #47  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Are "fine haze" and "lower contrast" Edius specific problems ? Maybe the decoder, or some setting ?

Is there an actual problem with the file ? If you open the ffmpeg DNxHR in another application (e.g. mpv, ffplay, avisynth, or resolve) , how does it look ?


Did you explore proxy workflows ? In general, they can offer significantly faster timeline performance for complex, multiple layer projects. (Higher quality too, depending on how you set it up)
poisondeathray is offline   Reply With Quote
Old 8th April 2021, 10:28   #48  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by Hotte View Post
That sounded like a good idea.
Sorry to tell you, that there is practically no difference between an uncompressed V210 > DNxHD
and a Canopus HQX > DNxHD

Both where generated using ffmpeg and the fine Haze is in both. Strange - isn't it ?
It also shows how good Canopus HQX is. It is such a pity it is an 8-bit compressor outside!
What ffmpeg version is it?
kolak is offline   Reply With Quote
Old 8th April 2021, 22:30   #49  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
I have made the recommended outside comparison and I chose VDub2 as viewer (and frame TIFF exporter).
This are probably also some technical transients, there is codecs, tiff compression, website compression... I know.
But the relative findings I had all point into the same direction: COMPLETELY different insights.

Samples now! Unfortunately they are heavily jpeg'ed on imgur and rich in artifacts so will give you only an idea of what I am taking about. But you can pretty much trust on the evaluations below. If interested and sbd knows a better dowload source (no google or other sniffer please) where I can drop 8MB tiffs I`d be happy to upload them.

1. Out of camera MOV H.264 4K 10bit 4.2.2
https://imgur.com/LCWcIHe

2. Edius Export Canopus HQX superfine
https://imgur.com/cX8YC01

3. Edius Export V210 uncompressed
https://imgur.com/jK34YI9

4. Edius Export DNxHR HQX native MXF
https://imgur.com/fo16rfQ

5. ffmpeg Edius V210 uncompressed > DNxHD profile dnxhr_hqx
https://imgur.com/ZZs3ixW

6. ffmpeg Edius V210 uncompressed > ProRes HQ 4.2.2 10-bit Highest Quality
https://imgur.com/QfgHtYd

My findings after pic-on-pic comparisons with 1000% magnification:

Edius Canopus HQX
Edius HQX and V210 uncompressed are practically identical down to the extreme detail. No contrast, saturation or sharpness shifts. This is an excellent, neutral codec.

Edius Export DNxHR HQX native MXF
increases micro contrast (fakes more resolution) and overall contrast/saturation. Nice look for people who like it and are ready to accept e.g. more pronounced ringing artifacts (that were already there). Apart from that it preserves resolution very well.

ffmpeg DNxHD profile dnxhr_hqx
in this setup has to be compared to its source file uncompressed V210 or to Canopus HQX to see which codec does better. There is NO HAZE. Resolution is kept very well, about as well as HQX. Like its native brother it introduces a very small amount of additional microcontast but way less than Edius DNxHR - it's ok. What I do not like is the slight increase of overall contrast/saturation to about the same amount as Edius DNxHR although it appears less evident because of less push in microcontrast. Overall an excellent performer for a free codec if you play with levels to tame it. poisondeathray was right!

ffmpeg ProRes HQ
this is an excellent neutral codec, no shifts, no sharpness push, very good detail preservation (although Canopus HQX has an ever so tiny advance in this respect). But you have to push the VDub2 compressor quality slider to the very left to get there. This increases file size by some 10% compared to Canopus HQX. ffmpeg ProRes is relatively slow on an Edius-X timeline and buffer will run out in seconds with 4K 10bit full res. Its not as bad as Cineform in this respect, but also not great.

Bottom line: I was tricked by some Edius internal transients. Sorry for that.

But finally it was you to help me find my 10-bit codec: ffmpeg DNxHD. DNxHD would have well-deserved to be implemented in VDub2 but I will be able to work around it.

Kolak, poisondeathray and all the others: Thank you very much.

Last edited by Hotte; 8th April 2021 at 23:57.
Hotte is offline   Reply With Quote
Old 8th April 2021, 23:13   #50  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
There are some issues with the color in the presented screenshots - there are 601/709 mismatches. It's most easily visible on the grass

edius v210 and canopus hqx are similar in one group in terms of color;

original, v210 to (ffmpeg) dnxhr_hqx, and edius direct dnxhr_hqx are similar in the other group.

If you correct for the mismatch (one group to the other) they all become the similar in terms of color

For example, vdub uses 601 to convert from YUV to RGB for display, instead of 709 . If you used vdub for all of them, they should all be the same color. So there is something else going on with the procedure you've used that is not explained
poisondeathray is offline   Reply With Quote
Old 8th April 2021, 23:49   #51  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
Quote:
Originally Posted by poisondeathray View Post
edius v210 and canopus hqx are similar in one group in terms of color
All pics were created manually with VDub2 in the following way: Load Clip, Direct stream copy, Decode Format=AutoSelect,Interpret YCbCr none/none, export single TIFF
These two are AVI-export directly from Edius. All Edius exports in 4.2.2 CSS like the original, project properties are YCbCr 10-bit BT.709

Quote:
Originally Posted by poisondeathray View Post
original, v210 to (ffmpeg) dnxhr_hqx, and edius direct dnxhr_hqx are similar in the other group
Same procedure and settings with VDub2:
- Original loaded unchanged
- Edius dnxhr was direct MXF export from built-in codec
- dnxhd was converted from the uncompressed V210 of above with ffmpeg latest release

How can I do better ?

Last edited by Hotte; 9th April 2021 at 00:04.
Hotte is offline   Reply With Quote
Old 9th April 2021, 00:57   #52  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by Hotte View Post
All pics were created manually with VDub2 in the following way: Load Clip, Direct stream copy, Decode Format=AutoSelect,Interpret YCbCr none/none, export single TIFF
These two are AVI-export directly from Edius. All Edius exports in 4.2.2 CSS like the original, project properties are YCbCr 10-bit BT.709


Same procedure and settings with VDub2:
- Original loaded unchanged
- Edius dnxhr was direct MXF export from built-in codec
- dnxhd was converted from the uncompressed V210 of above with ffmpeg latest release

How can I do better ?


In terms of the 601/709 mismatch - it doesn't add up.

All video versions are YUV. You used same procedure in vdub for screenshot creation for all of them. If one has the "wrong" color, they should all have same the "wrong" color . None of the jpg's have color profiles or metadata .

Even stranger is the ffmpeg dnxhd_dnxhr was created from the v210 version and yet has different color...

Something else is going on, there might be some flags or metadata interfering , but afaik vdub ignores them

Since the "AVI" files are in one group, there might be some local configuration difference, some VFW filter or vdub config difference






Another way is to control the conversion in avisynth explicitly

#load YUV source, use LWLibavVideoSource to be consistent
LWLibavVideoSource("video.ext")
ConvertToRGB24(matrix="rec709")





Or more important to your workflow, would be to take the screenshots in Edius, assuming what procedure Edius uses for screenshots is what it actually uses on the timeline





For example if you wanted to change the edius "v210" to "look" like the "original" colors

ImageSource("jK34YI9_edius_v210.jpg")
ConvertToYV24(matrix="rec601")
ConvertToRGB24(matrix="rec709")


or "original" to "v210"

ImageSource("LCWcIHe_orig.jpg")
ConvertToYV24(matrix="rec709")
ConvertToRGB24(matrix="rec601")

So that "prooves" that it's a "pure" 601/709 mismatch somewhere in the workflow
poisondeathray is offline   Reply With Quote
Old 9th April 2021, 20:50   #53  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
I have redone all my samples to be sure I have not made any mistake - because there are lots of opportunities for errors when you fiddle with different codecs. And this time I also exported TIFFs out of Edius (which are 8bit only but that does not matter for this comparison).

The Edius-TIFFs show a very different but consistent result:

1. All exports and the original brought back into Edius have the exact same color and contrast if you compare them. This is what I would have expected from professional software.

2. Resolution of the codecs does not differ a lot. The same is true for sharpness except for ffmpeg DNxHD-HQX (derived from V210) which has some slight softness, so the haze is back. But the haze is not as bad as before. The reason could be that I was on an old 2017-version of ffmpeg which I updated now - Thanks Kolak!

3. And now comes what really suprises me: The contrast profile of all Edius-Tiffs (like in the preview) is visibly flatter then any of the VDub-TIFFs. I had a look into the viewfinder of my camera and found it is flatter than in the camera also. But there is no primary color-mapping applied in Edius.

Samples in better quality now:

Edius-TIFF: V210 uncompressed
https://imgur.com/ILFz7hv

Edius TIFF: V210> ffmpeg DNxHD HR_HQX. Same color/contrast now but slightly less sharp:
https://imgur.com/fUjkNXh

VDUB TIFF: V210 uncompressed: VDub color space is different, more contrast
https://imgur.com/HhBw4OH

I am a bit confused now: What is the correct contrast profile ? Even more confusion is this: I tried your avisynth/lwlibavvideosource tip but...
Code:
lwlibavvideosource("F:\Temp\Export_V210.avi") 
info()
Return last
...returns interleaved (?) rubbish. How is this to be read with avs+? It is misinterpreted. It defintely is 10bit.
https://imgur.com/dulokJH

I can`t correctly interpret any of the codec exports with libav, only with ffm2.

Btw ffplayer shows the same false colors as VDub does.

Thanks for any advice.
Hotte is offline   Reply With Quote
Old 9th April 2021, 23:08   #54  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
The contrast difference is full vs. limited range

The color difference is 601 vs. 709 matrix

If you adjust for them, you can make one group look like the other or vice-versa



10bit - Possibly you're using an old lsmash build, or old avisynth build

https://github.com/HolyWu/L-SMASH-Works/releases

v210 should open up as yuv422p10

MOV and MP4 container does not require indexing if you use LSmashVideoSource - ISO base media formats, (unlike ffms2 or LWLibavVideoSource)
poisondeathray is offline   Reply With Quote
Old 10th April 2021, 10:49   #55  |  Link
shekh
Registered User
 
Join Date: Mar 2015
Posts: 775
Quote:
Originally Posted by Hotte View Post
Yeah! ***** The DNxHD would be a great addition to the compression menu as it seems to play some not unimportant role in professional video exchange and looks like being an excellent codec, also encoding is fully supported by ffmpeg.

I'd be ready to support that in any way that makes sense. I`d be happy to hear Shekh`s evaluation of the matter. I have no idea if that is a lot of work to do.
When I evaluated what codecs are good as intermediate I also saw DNxHD. However it is quite special as it does not work with arbitrary resolutions. I think it is not big problem to make some basic implementation, I just didnt like it.
__________________
VirtualDub2
shekh is offline   Reply With Quote
Old 10th April 2021, 11:18   #56  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209

My god, 6 tips that turn my video conversion world upside down! I write my findings down here for Edius-X and Avisynth/VDub2 user generations to come (who are as ingenuous as myself). Be nice and honour Mr./Mrs. Poisondeathray for his/her generous help.

1. Luminance range: YES, this the first time I understand why Edius marks my original Input clip as BT.709 [Full] instead of BT.709 only. In my camera I activated Rec.709 full luminance range (0-1023 with 10-bit) instead of TV range (64-1023). Edius obeys that and shows flat full range. The camera viewfinder/monitor doesn't care and always displays TV (bad!). VDub2 picks TV as well because it doesn't know or care and the AVI-container doesn't tell either.

2. Version of LSMASH: YES, I was on a 2017 built. This one cannot read "YUV422P10" correctly. Upgrading to the latest version solves it. And this is the first time when info() shows the correct colorspace and bit-depth and that is:
Color Space: YUV422P10 Bits per Component: 10. ffmpeg will per default convert to YUV422P16 which is not bad but also not fully correct. You should go for this:
Code:
LSmashVideoSource("F:\Temp\Export_HQX.mov",format="YUV422P10") 
info()
Return last
3. Pick the right video-container: YES. Edius-X (at least the workgroup version) allows Canopus HQX-super-fine 10bit Exports with AVI and MOV (see Quicktime-Export Menu). I've always tended to avoid Apple proprietary stuff. But in times of ffmpeg and libav this seems nothing to be concerned about. And this time it pays off to pick MOV instead of AVI, because then you can use LSmash and be rewarded with faster load times, no interim index files and a less stupid container that shows and transports more media information. Hence you can see the code above to import a Canopus HQX10bit MOV which is a dignified and adequate replacement for cumbersome Uncompressed AVI as far as my resolution tests yielded.

4. Color space: YES, I managed to tell VDub2 how to display this. At least I am getting very close (not 100% but must be around 99,8%) with the following extension
Code:
LSmashVideoSource("F:\Temp\Export_HQX.mov",format="YUV422P10") 
ConvertToRGB24(matrix="pc.709")
info()
Return last
To display a YUV color space on a monitor in sth that makes sense for our eyes it needs to be converted to RGB anywhere. To make sure that colorspace is not subject to a random default (like oldish Rec.601) in VDub, avs+ or anywhere else it is a good idea to talk Turkey: This is Rec.709. And to make clear that we don't want the PC (aka full) luminance range to be changed we choose "PC.709" instead of forcing gamma down to the more contrasty TV-Range which would be "Rec709".

@Poisondeathray, did I get it get it right or do you see anything to be improved with this little code snippet ?

I am getting almost correct colors and contrast with this. There are very subtle color differences, only viewable at very large zoomlevels:

Edius TIFF: HQX-10bit superfine
https://imgur.com/3bWpRUR

VDub2 TIFF: HQX-10bit superfine converted to RGB24 pc.709 as above
https://imgur.com/YZiFJAv

To round up the whole matter, there are a few questions left and IŽd be very, very happy if you could answer these too:

1. Does color-conversion Rec.601<>Rec.709 back and fourth in AVS+ / LSmash ... come with any losses or is it just fully reversible ?

2. I am not sure I fully understood the luminance range matter.

2a. Which luminance range would you recommend...
- for recording (in the camera)
- during video post processing for color grading with a calibrated sRGB monitor
- for the final version to be watched using a good video projector or modern TV

2b. Does the change of the luminance range have any lossy impact on my video...
- as long as I stay in the YUV world (e.g. avs+ filtering) or is it just a gamma curve that does not spoil anything ?
- when I change it being already in RGB ?

3. From all I learned from you and other experts in this forum I suspect that it is a good idea to stay in the YUV-world as long as possible while exporting and filtering with avs+ to have a minimum of loss. You only go RGB if a filter needs it or at the very end to display.
Is this a correct conclusion ?

If 3 is correct:
I heard that the latest "Primary color correction" filter of Edius-X works in RGB. Does this potentially come with IQ loss (there are YUV alternatives on board) ? I mean Edius would internally convert to RGB48 or something and convert back to YUV before it exports YUV e.g. with HQX.

Last edited by Hotte; 10th April 2021 at 12:30.
Hotte is offline   Reply With Quote
Old 10th April 2021, 12:00   #57  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
Quote:
Originally Posted by shekh View Post
When I evaluated what codecs are good as intermediate I also saw DNxHD. However it is quite special as it does not work with arbitrary resolutions. I think it is not big problem to make some basic implementation, I just didnt like it.
Shekh, that sounds ever so great!

DNxHR is used in the AVID broadcast world (and some other manufacturers) as intraframe interchange/intermediate codec. It is well supported by Edius and is pretty fast on its timeline.
DNxHD was the name of its predecessor which was only used for up to 1920x1080 10bits 4.2.2

There is an ffmpeg implementation of DNxHD which can run in some hqx_hr profile to manage e.g. 4K in 10 bits 4.2.2 and there is a hqx_444 profile for even more.

The implementation of these two profiles would be of great use. The ffmpeg version is a very good codec. I only noticed a very tiny hint of softness - or let`s say defensive micro contrast. Others obviously did not notice that. Anyway this could be cured easily in post if ever necessary since you will never notice it at regular zoom levels in 4K.

For Edius-X users it seems to me the best alternative for 10-bit content to be filtered with avs+ and VDub2 to bring back the filtered clip into sth which Edius can handle. The reasons are:

- Edius' native codec Canopus HQX is only 8-bit in ffmpeg hence VDub2 (it is 10 bit in Edius)
- reimported ProRes is 10bit and has great IQ but it is very slow on an EdiusX-Timeline
- reimported CineForm is 10 bit and has great IQ as well, but is extremely slow on an EdiusX-Timeline - can even make the Editor crash

I know, you are not Edius support but I am sure it would well appreciate VDub2 to offer
  • ffmpeg DNxHD profile dnxhr_hqx
  • ffmpeg DNxHD profile dnxhr_444
as new compression options.
Hotte is offline   Reply With Quote
Old 10th April 2021, 12:28   #58  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
DNxHD an DNxHR in ffmpeg is same thing. They are all under dnxhd codec, just different profiles. You should today use DNxHR and forget DNxHD. All current ffmpeg builds have DNxHR.

Quote:
Edius' native codec Canopus HQX is only 8-bit in ffmpeg
Wrong. HQX is fine ffmpeg and works at 10bit.
HQX is only 8bit in its VFW/Directshow codec installed by Edius (not in ffmpeg).
In Vdub2 you are using ffmpeg module to decode HQX (which I fine and 10bit), but VFW codec to encode, which only supports 8bit. Plain simple. Your only other tool which can encode HQX at 10bit is Resolve.

Last edited by kolak; 10th April 2021 at 12:31.
kolak is offline   Reply With Quote
Old 10th April 2021, 12:47   #59  |  Link
Hotte
Registered User
 
Join Date: Oct 2014
Posts: 209
Quote:
Originally Posted by kolak View Post
DNxHD an DNxHR in ffmpeg is same thing. They are all under dnxhd codec, just different profiles. You should today use DNxHR and forget DNxHD. All current ffmpeg builds have DNxHR.
Are you are saying (ffmpeg DNxHD profile=dnxhr_hqx) = DNxHR ? So that's even better!
Still I can see a difference (the slightly reduced microcontrast I was talking about) between ffmpeg DNxHR profile=dnxhr_hqx and native DNxHR Exports from Edius. But that could be a difference between the professional and the ffmpeg implementation - couldn`t it ?

Quote:
Originally Posted by kolak View Post
Wrong. HQX is fine ffmpeg and works at 10bit.
HQX is only 8bit in its VFW/Directshow codec installed by Edius (not in ffmpeg).
In Vdub2 you are using ffmpeg module to decode HQX (which I fine and 10bit), but VFW codec to encode, which only supports 8bit. Plain simple. Your only other tool which can encode HQX at 10bit is Resolve.
Ah! Does that mean that if VDub2 Compress-Dialog would implement HQX as "ffmpeg HQX" (rather than "HQX" without ffmpeg as today) it would compress 10 bit ? Now I understood, that HQX is not native VDub2 but came with Edius... Sometimes it takes time to understand - sorry. But then ffmpeg HQX would be another great implementation candidate...

Last edited by Hotte; 10th April 2021 at 12:51.
Hotte is offline   Reply With Quote
Old 10th April 2021, 13:04   #60  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: Poland
Posts: 2,843
Quote:
Originally Posted by Hotte View Post

1. Does color-conversion Rec.601<>Rec.709 back and fourth in AVS+ / LSmash ... come with any losses or is it just fully reversible ?

2. I am not sure I fully understood the luminance range matter.

2a. Which luminance range would you recommend...
- for recording (in the camera)
- during video post processing for color grading with a calibrated sRGB monitor
- for the final version to be watched using a good video projector or modern TV

2b. Does the change of the luminance range have any lossy impact on my video...
- as long as I stay in the YUV world (e.g. avs+ filtering) or is it just a gamma curve that does not spoil anything ?
- when I change it being already in RGB ?

3. From all I learned from you and other experts in this forum I suspect that it is a good idea to stay in the YUV-world as long as possible while exporting and filtering with avs+ to have a minimum of loss. You only go RGB if a filter needs it or at the very end to display.
Is this a correct conclusion ?

If 3 is correct:
I heard that the latest "Primary color correction" filter of Edius-X works in RGB. Does this potentially come with IQ loss (there are YUV alternatives on board) ? I mean Edius would internally convert to RGB48 or something and convert back to YUV before it exports YUV e.g. with HQX.
If you have HD file then you use Rec.709. Anything which goes through 601 is plain wrong and needs fixing. This conversion is probably near lossless (don't think it can be lossless)- point is that it's totally not needed and all should be handled over 709.

Luminance range is basically meaningless (specially for 10bit + formats) if it's handled properly by your tools. Conversion from one to another is nothing to worry much about unless it's done badly.
It's end delivery point/spec (before this it can be both) which may mandate certain levels, eg. YUV for broadcast is limited range. Although nothing stops you in your own environment use full range for YUV before final export. It all depends on workflows, your tools, monitoring etc. If you don't use properly calibrated monitor over video card (but Edius GUI) then you are not very accurate anyway. Edius GUI preview is not a reference preview and should not be used for anything color critical. You need to buy BM card and feed calibrated monitor with signal from it. For Edius this is a proper way of monitoring video.


Quote:
3. From all I learned from you and other experts in this forum I suspect that it is a good idea to stay in the YUV-world as long as possible while exporting and filtering with avs+ to have a minimum of loss. You only go RGB if a filter needs it or at the very end to display.
Is this a correct conclusion ?
Yes, overall this is the best practice. Once your video hits YUV at some point then it's good to stay in YUV (if possible), specially when you are going to deliver only to formats which require YUV. This is exactly why Edius uses YUV engine as it's tool for broadcast not really high-end finishing/grading. Staying with YUV has its own issues as well- you can easily produce out of gamut files (so such a YUV combinations which converting to final display RGB produce illegal (negating, or above max level) values). We know this is real issue in Edius and it has no native gamut legaliser (Premiere does now). If you work in RGB and convert to final YUV master out of gamut errors can't happen (can only as codecs overshoots).

From other hand when you start with high-end recording formats (RAW, film scans etc) then you rather want to work in RGB on GPU (with 32-bit floating point processing) and only during final exports you may convert to YUV.

This is a typical master chain for high quality production: RAW recording, grading/finishing in RGB (in tools like Resolve, Baselight, Mistika, Flame etc), export- quite often at this point master goes to YUV domain. This is the point where you may receive such a master, eg. ProRes, DNxHR and do editing, versioning etc. Here you ideally want to stay in YUV (as we already left RGB during "main" export), but in today's app this is not that essential anymore as RGB<->YUV conversion if not lossless (apparently with 32bit float it can be) is so high quality that this is your last worry. There are 1000x more important aspect of your video- editing, grading etc which impact its final perception.

Stop chasing some ideal paths- focus on artistic value as as long as you stay technically correct with main principals then this is easily good enough. For example your lack of proper monitoring in Edius is 100x more important than whole YUV<->RGB conversion "issue".

With tools like avs etc you have to test and validate path to make sure bit depth, levels, etc are preserved properly. Most NLes are rather closed apps and things work there fine, but don't take this as 100% ideal either. There are problems in Resolve, Premiere as well. I don't think I've seen some critical issues in Edius engine though (except maybe whole new primary color filter, which works in RGB). It seems to be well tested. Problems can still happen so any new export (new major app version) needs new validation and checks.

Last edited by kolak; 10th April 2021 at 14:27.
kolak is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 23:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.