Lepton support

[SergeiVorobyov]

• Added support for Dropbox Lepton image format for images with *.lep extension. lepton-avx.exe has to be downloaded from https://github.com/dropbox/lepton/releases/download/1.2/lepton-avx.exe and placed to JPEGView folder.

  Default Lepton parameters can be changed in config: LeptonToolName=lepton-avx.exe LeptonToolExtraArgs=-allowprogressive -memory=1024M -threadmemory=128M FilesProcessedByLepton=*.lep

Examples of Dropbox Lepton images can be found there: https://github.com/microsoft/lepton_jpeg_rust/tree/main/images

[sylikc]

Sergei, thanks for the PR and bugfix... I need to review the way the the support has been added.

Having an external executable write to a file is not really support the way that JPEGView supports other formats, would likely interact poorly with file change detection, etc, and would be considerably slow when browsing. Since you're already hooked into ImageLoadThread, can you add in support via the lepton library?

[SergeiVorobyov]

Sergei, thanks for the PR and bugfix... I need to review the way the the support has been added.

Having an external executable write to a file is not really support the way that JPEGView supports other formats, would likely interact poorly with file change detection, etc, and would be considerably slow when browsing. Since you're already hooked into ImageLoadThread, can you add in support via the lepton library?

Actually the Lepton library doesn't exist. At least I didn't see it yet. Please let me know if you know any implementation that can be used as the library. Standalone converter works with a temporary file, and it is an only area for a possible improvement. I could try to switch the temporary file exchange to pipes. It could save some time by reducing temporary JPEG file IO operation time. Fortunately, lepton-avx.exe works with pipes well.

[sylikc]

@SergeiVorobyov I've been swamped with work irl this past week, i'll take a look after this weekend. Before I left off, I was considering looking at the lepton source to extract the relevant parts... it's APL which is GPL compatible.

(Thanks for removing the updated project/solution files and squashing the commits. That makes it easier to merge.)

Piping

I could try to switch the temporary file exchange to pipes. It could save some time by reducing temporary JPEG file IO operation time.

I would like the idea of piping instead of writing to a file and reading back. I think that would at least be partially cleaner. If you can implement that piping, that'd be great

Other thoughts I had was, I would also need to test whether this executable idea works in the context of 32-bit and 64-bit, and like, that executable says AVX, whether it supports other environments, or what's the system requirements.

Generic similar support method

And lastly, if this type of file can be supported by an external executable and then piped into JPEGView, if it can be coded in a generic way which would pretty much support all types of other files with an external executable. Like I was going to investigate and look into your implementation if it can be made to support pretty much any type of file... say, via a config file, like an INI setting or like (just speaking off the top of my head) another config file to support other file types using the same method.