Multithreading support for faster HEIC loading (Microsoft HEIF are super slow in WIndows)

[mdrejhon]

I have a "Camera Uploads" folder of over 10,000 HEIC images synchronized from iPhone/iPads, to multiple computers (via cloud sync currently configured to preserve HEIC/HEIF instead of autoconvert to JPG).

Microsoft's HEIF extensions are extremely slow (CPU based) and single-threaded:
https://www.microsoft.com/en-us/p/heif-image-extensions/9pmmsr1cgpwg

It works with WinThumbsPreloader, but it is ASTONISHINGLY SUPER PAINFUL SLOW (not your fault, it's Microsoft's since it's similarly painful slow in Explorer too) ....

On some computers (that my can take hours to render HEIC images at 1 image per second on some CPUs -- about 10x to 50x slower than JPG files.

To fix the slowness, I would like to see WinThumbsPreloader go multithreaded, to render .heic and .heif files between 8x to 20x+ faster (depending on available cores/threads of your CPU).

[mdrejhon]

Update: I just discovered one of the forks has multithreaded generation added by him:
https://github.com/inthebrilliantblue/WinThumbsPreloader

But the @inthebrilliantblue installer has an "Update check failed" and does not let me install it (even if I uninstall the bruhov version first).

Is there a way to install the multithreaded version easily without recompiling via Visual Studio? Or can the original author (@bruhov) merge the @inthebrilliantblue multithreaded patch into this build?

The multithreading patch is at inthebrilliantblue#1

[inthebrilliantblue]

So all I added was a cli option to toggle the _multithreaded flag, and the parallel foreach code to do the work. I never did get around to touching the installer or add a context menu to select the MTed option.

I mostly just needed a cli option where I setup a task to run a few times a day for a highly rotating dump folder for photographers. I may be able to change the installer, but its been a hot minute since Ive looked at this project. Also while the MTed code works just fine for me, it hasnt really been tested in other environments so Im not sure how it will work for you.

You can download a compiled version of my MTed version on tag 1.0.2:

https://github.com/inthebrilliantblue/WinThumbsPreloader/tree/v1.0.2

[Kieaer]

@inthebrilliantblue How to make the -m option work?
No popup and not preloaded.

I tried
WinThumbsPreloader.exe -m C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe -r -m C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe -m -r C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe -r C:\Users\cloud\Downloads\test // work
WinThumbsPreloader.exe -rm C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe -mr C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe C:\Users\cloud\Downloads\test // work

[mdrejhon]

@Kieaer @inthebrilliantblue
You're right... I just git pulled that repo, compiled it. It appears to not recognize the -m option nor show it in the startup screen (as in screenshot above).

I wonder if part of the pull request wasn't fully uploaded? (Will dive into the source later)

[inthebrilliantblue]

I created pull request #20 with the multi-threaded patch I did. Apparently I just did a Parallel.ForEach with an absurd amount of threads it can spawn for my servers. Someone might want to bring it down, but C# tends to manage the tasks it spawns with Parallel.ForEach based on the computer it runs on, so it "shouldnt" be a problem.

[inthebrilliantblue]

Here is an example of it running on my desktop using 113 threads.

[inthebrilliantblue]

@inthebrilliantblue How to make the -m option work?
No popup and not preloaded.

I tried
WinThumbsPreloader.exe -m C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe -r -m C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe -m -r C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe -r C:\Users\cloud\Downloads\test // work
WinThumbsPreloader.exe -rm C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe -mr C:\Users\cloud\Downloads\test
WinThumbsPreloader.exe C:\Users\cloud\Downloads\test // work

It runs with this:

WinThumbsPreloader.exe -m -r C:\Users\cloud\Downloads\test

Each option needs to be separated for it to be detected. That could be improved upon. As for why it didnt work for you, Im not sure.

What happens if you just do

WinThumbsPreloader.exe

?

[inthebrilliantblue]

@Kieaer You should see this if you just run the exe with no options, make sure it has the -m option listed in the window.

[mdrejhon]

Hello.

1. I did this:
   git clone https://github.com/inthebrilliantblue/WinThumbsPreloader.git

2. I opened the .sln file in Visual Studio 2017

3. I modified AssemblyInfo.cs to Version 1.0.2 as an additional verification that I'm compiling the correct copy

4. I compiled (easily, no errors, no warnings)

5. I ran WinThumbsPreloader.exe to pop up this dialog below, and the -m option does not show in the dialog which is missing the -m option:

@inthebrilliantblue Are you sure that your git pull request is complete? I think there might be missing code.

Can you test a git pull into a 2nd separate folder on your disk, and verify if there are any missing files / missing changes? Please do a verification by this clean pull request -- and you will see the missing "-m" option suggestive your your repo is incomplete (e.g. missing a file or missing a change) -- i.e. a forgotten file to be comitted.

I also viewed your source code files and there's no occurence of the text modification "-m Multi-Threaded mode" which is another 2nd check that makes me suspect this pull request may be missing code.

I did a grep -R -i "Multi-Threaded mode" to find the location of your dialog change, and zero results appeared (anywhere in the @inthebrilliantblue source code tree).

If so, @inthebrilliantblue, would it be possible to add the missing code to your original github & this pull request? This would be a major speedup for me for a File Explorer limitation with .HEIC / .HEIF files.

[inthebrilliantblue]

Looking at my old code, it looks like the AboutForm.cs did not get updated in the repo like it should have, but all of the actual code to run multi-threaded mode is in the repo. That form missing shouldnt cause any issues, grep for "multithreaded", "_multiThreaded", and "Parallel.ForEach" and see if you get results.

[mdrejhon]

Yeah, I see hits on those greps.

Repeating some tests. I'll report back. I'm gonna do a Debug session. It's rare I'm this eager, but -- Microsoft HEIC is so super painfully slow with File Explorer's single-threaded thumbnails generator. (Hope Windows 11 fixes it)

The other day, I tried testing it on a folder full of .HEIC files and it wasn't any faster, attempting to breakpoint on ForEach and seeing what happens.

[inthebrilliantblue]

If your .HEIC files are on spinning HDD's, then it most likely wont be faster. IO will always be the bottleneck, not the actual generation of the thumbnails.

[mdrejhon]

It's definitely not disk.

(1) Samsung 960 Pro SSD here, in a 4-lane NVMe M.2 slot.

and

(2) Larger 2+ megabyte .HEIC files take almost 1 second to convert even on an SSD, while even larger 3-5 megabyte .JPG files can convert 10x+ faster even for HDD. .HEIC is that painfully slow on Windows machines compared to Mac because Microsoft uses 100% CPU (no GPU acceleration) for converting HEIC.

HEIC is more than 10x slower than JPG on Windows

On Windows machines specifically, it is literally honestly truly more than an order of magnitude slower per byte. It's why I desparately want multithreading for .HEIC because Microsoft didn't optimize .HEIC like Apple did.

On a single thread, it can take HOURS to convert an iPhone's worth of many (tens) thousands of smartphone photos captured natively in Apple's preferred .HEIC / .HEIF formats. That's why most sync software (e.g. Dropbox) converts to JPG first before syncing, but I didn't want the quality loss of downconverting .HEIC to bigger .JPG files when syncing from my iPhone/iPads.

It's faster to cloud-sync thousands of photos to 5-6 computers if the images are smaller file size like HEIC. Many Internet connections have slow upload speeds for cloud syncing of photos, so this is where smaller HEIC file sizes helps. Although I've since upgraded to FTTH with fast upload, the HEIC still remains. I'm just paying a severely time-punitive thumb-generation penalty, however. And this is why I express great interest in multithreaded HEIC thumbnail generation.

Imagine maximizing your File Explorer window in Large Thumbnails mode, and having to wait 30-60 seconds for all the thumbnails to generate -- just only for that screenful. PgUp and PgDn is simply AGONIZING due to Microsoft's suboptimal HEIC engine

For People Unfamiliar With Why HEIC is Good

800 kilobyte HEIC photos look better than 2 megabyte JPG files -- it's a pretty compact, and efficient photo compression format. I made the (semi-stupid) decision not to pre-convert to JPG for performance, and am having to bear Windows inefficiency with HEIC, for the superlative compression efficiency of HEIC.

(JPEG efficiency harkens way back to the MPEG1 days literally, while HEIC is pretty much H.265 in compression efficiency -- so huge amount of space savings keeping it HEIC native)

If they were all Macs it would be so much faster, since Apple's HEIC implementations are GPU accelerated. Thumbnails for HEIC just flies almost 100x faster on an M1 Mac, for example.

Everytime I dump a new batch of photos, I have to put up with Windows' slowness in regenerating thumbnails on 5-6+ sync'd computers, as they keep separate thumbnails databases.