So Confused, and ready to throw in the towel.


ALO wrote on 3/11/2023, 9:56 AM


@Wolfgang S. Vegas' 32-bit Full Range mode is flat-out broken for working with SLOG3, at least for the media I've tried. At some point I may try to post about that on the VP20 issues thread, but there are more issues than I have time to report.

As far as the color grading tools being outdated, look at what the (free) competition offers:

That's just one tiny aspect of Resolve's tools!

This is simply wrong, the slog and vlog workflow works in Vegas. What do you think that I do since years with my FS7 or EVA1 10bit log footage?



I'll detail this out in the VP20 bug thread. 32FR improperly decodes SLOG3/SGamut3 footage. But I will need a little time. Note that I'm referring to Vegas in 32FR mode. In 32 video levels mode, provided you stay away from the broken plugin chain fx, you can properly decode SLOG3 using the LUT filter.

You should have no trouble seeing the difference if you switch between the two modes (properly configured).

Sorry to go off-topic!

Wolfgang S. wrote on 3/11/2023, 12:26 PM

You think that a LUT is more appropriate then the 32bit floating point mode and ACES? A difference between two modes proves - which modes? And if that is so - which mode delivers then the „correct“ results? How can you know that?

I think you would have to become more specific. Simply to state that something is not correct is not enough. It requirers a testing that can be used as repro for the development team, to fix it (if it is broken really). What is not so simple.

Howard-Vigorita wrote on 3/11/2023, 5:03 PM

My 1st exposure to LUTs was in cryptography, not video. Were the object was to achieve identical results, but more quickly with luts. Generally, look up tables are pre-calculated with greater precision than practical with floating point on the fly. 64-bit floating point and 512-bit avx are commonly available today. The other determinants of accuracy are the number of pre-calculated entries you have in your look-up table and how you interpolate values in-between, if you have fewer than all possible entries in your table. In cryptography, the luts used are generally exhaustive so that's not an issue. Exhaustive luts are possible in video if they provide a pre-calulated entry for every expected value but I've never seen such a thing. In any event, that's were Vegas falls down, providing relatively small 33-point luts rather than 64 or 128 points. But makes up for it by providing a tetrahedral lut interpolation option rather than just lower precision linear or cubic... which I expect is implemented 32-bit float.

On the other hand, the Vegas Aces implementation seems to be implemented with 64-point luts and I assume the interpolation between points is done with some sort of 32-bit float calculation. So, at the end of the day, there's probably not much difference in accuracy if you use 64- or 65-point luts from camera makers compared to Vegas Aces. Widespread reports are, however, that the Vegas Aces implementation runs slower than using manufacturer supplied Luts instead. Not sure why that is. I'm guessing it's because the Gamut and Range are calculated independently in Vegas Aces rather than merged as is common with Luts supplied by camera makers.

EricLNZ wrote on 3/11/2023, 10:10 PM

This thread is derailed...

Agreed. It's gone OT. It appears you've all helped @Silverglove as far as you can so I'll close the thread.

If you want to discuss SLOG3/SGamut3, Aces, 64-point luts, 32bit floating point etc suggest you start a new thread although there is probably several existing threads that touch on these topics.