It is unlikely, that this codec is decoded in Vegas as 10bit anyway.

Imported back into Vegas, it shows 10 bit 444.

It looks like the MagicYUV plug does handle high-bit. Here's 10-bit 4:2:2 (tested with VP 19). 

Folder: D:\My Documents\Dropbox\Videos
  Type: MagicYUV AVI
  Size: 4.83 GB (4,947,486,496 bytes)
  Created: Monday, February 6, 2023, 3:07:29 PM
  Modified: Monday, February 6, 2023, 3:08:05 PM
  Accessed: Monday, February 6, 2023, 3:10:14 PM
  Attributes: Archive

Streams
  Video: 00:00:05.739, 29.970 fps progressive, 7680x4320x20, MagicYUV 10-bit YUV 4:2:2
  Audio: 00:00:05.739, 48000 Hz, 16 Bit, Stereo, Uncompressed

Other metadata
  Regions/markers: no
  Command markers: no

Media manager
  Media tags: no

Plug-In
  Name: magicyuvplug.dll
  Folder: C:\Program Files\VEGAS\VEGAS Pro 19.0\FileIO Plug-Ins\magicyuvplug
  Format: MagicYUV
  Version: 1.0.0.0
  Company: INNOMAGIC Bt.

It is unlikely, that this codec is decoded in Vegas as 10bit anyway.

@Wolfgang S. - Why do you say this?

Imported back into Vegas, it shows 10 bit 444.

@wwaag - Thanks for clarifying.

I was able to import and render out a 10-bit MagicYUV video in 32-bit full mode here in VP 20.

It is unlikely, that this codec is decoded in Vegas as 10bit anyway.

@Wolfgang S. - Why do you say this?

 

Imported back into Vegas, it shows 10 bit 444.

Unfortunately I know, that the implementation of the 10bit decoding required an native implementation in the past. That was true for the cineform code, but also ProRes. But if the OFX interface is still used for the decoding, you end up with 8bit onlyl.

So the information, that is shown in the media properties, is not a guarantee that this codec is decoded as 10 bit really.

Also, that you can import the codec and exprt it again does not proofe anything, Roger.

The best way to explore that is to take such an imported file in the histogram - and enlarge it. So we have identified that in the past, if it is decoded in 8bit or 10 bit really.

What I have not done is to expore that for this codec really. Simply, because I do not use this codec.

@Wolfgang S. - O…K….? Would you kindly take me through, step-by-step, the separation of the understanding of the two sets of processes?

@Grazie

the test approach was a simple one,

- use a 32bit floating point project

- bring in the test file

- apply the filter levels to the test file

- choose for the test dramatic settings. For example Input start 0,550 and output end 0,552

If you do that for a 10bit and a 8bit file, you will see a dramatic difference!

8bit file (from the GH4, recorded internaly)

10 bit file (from the EVA1, recorded also internaly but to 10bit)

An old thread, where we have explored such points in 2015, can be found here (but it is in German):

https://www.videotreffpunkt.com/videotreffpunkt/index.php?thread/17874-10-bit-uhd-prores-verarbeitung-in-vegas-wissenstand-1-2015/&pageNo=1

I see no reason to doubt that MagicYUV doesn't work as advertised, which is up to 14 bit depth in Vegas: https://www.magicyuv.com/

Original file is high-bit and then converted to MagicYUV 10 bit 422 in Vegas.

32-bit video levels (full seemed to have issues with the levels Fx)


8-bit video levels

Happy to be corrected if I'm missing something.

If this codec has been implemented in the meantime as 10bit codec in Vegas too - great.

In your measuring approach I would tend to compare 8bit files with 10bit files - but since you manage the decoding here about the project settings, that should work too.

But that are the reasons why I use the measuring approach always, if possible. Simply, beause such measurements show us the technical truth.

@Wolfgang S. - So, to achieve closure, will you do the Math?

@Wolfgang S. - So, to achieve closure, will you do the Math?

Was the original question solved? Not sure about that.

I’m gone.

Did anyone manage to replicate the original render error? The file name says HDR, wonder if that's a clue as to settings.