As far as I see it, there is a '2020' that is possible as a regular color matrix, and another one that requires special coding that it can't be easily implemented in the same conversion routines (fmtconv in vapoursynth has a special function for it for instance).
'non constant luminance mode' (ncl) is the simpler one, and you'll encounter it more often. 'constant luminance mode' (cl) is the 'special' one.

The thing is, it's not just the colormatrix. Most 2020 stuff uses different color primaries then bt709 (although 2020ncl with bt709 does exist.. it's not _that_ weird, just not the only stuff out there).
So the correct way to change / convert color primaries is to go to RGB, then to linear RGB (gamma 1.0), convert the color primaries (from bt709 to 2020, or from bt709 to dci-p3 for example).
Then go to gamma-correct 'normal' RGB again then convert to the YUV with the colormatrix you want (or leave it RGB if that suites you).

This all is to convert the colormatrix and/or colorprimaries. The thing to remember is, this does NOT convert HDR to SDR or something. What you end up with is still all the HDR information but in a colorspace-configuration that you know from SDR times. To make the stuff watchable on SDR displays you would still have to do some kind of dynamic-range compression and / or clip some stuff out to get it watchable. I could get stuff looking pretty OK by tweaking the gamma correction but there are better ways (for example, what MadVR does to display HDR content on SDR displays).

So, colorspace conversion is one thing. HDR to SDR conversion is another. And of course stuff like the 2020 colormatrix and 2020 colorprimaries (or dci-p3 color primaries or something else) has a much wider gamut of colors available, so you will be loosing color precision / data somewhere (colors _should_ end up over saturated here and there in bt709, unless you use some smart 'desaturation' filter during the conversion.. again, like MadVR does).

Hum... It seems that i read thing too quickly and not deep enough, didn't realise it wasn't a simple matrix like the other formats. Non linear is not a real issue with 8 bits using look-up table, but maybe in that case lookup-tables even of... 64k maximum may still be interesting.

So is matrix-only Rec2020 useful in practice? I am confused with transfer functions. They are defined for rec601/rec709 too, but in reality are ignored (so that rgb-yuv conversions are linear and fast).
If the same still works for ldr 2020 then it is basically a matter of adding some new constants (as in avs+)

All my apologies, my bad again (it's becoming quite an anoying habit), i'm very not used to all these new behaviors...
It never cames to my mind that bottom was still active when it wasn't with original (so i didn't even check), neither that right panel could be moved with mouse.
Finaly nothing wrong, so it's perfect.

In the good old VirtualDubMod, saving a screenshot of the currently displayed frame was so easy: Video » Snapshot source frame (Shift+1).

Trying the same in VDubFMod r38543 (32b) ... Video menu: No more matching entry. File menu: Export ... a submenu, that costs me precious time, unless there is a keyboard shortcut assigned; Single image ... no shortcut assigned yet, have to try to assign one later; click. Nothing happens?

Let's try in VDubFMod r38544 (64b) ... pressing shortcut (was assigned for both versions, that's nice): OK, a dialog appears. Exporting a single image works. So it appears to be broken only in the 32b version.

Or is it? Trying again ... this time it works there as well?! Strange. A reliable bug could be found and fixed. But unreliable issues are the hardest.

Ligh, Menu/File/Export/Save Single Image, for current frame (choice of output formats).

EDIT: Oops sorry, you already saw that, guess I'm in a hurry to get some shut eye and just partially skim read your post.

EDIT: REading a bit more in full

Quote:

Or is it? Trying again

I think that used to be a problem in earlier versions, thought it got fixed (I'm on 32 bit build 20160407164938).

EDIT:
I've never had that problem for some time, but only just updated to VirtualDub_Pack_38543, I'll keep my eyes open for that problem
re-appearing (used Save Single Image about a half dozen times throughout the night in previous version, no problems).

Yes. As I wrote, it's in a submenu, so navigating the mouse cursor through it takes a lot of time, unless I assign a keyboard shortcut. Please read it again completely, there is more about it.

Yes it is supposed to have a shortcut, since it is also accessible from filter preview and there is no menu.
The logic behind File->Export structure is because Image sequence is also there (and it is very similar).

The bug when it suddenly does not work still exists in all versions and is old, btw in the same situation "copy to clipboard" command gets disabled too.

Minor issue i've noticed :
In View->Pane Layout if you select "Auto Size panes" when it's not it's done immediatly. But unselect it has no effect. You have to close VDubMod and restart it unselected to remove the "Auto Size".
And... it's also the case in the original version... Well, i think it's up to you to chose if it's worth fixing or not.

Dont like that VDFM drops display of frames [EDIT: contents] whilst user stepping through the timeline via keyboard [EDIT: right cursor key], you have to stop timeline traversal to see the current frame. (I can see that it is quicker to not display frames during such time, but not if you have to stop to view every frame).

EDIT: Perhaps its an option, if so then make it (standard mode) default.
EDIT: Only happens in heavy filtering scripts that do not play anywhere near real time.

Dont like that VDFM drops display of frames whilst user stepping through the timeline via keyboard, you have to stop timeline
traversal to see the current frame. (I can see that it is quicker to not display frames during such time, but not if you have to stop to view every frame).

EDIT: Perhaps its an option, if so then make it (standard mode) default.

Definitely not (planned) behavior. IMO step keys are exactly for viewing each frame, no reason to make it quicker.
So this is a defect (in my test it is even worse with old VD)