Vegas PlugIns not actually 32bit (colour wise)

[Craig Longman]

While playing around just now, I noticed something weird in Pro v10 that I wasn't expecting. In 8bit colour mode, I put a Levels plugin on a clip, then adjusted the input end to a lower value. I got the expected banding in the histograms as integer maths just rounds awfully. However, when switching to 32bit mode, I would have expected the (hugely) greater precision to have smoothed those out, but it did not. Which leads me to believe that the Levels (and others?) are not, infact, using floating point or 32bit maths at all.

This type of thing is expected in 8bit, but I had expected 32bit fp mode to behave more like AEs 16bit mode, and use the higher numeric fidelity to fill in the gaps properly. There seems no reason at all to me why there should be gaps when you're using single precision floats, they can store 30 some digits for goodness sake, way better than 16bit integers (0-65535).

I'm really surprised about this.

Attached are two histograms, one was 32bit and one was 8bit. There is a slight difference, but it's not very much at all.

[Craig Longman]

Actually, I think there is something I'm not understanding about AE when I was playing with it. In retrospect, given a basically integeric source (RGB) if you're going to split the 0-191 range across the full 0-255, white input of .750, for eg, then you're going to get holes I guess. Unless you were able to get access to higher resolution colour information in the first place.

I'm going to keep playing with this and try and figure out what I thought I saw in AE.

[Craig Longman]

Well, I see my first mistake was thinking that choosing it actually allowed the plug-ins to get floating point pixel information. It seems it doesn't, the same 4 bytes are sent regardless. So, if there was any extra information it is long lost before the plug-in gets it.

Where is floating point used then, in the built-in 2-1 transformations/compositing only? The custom ones have to use the same DX interfaces, and I see no way of getting floating point out of them. I realize this is getting more technical than most here are likely to care to see, I'm just wondering what is actually floating point when in 32bit floating point mode, then I'll stop.

[Gerald Webb]

I for one greatly appreciate what your trying to work out Craig,
I'm not saying I understand it completely, lol, but i'm trying,
The mystery of color correction in Vegas is slowly becoming clearer.

[Edward Troxel]

What kind of footage are you testing? If it's 8-bit footage to begin with, you can expect it to pass 10-bit information to the plugin. You'd need to start with 10-bit footage for that.

[Chris Hurd]

Should we edit the title of this thread?

[Craig Longman]

I don't see how Edward. Everything seems to use DXSAMPLE as the 'format' of the pixels, and that is a 4x8bit only, as far as I can tell. Nothing in their SDK indicates anything different either.

And even if the source was 8bit, it's YCbCr, when it's converted to RGB, there will be more information there that could be presented in 32bit float, be it 0.0 to 255.0 or even left normalized. But when it's converted again to an 8bit integer, all that is lost for good.

The 16bit integer really does make a lot of sense (ignoring MMX at least), your MSB is the actual value to use, and the LSB is your 'precision'. No rounding required.

I'm going to take this up with Sony now I guess. I haven't looked into the OFX spec to see if it allows for different pixel formats, but given its pedigree, I imagine it must. Just depends on what Sony makes available I guess.

[Edward Troxel]

To be 32-bit, the plugins must be written to handle floating point. Otherwise, they'll down convert them to 8-bit. So it's really plugin dependent on whether or not it will work properly with 32-bit.

[Craig Longman]

=)

Clearly, something would need to be requested and handled differently.

My original issue was why the Sony built-in ones seemed to still be working with integer only values, not some third party one.

My second point, was any reference to 32bit/float is conspicuously missing from the PIDK I downloaded. Literally, no '32' in the entire manual, no 'float' (float is the 32bit floating point). Nothing. Not in the samples, etc. And the only option is DirectShow, and the enum for pixel types in DirectShow do not seem to include anything non-integer.

So, it might be plug-in dependent to request it, but it is incumbent on the host to provide a mechanism to offer it. And publish said mechanism.

Anyway, as I said, I'll be taking this thread to Sony support. Even if it is a non-issue seeing as DirectShow is almost certainly a dead-end now that it's only VMS that is stuck with it, but I'd like to figure out where/how 32bit is actually used.

[Craig Longman]

Haha... the email in the PIDK (md-videopidk@sonymediasoftware.com) gets bounced as recipient unknown. Now that's funny...

Gonna try a support ticket I guess.

edit: Actually, it was a 'too many hops' error. Hopefully just a transient DNS issue.

[Gene Gajewski]

Hi craig,

I don't really think there is any problem with the color systems in Vegas. As you expected, when you played with the input start and end levels in 8 bit mode, you saw some banding in the color histograms. This is normal.

A point to note in 8-bit mode is although codes 16 thru 235 for luma (and 16-240 for chroma), video is recorded full swing. This is why when you view a properly recorded set of color bars from your camera on the levels scope (with 16-235 enabled) you see the pluge bars go below, at, and above the zero mark.

When setting the input levels to do a sRGB (video) to computer (linear), it must spread codes 16-235 among instead of 0-255 - this holds true for properly encoded video - and now we some some banding holes because there just isn't enough codes to go around. Switching to 32-bit mode won't help this either - you still have only 220 codes (16-235) spread across an 32-bit floating value which wants to map 255 exact codes to to specific value from 0.0 to 1.0.

(the benefit of 32bit comes out in compositing - not from the 8bit source)

This is all normal. The only thing I should point out is that in linear gamma mode, at least for the sony MPG-2 codecs, is that they will automatically map 16-235 to 0-255 (as seen on scopes - although it is internally using floating point). This is mapping the *legal* ranges... if you now take a look at a recorded clip of color bars, you'll notice that that bottom half of the pluge is clipped out in linear mode.

(note: cineform doesn't "clamp" levels like the sony codecs do in linear mode - you have to manually add levels control *and* adjust the gamma - this is why recorded color bars are crucial)


This can all be confusing - but the short point to remember is that that in video levels (2.2 gamma , 8 - or 32 bit), the valid viewing level are still the 0-100% levels on the waveform monitor (with 16-235 checked) - but encoding is still done full-swing. When you bring in generated media or pictures, these are computer rgb (linear) and you will see out of range levels you generally want to fit the full-swing image into the legal range so it will look proper.

However, when compositing in linear mode. you don't need to convert levels on images, and you won't need to do levels on video using the sony mpg2 codecs - but don't trust any other codecs without verifying with color bars.

[Adam Stanislav]

Originally Posted by Edward Troxel

To be 32-bit, the plugins must be written to handle floating point.

Well, unless you have some kind of insider information, there is nothing in the SDK that tells us just how we are supposed to handle floating point. I mean, it is clear that it is possible, just not how.

Hopefully, with the OFX this will change, since OFX does allow for 8-bit, 16-bit and 32-bit formats and its sample source code seems to show how it works (I just had a cursory look at this point, but it seems to be possible).

The downloadable SDK is truly ancient, almost makes you thing Sony does not want us to write Vegas plug-ins. (Though then they use our plug-ins to brag about all the things Vegas can do, something that really annoyed me when they used my plug-ins to brag, after which I never released any updates).

[Craig Longman]

@Gene

Gene, I understand what you're saying, but I don't think I'm contradicting anything there. One thing though, you seem to imply that only in linear mode will Vegas remap to cRGB, and I believe it does it in full range 32bit regardless of the gamma mode, and linear light is only available in full-range. I have yet to tackle the maths involving gamma correction, that's coming later =)

Secondly, you are right when you say you're spreading X number of values across some >X range. But the point is, assuming the RGB components were not left normalized, we'd have colours like this (only giving one component for eg)

64.8 : 64.3 : 64.5 : 64.99 : 64.01

As opposed to just a run of 64s in 0-255 only mode. Then, when those floating point numbers were spread out, the banding will be all but eliminated, assuming the spreading wasn't a ridiculous amount. Clearly, 2one can't simply invent values for the 'tweening, but having the source calculated float values without the flooring that conversion produces gives you a far, far better chance at a smoother ramping. This is essentially what I believe the 16bit mode of AE does, takes the normalized RGB and multiplies by 65535 instead of 255, still allowing work in integer for performance, but giving 256 levels of sub-integer precision.

In one CC layer, this won't likely be noticeable. But given decent amount of CC and/or levels, followed by various grading layers, it certainly can make a difference.

[Gene Gajewski]

I think you have a fairly good handle on it.

I'm sure one could use a non normalized system, but, from practice, many developers will simply use 0 to 1 to describe a widest possible range and keep all the precision in the exponent. At least this is so in the engeering profession, especially when working on signal processing - that being so - I really shouldn't make any assumptions about how 'they do it' in video.

I'd have to look at my 'C' headers to see what the min and max values for floating point are - you could simply devide that range by whatever your integer source is, 0-255(8),0-1023(10) and figure out the mappings.

As far as using a 16bit integer mode - damn good idea. I once worked on a project to display aeronautical data. Our client was less than happy with the program they had been using which required floating point, and this was in the days of 386's and 486's of which few had the required coprocessor. We simply converted latitudes and longitudes to normalized integer X/Y coordinates based on a reference point - it was blazing fast.

Today though, floating point support is always available, so there's less of a need to avoid it for performance reasons.

[Craig Longman]

For anyone who might happen to be interested in the missing 32bit plug-in information.

After a bit of back-and-forth with Sony Support who were, understandably, unsure of how to answer or what to do, I got this excellent response:

Originally Posted by Sony Support

Thank you for writing back. I have been in contact with our Development team, the following information has been provided:

New Email Address for the PIDK:

scs-videopidk@am.sony.com

The following info has been provided from the Developers:

Here is a brief overview of what you need to add floating-point support to your Vegas Pro video plug-in (FX, Transition, or 2-to-1) using the old DX Transform-based SDK.

- Add a new #define for floating-point capable, "#define SFVIDEOPLUGIN_CAPS_FLOATCAPABLE 0x00000800"

- In the place you set your capability flags (for example, setting m_vplugInfo.dwCaps in the "FinalContruct" method) include the SFVIDEOPLUGIN_CAPS_FLOATCAPABLE flag. This will let Vegas know it can pass floating-point data to the plug-in.

- In your WorkProc, to determine if the current request is for floating point processing, your call to CDXSurface::GetPixelFormat will fill in *pFormatID with SFPF_PMARGBFLOAT for float images (as opposed to DDPF_PMARGB32 for 8-bit images). I'm not certain if this is declared in the SDK, so I'll copy it here:
// {EC385932-2D38-11d2-99D3-00C04F8EDC2D}
DX_DECLARE_GUID(SFPF_PMARGBFLOAT,
0xec385932, 0x2d38, 0x11d2, 0x99, 0xd3, 0x0, 0xc0, 0x4f, 0x8e, 0xdc, 0x2d);

- Alternatively, and typically what we do, is after initializing the surfaces (which will all use the same pixel depth), check sfsurfDst.m_nBytesPerPixel which will be 16 bytes for float (and 4 bytes for 8-bit).

- If you use CSFARGBReadPtr, float versions are attached an updated sfbase.h which adds CSFARGBFloatReadPtr and CSFARGBFloatReadWritePtr. For our plug-ins, the code that used to use CSFARGBReadPtr now checks the pixel type first and branches to either the 8-bit code or the float code which uses CSFARGBFloatReadPtr. Also, instead of DXSAMPLE it uses SFDIBPIXEL (same layout but with floats instead of unsigned chars).

The floating point data is in the same structure order as 8-bit data. 0.0f, 0.0f, 0.0f represents black and 1.0f, 1.0f, 1.0f represents white, but we do not bound the RGB data so you can very likely see values less than zero and greater than one. These should be dealt with in a reasonable manner and the output values should not be bounded if possible. Alpha, on the other hand, should never be outside 0..1 and if you generate alpha, please bound it. To create test projects with over-range data, I usually use the Test Pattern generator with the "Gradient" preset, then apply the "Brightness and Contrast" FX with Contrast set to 0.80. On the final output, you can apply Brightness/Contrast with Contrast set to -0.80 to bring the values back into visible range. Clipping will be apparent visually and with the Scopes window.

If the project compositing gamma (set in Project Properties) is set to 1.0, the RGB values represent linear light (no gamma).

Also, if your plug-in is thread-safe (please be positive), set the "SFVIDEOPLUGIN_CAPS_CLONEABLE" flag (0x400) which will improve multithreaded render performance for sections of the project using your plug-in.