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.

Since neither project settings, nor media settings, nor rendern settings were published, I think it is hard to repro those findings.

I am having the exact same issue as the OP both on VP18 and VP20.

Anyone knows how to solve it?

Can you provide the exact conditions that trigger an error? We need to be able to replicate it.

@RogerS

To recreate my issue

1/ Render a prores422 file using vegas 20-403. Rendered file should be YUV422-10bits

2/ Import this file to a new project. Project settings 32 bits video level or full, same result

3/ Render using MagicYUV 422-10bits. Same error windows as the OP

It's a fresh MagicYUV install.

Rendering 8bits no issue

Interesting, thanks for the steps. I tried that on a ~30s file first creating a ProRes file and then rendering to MagicYUV in a 32-bit full (view transform off) project.

My render dialog box looks quite different:

I am using MagicYUV Ultimate 2.3.2

Thanks @RogerS

Your screenshot actually solve the problem.

I also have VP18 installed in my computer and notice that magicyuv option is available in the render window, option that i didn't have in VP20.

I then copy paste magicyuv folder from VP18/FILE IO PLUGINS to the same folder im VP20 and magicyuv.config from VP18 folder to VP20 folder.

Now magicyuv render option is available and works.

I was using Video for windows render option before.

Oh... I would never have figured that out. Glad it helped you!