Generating video thumbnails preview / contact sheet in batch, color issue

[abolibibelot]

I have a large collection of videos to sort out, and for that purpose I want to create a thumbnail preview for each one of them, as quickly and efficiently as possible. I have tested several tools which have that capacity, with a varying degree of satisfaction.

- Media Player Classic : Does not allow command line interaction or batch directory processing. The presentation of timestamps and other informations is good enough as it is, but not customizable. The aspect of the screenshots, as I found out, depends upon the settings of the graphic driver (from Intel Skylake CPU) : whether there are “enhancements” active or disabled, or whether the entry levels are set to full range or restricted range. With the default “restricted range”, the picture appears more vivid, with more contrast, but the blacks are crushed and the highlights are blown ; with entry levels set to “full range”, the picture is rather dull, with slightly faded / washed-out colors, similar to the representation of the other tools below.

https://i.stack.imgur.com/ihwwe.jpg
{default graphic settings}
https://i.stack.imgur.com/Vg0IV.jpg
{“full range” in Intel graphic settings}
https://i.stack.imgur.com/dgUc4.jpg
{all “enhancements” disabled in Intel graphic settings}

- SMPlayer : Does not allow command line interaction or batch directory processing. The display of information is not customizable (does not allow to display the file size in bytes for instance). The colors on the screenshots appear shifted compared with the other tools, i.e. the greens are darker / less saturated while the reds are lighter / more saturated, which I know is related with the matrix used for YUV>RGB conversion (Bt.601 vs. Bt.709), but it's hard to determine which of these provide the most accurate representation and how those colors are supposed to look like.

https://i.stack.imgur.com/6mrmx.jpg

- Scorp Video Thumbnail Maker (GUI tool) : The display of information is fairly customizable, it allows to treat a whole directory recursively, but there's a huge logo / watermark covering one tile with the free license.

https://i.stack.imgur.com/9vIXd.jpg

- MTN / Movie Thumbnailer (CLI tool, also included in StaxRip) : The display of informations is fairly customizable, but the aspect of the screenshots is slightly blurry compared with the others (perhaps it creates JPEG-compressed temporary files ?). That tool, which apparently hasn't been updated since 2008, comes as an already compiled .exe file interacting with a bunch of DLL (based on libavcodec), so I don't know how to see which commands it uses internally, and could not alter them.

https://i.stack.imgur.com/qNQJy.jpg

- VCSI (Python script) : The display of informations is fairly customizable, but some useful items are missing (video bitrate for instance). A small drawback is that it seems to be creating a temporary PNG file for each tile before generating the actual thumbnails file, it's still quick enough with 4 tiles but could make it slower for more complex presentations. Since it comes as a script interacting with ffmpeg, I could modify some parameters if necessary.

https://i.stack.imgur.com/Unbz9.jpg

QUESTIONS :

- My main issue is the color accuracy and sharpness of the screenshots. MTN would have been fine as it's simple and quick and readily provides all the relevant informations in the description, but the resulting files are definitely blurry : what are the likely causes of this ? When comparing the results, how can I determine which color representation is the most accurate, and is there a way to modify this behaviour, either by tweaking each tool's parameters or by adjusting global, system-wide parameters ?
- Are there other similar tools which would be worth trying ?

[abolibibelot]

I did some further testing, opened another thread about the specific problem of the color inaccuracy, an issue report on Github for both VCSI and MTN, and I'm still at a loss since each of these tools has advantages and drawbacks.
Among the 3 tools which can process an entire directory in batch :
– MTN is by far the fastest (in a test in generated 104 previews in 60s), but the output quality is definitely inferior (blurry screenshots, even in PNG), and the colors are inaccurate ;
– VCSI can be tweaked to use the correct color conversion matrix (see the other thread linked above), but is significantly slower (in the same test, it generated only 17 previews in 60s), which matters when there are thousands of videos to process ;
– Scorp Video Thumbnails Maker is in-between with regards to speed (in the same test in generated 36 or 40 previews depending on the video rendering engine selected), the quality is on par with that of VCSI (better than MTN's output, although less sharp / crisp than MPC-HC's output), the colors are inaccurate.

So, does anyone know of another tool which could do this right and fast ?

[abolibibelot]

OK, this thread seems to have a lot of followerz !

In the mean time, doing some more tests, I found out that Scorp Video Thumbnails Maker gets the colors right with one of its four video rendering modules, named “Engine 2”.
http://www.suu-design.com/forum/viewtopic.php?f=7&t=1893
(The person who replied, presumably that software's author, or part of the team of programmers, seems pretty clueless about the very notion of color spaces.)

Problem, that module doesn't work with the files I have to process, which use the GAVC codec, which is apparently a proprietary format. Only the “Crystal” and “Ultimate” modules work, and with those two modules (as well as “Engine 1”) I get wrong colors. “Crystal” and “Ultimate” are said to rely on “embedded codecs”, while “Engine 1” and “Engine 2” rely on the system's codecs. On the website it is advised to install CCCP for those two modules to work properly : I installed CCCP, they work with regular MP4/H.264 files, but still don't accept those GAVC files.
So, how could I solve this issue, i.e. make this “Engine 2” module “reasonably happy” with GAVC files ?

[jagabo]

- My main issue is the color accuracy and sharpness of the screenshots. MTN would have been fine as it's simple and quick and readily provides all the relevant informations in the description, but the resulting files are definitely blurry : what are the likely causes of this ?

Since the thumbnails are half the size of the original videos -- probably different scaling algorithms. Bilinear vs. bicubic vs. lanczos, etc. Some of the programs may give you control over this. Programs that use hardware decoders use the graphics card's setting.

When comparing the results, how can I determine which color representation is the most accurate,

Use a program that lets you control the conversion from YUV (video) to RGB (image). (I would use AviSynth for this.) The differences are probably rec.601 vs. rec.709 colors, and limited range vs. full range YUV. Generally SD video uses limited range rec.601, HD limited range rec.709. But same cameras shoot full range rather than limited range. Use MediaInfo to check the properties of the video. The range and matrix are sometimes flagged.

[abolibibelot]

Hi,

Generally SD video uses limited range rec.601, HD limited range rec.709.

That I know already.

But same cameras shoot full range rather than limited range.

And some cameras shoot “HD” footage with the Bt.601 matrix (I've been given the example of Canon DSLR cameras in the related thread).

Use MediaInfo to check the properties of the video. The range and matrix are sometimes flagged.

In my experience it's quite rare actually (I've checked a folder containing hundreds of MKV files and a few AVI files, couldn't find one with such a tag ; a MP4 video I've created and encoded myself, using an Avisynth script containing the ConvertToYV12(matrix="Rec709") command, processed with MeGUI, doesn't have such a tag either, not according to MediaInfo anyway). I should try those tools with videos which are actually flagged (videos downloaded from YouTube for instance) to see if there's a difference. Since some of them are based on ffmpeg, does ffmpeg respect the Bt.709 flag by default when there is one ?

Since I opened this thread, I made some more tests with a personal video purposefully created with Bt.709 color conversion matrix, which at some point shows a still picture I took of a red car, so I could compare each tool's output with the native picture (see the suu-design.com link above). I found out that the colors are correct with Scorp Video Thumbnails Maker and its “Engine 2” module (not with the other three), as well as with SMPlayer, and with the tweaked VCSI script containing a "-vf", "zscale=matrixin=709:matrix=709,format=rgb24", line, based on the suggestion from “poisondeathray” on the other thread.


Regarding full range vs. limited range, I know that videos are supposed to be recorded / encoded with the limited 16-235 range (right ?), but how are they supposed to be correctly displayed on a PC screen, and what should screenshots look like ? MPC-HC screenshots are more contrasted, but the highlights are blown, while the screenshots from the other tools are duller, but with better preserved highlights. What does it mean with regards to the full range / limited range distinction, and what is the correct aspect ? Is the duller aspect normal, and is it a false impression that the more contrasted picture looks better when compared side by side ?

Since the thumbnails are half the size of the original videos -- probably different scaling algorithms. Bilinear vs. bicubic vs. lanczos, etc. Some of the programs may give you control over this. Programs that use hardware decoders use the graphics card's setting.

I should try with non-resized frames to see if there's a difference.
=> Indeed, with only one 1920x1080 frame, the level of sharpness is about the same between MTN and VCSI (tweaked), so it might be a resizing issue. This seems to be the resizing code in the MTN source file :

        /* convert to PIX_FMT_RGB24 & resize */
        sws_scale(pSwsCtx, (const uint8_t * const*)pFrame->data, pFrame->linesize, 0, pCodecCtx->height,
            pFrameRGB->data, pFrameRGB->linesize);
        /*
        sprintf(debug_filename, "%s_resized%05d.jpg", tn.out_filename, nb_shots - 1); // DEBUG
        save_AVFrame(pFrameRGB, tn.shot_width, tn.shot_height, PIX_FMT_RGB24,
            debug_filename, tn.shot_width, tn.shot_height);
        */

Could “linesize” mean that it's using the bilinear algorithm ? (I remember reading that bilinear is among the less sharp resizing algorithms.)

On the Github page for the VCSI script I got this reply (from Revan654 who is apparently the main author of StaxRip, which contains MTN, as well as an internal thumbnails preview generator) :
“Bicubic is ffmpeg's default resizer, Lanczos is very similar to Bicubic. Spline would be a better choice since it contains better AA. The jpeg compression will always reduce quality, PNG is better format to use, filesize will be slightly larger.”
(AA = anti-aliasing ; MTN's output is blurry in PNG too so compression is not the issue.)

[jagabo]

a MP4 video I've created and encoded myself, using an Avisynth script containing the ConvertToYV12(matrix="Rec709") command, processed with MeGUI, doesn't have such a tag either, not according to MediaInfo anyway).

You can force the encoder to include this information. For example, in the x264 and x265 command line encoders you specify it with "--colormatrix bt709". MeGui gives you access to these in x264's advanced settings, Misc tab. With x265 you have to enter it manually in the Misc tab.

Some things to keep in mind: some programs may pay attention to the flag, some not. Some programs may assume <720p is rec.601, >= 720p is rec.709. Some programs just use one or the other. Some programs leave it up to the graphics card's driver to do the conversion to RGB (so behavior may change depending on the graphics card and driver).

Regarding full range vs. limited range, I know that videos are supposed to be recorded / encoded with the limited 16-235 range (right ?)

Most commercial distribution formats are limited range (DVD, Blu-ray, youtube, etc.)

but how are they supposed to be correctly displayed on a PC screen

Limited range YUV should be contrast stretched back to full range RGB on playback. That is, Y=16 (full black) becomes RGB=0, Y=235 (full white) becomes RGB=255.

and what should screenshots look like ?

You can use AviSynth to convert to RGB with ConvertToRGB(matrix="rec709") then view that in VirtualDub or some other editor that doesn't screw up RGB video.

MPC-HC screenshots are more contrasted, but the highlights are blown, while the screenshots from the other tools are duller, but with better preserved highlights. What does it mean with regards to the full range / limited range distinction, and what is the correct aspect ? Is the duller aspect normal, and is it a false impression that the more contrasted picture looks better when compared side by side ?

You'll have to check. It's very common for limited range sources to have content above Y=235 (DV camcorder video, for example). The correct conversion would crush all of those to the same shade of white (RGB=255). But it's possible to set the proc amp controls to bring out those details. With media players you have to be careful. Output may vary depending on the output renderer (Overlay Mixer, VMR9, EVR, Haali, etc.). It may also be effected by the graphics card's settings (many are set to "enhance" contrast, colors, skin tones, sharpness, etc., by default).

Since the thumbnails are half the size of the original videos -- probably different scaling algorithms. Bilinear vs. bicubic vs. lanczos, etc. Some of the programs may give you control over this. Programs that use hardware decoders use the graphics card's setting.

I should try with non-resized frames to see if there's a difference.
=> Indeed, with only one 1920x1080 frame, the level of sharpness is about the same between MTN and VCSI (tweaked), so it might be a resizing issue. This seems to be the resizing code in the MTN source file :

        /* convert to PIX_FMT_RGB24 & resize */
        sws_scale(pSwsCtx, (const uint8_t * const*)pFrame->data, pFrame->linesize, 0, pCodecCtx->height,
            pFrameRGB->data, pFrameRGB->linesize);
        /*
        sprintf(debug_filename, "%s_resized%05d.jpg", tn.out_filename, nb_shots - 1); // DEBUG
        save_AVFrame(pFrameRGB, tn.shot_width, tn.shot_height, PIX_FMT_RGB24,
            debug_filename, tn.shot_width, tn.shot_height);
        */

Could “linesize” mean that it's using the bilinear algorithm ? (I remember reading that bilinear is among the less sharp resizing algorithms.)

I don't think so. That is probably the image stride (width + horizontal padding). I believe that program is using ffmpeg's scaler so you may be able to add the scaling algorithm:

https://ffmpeg.org/ffmpeg-scaler.html

In my opinion, sharper isn't always better. Too much sharpening creates oversharpening halos and moire artifacts. For downscaling very sharp video I prefer to use bilinear (BilinearResize() in AviSynth). For less sharp material spline (Spline36Resize() in AviSynth).

[_Al_]

Are you doing this for only one type of video, as judging from those snaps in first post? Like that video has a specific color space and you want outcome to turn correctly.

Or are you talking in general, do you want to make those snap sheets for any video?

[pandy]

I had similar problem some while ago and it was solved with ffmpeg - series of surveillance videos, need to analyse them quickly, find changes and create thumbnail sheet. To navigate over video a time code is added to selected frames (so interested areas can be manually inspected) - all you need to do is entering/specifying how sensitive should be scene detection, lower number means more sensitive. Introduced some modification to strip unnecessary part.

@setlocal
@echo off
@echo "script"

@set filename=%~1

@set /p sens=Enter Scene Detection Sensitivity (0..1 e.g. 0.25): 
@echo Scene Detection Sensitivity is: %sens%

@ffmpeg -hide_banner -v 32 -stats -y -i "%filename%" -vf "drawtext=timecode='00\:00\:00\:00':r=25:x=(w-tw)/2: y=(2*lh):fontsize=64:fontcolor=black:box=1:boxcolor=0xFFFFFFFF@1,scale=iw/4:-4:out_range=full:sws_flags=spline:sws_dither=0,select='gt(scene\,%sens%)',tile=2x2" -vsync 0 %1_preview_%%03d.png

@endlocal
@timeout 30
@exit

[abolibibelot]

@jagabo :

You can force the encoder to include this information. For example, in the x264 and x265 command line encoders you specify it with "--colormatrix bt709". MeGui gives you access to these in x264's advanced settings, Misc tab. With x265 you have to enter it manually in the Misc tab.

Does this only add the corresponding tag, or also set the parameter for the conversion ? In other words, can this switch be used to directly convert a RGB source, or is it required to convert to YV12 before x264 / x265 encoding ?

Some things to keep in mind: some programs may pay attention to the flag, some not. Some programs may assume <720p is rec.601, >= 720p is rec.709. Some programs just use one or the other. Some programs leave it up to the graphics card's driver to do the conversion to RGB (so behavior may change depending on the graphics card and driver).

As if things were not complicated enough !

Limited range YUV should be contrast stretched back to full range RGB on playback. That is, Y=16 (full black) becomes RGB=0, Y=235 (full white) becomes RGB=255.

So if you saw the pictures in the first post, which one(s) seem(s) correct, with regards to the range specifically ? That's not very important in this particular case, but it's something I've been wondering about for quite some time, seeing how different players could display the same video with a significantly different aspect.

You can use AviSynth to convert to RGB with ConvertToRGB(matrix="rec709") then view that in VirtualDub or some other editor that doesn't screw up RGB video.

Alright, so at least VirtualDub can be used as a reference. Which other ones are known to have a reliable rendering, among those commonly recommanded on this forum ?

With media players you have to be careful. Output may vary depending on the output renderer (Overlay Mixer, VMR9, EVR, Haali, etc.).

And among output renderers, which are the ones known to be reliable in that regard, which are known not to ? Are there other known issues with the ones which are reliable in that regard ?

It may also be effected by the graphics card's settings (many are set to "enhance" contrast, colors, skin tones, sharpness, etc., by default).

That's what I discovered on this occasion : with Intel graphic driver (for CPU i7 6700K integrated graphic circuit) some “enhancements” are activated by default. Some players are affected by this (MPC-HC – perhaps depending on the active output renderer), some are not (VLC Media Player).


@_Al_ :

Are you doing this for only one type of video, as judging from those snaps in first post? Like that video has a specific color space and you want outcome to turn correctly.
Or are you talking in general, do you want to make those snap sheets for any video?

Well, I've discovered this issue while trying to do that particular task, but then I found out that it is more general. (At least I won't have tackled this foolish thing for nothing !) I also have a collection of movie files, mostly 1920x1080 Blu-Ray rips, for which I would like to make similar previews, I made some tests, and with the same tools I got a similar color shift. I added samples created from one of these movies on the suu-design.com thread (I also discovered some peculiar inconsistencies in the timecodes generated by Video Thumbnails Maker). Without a reference it would be near impossible to say which output is correct, but based on my previous tests, I'm pretty sure that – as I wrote earlier – SMPlayer, Scorp Video Thumbnails Maker with the “Engine 2” module, and VCSI tweaked with the Bt.709 line, are the ones which preserve the colors for Bt.709-converted videos, while the other three modules of VTM, MTN, the internal thumbnail creator from StaxRip, the native VCSI, MPC-HC, BSPlayer, PotPlayer, Auto Movie Thumbnailer, do not (reds are darker, same color shifting pattern as with the red car picture).

Regarding Auto Movie Thumbnailer, it has a menu called “MPlayer arguments” which is supposed to give control over the video rendering, after reading MPlayer's manual I tried to add -vo gl:colorspace=2, which as I understand it is supposed to force a Bt.709 conversion, but it produced the exact same output.


@pandy :

I had similar problem some while ago and it was solved with ffmpeg - series of surveillance videos, need to analyse them quickly, find changes and create thumbnail sheet. To navigate over video a time code is added to selected frames (so interested areas can be manually inspected) - all you need to do is entering/specifying how sensitive should be scene detection, lower number means more sensitive. Introduced some modification to strip unnecessary part.

Thanks for this tip, I'll try it ! (It's almost incredible how powerful and versatile that little tool is...)

[jagabo]

You can force the encoder to include this information. For example, in the x264 and x265 command line encoders you specify it with "--colormatrix bt709". MeGui gives you access to these in x264's advanced settings, Misc tab. With x265 you have to enter it manually in the Misc tab.

Does this only add the corresponding tag, or also set the parameter for the conversion ? In other words, can this switch be used to directly convert a RGB source, or is it required to convert to YV12 before x264 / x265 encoding ?

This only adds the flag to the video. You must connvert RGB to YUV yourself (or with YUV sources verify the matrix that was used) to be sure which matrix is being used. Then you can only hope that the player uses the flagged matrix during playback. As noted earlier you can't count on that.

Limited range YUV should be contrast stretched back to full range RGB on playback. That is, Y=16 (full black) becomes RGB=0, Y=235 (full white) becomes RGB=255.

So if you saw the pictures in the first post, which one(s) seem(s) correct, with regards to the range specifically ?

I think the second image, https://i.stack.imgur.com/Vg0IV.jpg, {“full range” in Intel graphic settings}, has the right levels. The others had blown out brights and crushed blacks. But I don't know exactly how your system was set up so I don't know for sure that source was really full range.

You can use AviSynth to convert to RGB with ConvertToRGB(matrix="rec709") then view that in VirtualDub or some other editor that doesn't screw up RGB video.

Alright, so at least VirtualDub can be used as a reference.

To be sure, go to VirtualDub's settings and turn off DirectX. Options -> Preferences -> Display -> Use DirectX for Display Panes -> untick. This will force VirtualDub to use Windows GDI to output video to the screen (avoiding the graphics drivers video output settings). And note you must ConvertToRGB(matrix = "rec709") (or rec601, or pc.709 or pc.601, whichever is appropriate for your source) in the AviSynth script to be sure of the levels/colors. VirtualDub itself usually uses a rec.601 matrix if it's given YUV to display.

Which other ones are known to have a reliable rendering, among those commonly recommanded on this forum ?

I always use VirtualDub for this type of testing. But in my experience most players refrain from molesting RGB on the way to the display.

With media players you have to be careful. Output may vary depending on the output renderer (Overlay Mixer, VMR9, EVR, Haali, etc.).

And among output renderers, which are the ones known to be reliable in that regard, which are known not to ? Are there other known issues with the ones which are reliable in that regard ?

There's no way of saying without checking them. Different graphics cards and driver updates result in different conversions.

[_Al_]

Try that ffmpeg first, very easy setup, I do not see that matrix variable in that filter in that cmd line,

but thumbnail generators in general might be wrong thing to study color spaces, too many variables and folks do not think twice about exact color space for just thumbnail generating.
It is very easy to setup using Vapoursynth and OpenCV(that puts it on screen if needed or write it on disc). Vapoursynth has also imwri but that needs to actually execute script thru vspipe to actually write it on disc, openCV is more friendly.

Not sure if you want to go this way, Vapoursynth, using Python, all this learning, just showing, it is possible thru a script, constructing a pic using StackHorizontal and StackVertical. But you have a total control, just like ffmpeg but a bit more, I'm hearing that ffmpeg uses default this and that for something. In Vapoursynth you control in and out during any conversion.
That movie is 2hours long, it took about 30sec to write an image, most of the time is indexing done by ffms2, not sure if 30 sec would work for you.

[abolibibelot]

@jagabo

I think the second image, https://i.stack.imgur.com/Vg0IV.jpg, {“full range” in Intel graphic settings}, has the right levels. The others had blown out brights and crushed blacks. But I don't know exactly how your system was set up so I don't know for sure that source was really full range.

Isn't it this one which has blown out brights and crushed blacks ? Although it does look better indeed.

To be sure, go to VirtualDub's settings and turn off DirectX. Options -> Preferences -> Display -> Use DirectX for Display Panes -> untick. This will force VirtualDub to use Windows GDI to output video to the screen (avoiding the graphics drivers video output settings). And note you must ConvertToRGB(matrix = "rec709") (or rec601, or pc.709 or pc.601, whichever is appropriate for your source) in the AviSynth script to be sure of the levels/colors. VirtualDub itself usually uses a rec.601 matrix if it's given YUV to display.

VirtualDub FilterMod also has a “Rec. 601 (SD) / Rec. 709 (HD)” option in “Decode Format”. It's strange because this shows that it (or its author) is perfectly aware of that convention, yet indeed uses the Rec. 601 setting by default, which is almost always wrong for 720+ resolutions.

@_Al_

Try that ffmpeg first, very easy setup, I do not see that matrix variable in that filter in that cmd line,

What do you mean by that ? The script proposed by “pandy” ?

I tried it as-is (I don't understand all the parameters yet), by dragging-dropping a test AVI/GAVC file (the same I used for those tests) on the script saved as a .bat, but had to stop it as I got a gazillion of lines like this :

...
[h264 @ 0000000002d500c0] data partitioning is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[h264 @ 0000000002d500c0] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
[h264 @ 00000000029e9640] data partitioning is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[h264 @ 00000000029e9640] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
...
[h264 @ 0000000002d500c0] data partitioning is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[h264 @ 0000000002d500c0] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
[h264 @ 00000000029e9640] data partitioning is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[h264 @ 00000000029e9640] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
frame=    0 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.00 bitrate=N/A speed=   0x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)
Exiting normally, received signal 2.

but thumbnail generators in general might be wrong thing to study color spaces, too many variables and folks do not think twice about exact color space for just thumbnail generating.

It is not to “study” color spaces, just to get it right the first time around and not have to start all over again because of such a pesky detail !
Even if it is not the purpose of those tools, they should still be accurate. And this issue also exists for simple screenshots, which are definitely used to scrutinize colors and other technical aspects of video files, so it's quite pervasive. It's the kind of thing, when one starts to notice it, it becomes impossible to ignore (it's like the aspect ratio, there are software tools which do not respect it by default, people who edit videos without bothering to correct The Horrror, and apparently legions of watchers who are not even aware that it doesn't look like it's supposed to, while it has pretty much become the norm – at least in Europe as far as I can tell – to present 4:3 archive footage in professional documentaries in ugly elongated 16:9 AR, makes me cringe every time I see such butcher job). Or maybe it's an “O.C.D.” thing of mine, but I'd venture that anyone posting on such a forum has at least some level of O.C.D.-ness !

It is very easy to setup using Vapoursynth and OpenCV(that puts it on screen if needed or write it on disc). Vapoursynth has also imwri but that needs to actually execute script thru vspipe to actually write it on disc, openCV is more friendly.
Not sure if you want to go this way, Vapoursynth, using Python, all this learning, just showing, it is possible thru a script, constructing a pic using StackHorizontal and StackVertical. But you have a total control, just like ffmpeg but a bit more, I'm hearing that ffmpeg uses default this and that for something. In Vapoursynth you control in and out during any conversion.
That movie is 2hours long, it took about 30sec to write an image, most of the time is indexing done by ffms2, not sure if 30 sec would work for you.

I'll try to investigate, it seems to be quite a lot to swallow just for one task, but could prove very useful to learn indeed (most I've did so far in Python is modify an existing script, so it would be a long way before being able to do something useful from scratch !). As for the time needed to generate each image, it would be less for shorter videos obviously, but significantly more than those dedicated tools, which apparently do not have to parse the whole video. Also, as it is there is no text header with informations about the file.

Again, each of those tools does it mostly right, and almost fits my requirement, but has at least one shortcoming.
I managed to install the GAVC codec, found here, now I can use the “Engine 2” module in Video Thumbnails Maker, but the color conversion is also wrong (whereas it was correct with other test files and that module). Meanwhile the author is not providing any insight on that matter...