Hi all,

I'm the developer of the MagicYUV codec, just thought I'd tune in to the discussion, in fact I was more or less following this thread since the Sony days.

In any case, it is unfortunate that Vegas cannot send 10bit+ data neither through VFW nor QuickTime.

I had a lengthy discussion with a Vegas developer 2 years ago, and he also confirmed that 10bit+ data paths are handled specially.

Actually, transfering 10bit+ data through VFW should be easily possible to do. The main reason I believe it is not done is probably a lack of agreed upon fourcc/pixel format for 10bit+ data and/or architectural difficulties inside Vegas. v210 (nicknamed in Vegas as the Sony YUV "codec") is one option for 10bit YUV 4:2:2 transfer, but there are 2 fourccs already in place in other programs (ffmpeg, VirtualDub Filtermod, AviSynthPlus) that could be used for 16bit RGB transfer: "BGR0" ie. BGR[48] and "BRA@" ie. BRA[64].

If Vegas development could be convinced to implement presenting these formats to VFW, deep color compression with MagicYUV (and possibly other VFW codecs) would work now right away.

It is a bit of a chicken-egg problem I believe: there is no incentive to add support until the need arises from the community (ie. MagicYUV 10bit+ files waiting to be imported), but the community cannot raise the need, as there is no way to create MagicYUV 10bit+ files from Vegas in the first place.

Balázs

So, does anyone have an idea how to go about convincing Magix to implement deep color transfer support to generic VFW/QT codecs?

Write a letter to ******* in Madison Wisconsin.  He is the product manager.

Sorry, publishing or mentioning the names of MAGIX employees in your posts is not permitted (Community Rule #9). I will attempt to pass the message on to the product owner.

Oh, sorry, his forum name is ********.  Sorry I added a space. 

His identity and position are public knowledge and his forum name is hardly a pseudonym.

NickHope (is this how you prefer to be adressed?), have I offended you in some way?  Because what you just did was both unecessary and seems a little sharp.

NickHope (is this how you prefer to be adressed?), have I offended you in some way?

Not at all. Just following my instructions as a moderator.

Because what you just did was both unecessary and seems a little sharp.

Really? To me, Nick is the ulltimate nice guy.

Back to topic. I do not see any need for the MagicYUV codec in Vegas at all. One can use Cineform but also XAVC I for 10bit, and especially Cineform works great in Vegas.

MagicYUV is lossless. Cineform and XAVC-I aren't.

Thanks Nick, if you pass on the info that would be great! I await the results.

Because what you just did was both unecessary and seems a little sharp.

Really? To me, Nick is the ulltimate nice guy.

Yes, of course.   Just a little mis-understanding on my part about how MAGIX view the forum rules. I think rule #9 needs a little embellishment for practicality, but I will still respect the rule as it stands.

I use and like Cineform, but having choices is best.  You can't send cineform to handbrake, for example, and you never know how long GoPRo will keep it in develpoment.

I use and like Cineform, but having choices is best.

Exactly. I'm advocating for supporting deep color transfer through generic codec interfaces, that would allow not just MagicYUV to encode at higher bit depths, but any other codec implementing the interface.

I use and like Cineform, but having choices is best.

Exactly. I'm advocating for supporting deep color transfer through generic codec interfaces, that would allow not just MagicYUV to encode at higher bit depths, but any other codec implementing the interface.

As far as I’m concerned, such a generic interface would have to pass the data as 32-bit floats, and the codec would then convert them to whatever bit depth it needs.

MagicYUV is lossless. Cineform and XAVC-I aren't.

Fun answer: if you see the difference then you have great eyes! ;)

More serious: it is not true that the use of any intermediate codec is lossless really. At least there is the step to decode the camera footage and encode it in the intermediate codec (and this step is not loseless). The advantage of all the intermediate codecs is that - after you have transfered your footage in the intermediate codec, the loss when rendering generations of the footage becomes small. But you are not able to avoid the initial loss. So it can be better to avoid any loss due to the first conversion and to decode the original footage immediately - if that is possible from your workflow side.

Beside that: all the intermediates are of interest for an high-end workflow mainly, where we adress 10 bit or higher. Given the fact that we will not see a 10bit implementation for MagicYUV in Vegas very likely, for me it is quite clear what codec I will use. For 8bit I would not go into the effort of huge intermediates at all, as long as I am not forced due ot a lot of render generations I would try to stick to the original footage (and all what is called H.264 preserves the picture quality in a great way, as long as we render again to H.264).

Thanks Nick, if you pass on the info that would be great! I await the results.

I can tell you that the request has reached the place it needs to and is at least in discussion. Doesn't mean to say it will happen of course! Could you PM me your email address and I'll pass it on in case the devs wish to contact you?

More serious: it is not true that the use of any intermediate codec is lossless really. At least there is the step to decode the camera footage and encode it in the intermediate codec (and this step is not loseless).

If I compare a video rendered by MagicYUV (e.g. 8 bit RGB) on the timeline with the original MP4 or whatever, not a single pixel moves on any scope. So how is this not lossless?

A scope doesn't show you every pixel so that is not necessarily accurate, but if you don't see any visual changes and the scope matches the original, then it could be considered visually lossless. I don't know if it is mathematically lossless or not.

The comparison should be done with difference pictures, and the noise brougth in by any step can be quantified. If you do that you will find that the decoding and the encoding from one (not loseless codec) to ANY other codec will deliver some noise. I have done those tests years ago with both Cineform and the Canopus HQ codec. That is why a workflow with an intermediate may makes limited sense only in terms of quality, as long as you do not need more than one render generation. This is why Vegas never added an more explicit intermediate workflow.

Magix should add higher bits to Vegas because ALL of its pro competition has already done so. With the new cameras recording higher bits for lower prices, its become sort of manditory.

MagicYUV is mathematically lossless. It is not reconstruction of pixels/macroblocks, it is identical bit reconstruction. In a certain way similar to ZIP compression.

The comparison should be done with difference pictures, and the noise brougth in by any step can be quantified. If you do that you will find that the decoding and the encoding from one (not loseless codec) to ANY other codec will deliver some noise.

Method: Original UHD footage on upper track, compositing mode set to "Difference", rendered footage on lower track.

MagicYUV RGB 8-bit:

Cinform Filmscan2 (least lossy of the Cinform codecs):

I have been testing this codec recently and my results match Nick's pictures.

This is valid as long as no fx is added, as soon as 1 is added, some pixels change (may be due to rounding error).

If one wants true lossless encoding, no choice but using a lossless codec and encoding as RGB, which Cineform or Canopus (among others) are not.

Today, I bought a license for MagicYUV 2.0 Standard.

1) The ground is too wet to mow the grass.

2) I've spent more time, of late, working with external encoders.

I'm happy.