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. |
8th April 2021, 00:25 | #43 | Link | |
Registered User
Join Date: Oct 2014
Posts: 209
|
Quote:
|
|
8th April 2021, 00:41 | #45 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
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 |
|
8th April 2021, 01:01 | #46 | Link |
Registered User
Join Date: Oct 2014
Posts: 209
|
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! |
8th April 2021, 01:10 | #47 | Link |
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) |
8th April 2021, 10:28 | #48 | Link | |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
|
|
8th April 2021, 22:30 | #49 | Link |
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. |
8th April 2021, 23:13 | #50 | Link |
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 |
8th April 2021, 23:49 | #51 | Link | ||
Registered User
Join Date: Oct 2014
Posts: 209
|
Quote:
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:
- 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. |
||
9th April 2021, 00:57 | #52 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,346
|
Quote:
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 |
|
9th April 2021, 20:50 | #53 | Link |
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 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. |
9th April 2021, 23:08 | #54 | Link |
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) |
10th April 2021, 10:49 | #55 | Link | |
Registered User
Join Date: Mar 2015
Posts: 775
|
Quote:
__________________
VirtualDub2 |
|
10th April 2021, 11:18 | #56 | Link |
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 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 @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. |
10th April 2021, 12:00 | #57 | Link | |
Registered User
Join Date: Oct 2014
Posts: 209
|
Quote:
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
|
|
10th April 2021, 12:28 | #58 | Link | |
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:
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. |
|
10th April 2021, 12:47 | #59 | Link | ||
Registered User
Join Date: Oct 2014
Posts: 209
|
Quote:
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:
Last edited by Hotte; 10th April 2021 at 12:51. |
||
10th April 2021, 13:04 | #60 | Link | ||
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
Quote:
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:
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. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|