Timo Kokkonen

@necros2k7, artifacts expire after couple months (thats under github's control). This fix will be in next release that I hopefully have time to in next couple days.

I don't see issue with the latest version. Can you provide some more details? Results testing with the (MacOS) binary from the latest release: ``` $ ./jpegoptim test.jpg test.jpg 1944x2592...

Looking the other other similar calls, I updated the pull request to use `%08x` as that seems to match how addresses are printed in the surrounding code...

I checked in change 8c68bac5ad1904c52f0369a0a49724b56b7d7cbe that changes _--treshold_ option to accept decimal numbers as parameters. So it now should work specifying ``-T0.5`` ?

Unable to reproduce with the current 'master' branch (tested with currently latest libjpeg version "9e"): ``` $ ./jpegoptim -f --all-progressive 'crash1_SEGV_caused_by_READ_memory_access_at_jpegoptim.c^%631^%3' crash1_SEGV_caused_by_READ_memory_access_at_jpegoptim.c^%631^%3 [ERROR] ``` ``` $ ./jpegoptim -f --all-progressive 'crash_SEGV_caused_by_READ_memory_access_at_jpegoptim.c^%710^%18'...

I checked in change to relax checking of the model block (8cec1ee71713480a377c9f4471fe5c18dbfd4dea), can you try it with the new version? Also, can you post output with the -d flag, that...

What is the firmware version on your unit? (I can add note in the README, in case someone else runs into same issue...)

HEIC seems to be Apple's variant of [HEIF](https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format). I don't see _jpegoptim_ supporting HEIC, unless support for it is added to existing JPEG libraries (which seems unlikely).

Finally got around to look into this further. AddressSanitizer was 'hiding' what was happening, when compiled withouth it NULL pointer dereference was apparent. Bug was indeed in jpegoptim, this change...

Current parallel processing implementation relies on _fork()_ system call, that is not present in Windows (or has it been recently added?), so it's not trivial to enable this feature on...