Open necros2k7 opened 1 year ago
I seem to recall that, jpegoptim discards any JFIF marker(s) found in the input image, since libjpeg adds one in the output image on its own. This is done to avoid "duplicate" JFIF markers in the output file.
If you've noticed change in behaviour that likely is caused by compiling jpegoptim against different version of libjpeg (or using different compatible library like libjpeg-turbo or mozjpeg).
Your latest win64 win binary keeps it - яШяа JFIF
I had never given much thought about how JFIF markers were handled. It was left to whatever was default behavior of the JPEG library being used.
I made change (22b1dd82f30d86cff26de86946be17785c689908) to add options to specify whether to keep or remove those (--keep-jfif and --strip-jfif). While default is to preserve JFIF marker (if its present in input file).
@tjko Thanx, it`s exactly what I meant, can you make --strip-jfif default option as it was before?
@tkjo can you fix artifacts` expiration pls? wanted to test latest build with --strip-jiff option
@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.
@tjko JFIF header came back again) --strip-jfif doesn`t work
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 24bit N JFIF,Exif,XMP,XMP,ICC [OK] 1370168 --> 1370168 bytes (0.00%), skipped.
$ ./jpegoptim test.jpg --strip-jfif
test.jpg 1944x2592 24bit N JFIF,Exif,XMP,XMP,ICC [OK] 1370168 --> 1370150 bytes (0.00%), optimized.
$ ./jpegoptim test.jpg
test.jpg 1944x2592 24bit N Exif,XMP,XMP,ICC [OK] 1370150 --> 1370150 bytes (0.00%), skipped.
Am I miss smthing? Or JFIF part of header was deleted in previous versions? And now not.