Closed catharsis71 closed 2 years ago
This sounds good idea and shouldn't be difficult to implement new --nofix option... Do you have an example (corrupted) jpeg file to provide for testing?
This includes example files for what seems to be the 5 most common types of repairable warnings:
Premature end of JPEG file premature end of data segment extraneous bytes before marker bad Huffman code Invalid SOS parameters for sequential JPEG
Thanks for the samples.
I added new --nofix option (91054c26540fb24e6fed348f9afa01428b02ec2a). If you can please test that it works as expected.
Excellent, this is great
I did discover one more scenario that I had a question about
Sometimes people hide archives inside images by for example appending a ZIP or RAR to the end of an image
with PNG images, optipng detects these ("Extraneous data found after IEND") and only processes them if -fix is used
however I've noticed that for JPEGs, jpegoptim doesn't even throw a warning:
$ jpegoptim -n -v *.jpg
hidden.jpg 570x362 24bit N IPTC JFIF [OK] 6127023 --> 110390 bytes (98.20%), optimized.
In this case if you're paying attention you can notice something unusual happened because of the drastic file size reduction, although in some cases it may be much harder to notice like if the hidden archive is relatively small
Would it be theoretically possible to detect and throw a warning in cases like this?
This is getting out of the scope of what I opened the issue for... if you think it's feasible I could open another issue for it, but if it's not feasible or not something you want to do then that's fine, no big deal.
Thanks for all your assistance.
I've attached a zip containing the "hidden.jpg" referenced above, if you want it.
jpegoptim is relying on libjpeg for decompression (and compression), looks like libjpeg does not detect (or care) about any data that may be present after end of the JPEG image data....
Looks like checking current position in input file after decompression is complete, would seem to reveal if there is extraneous data in the file.
I added quick check (9aad9235cd8f1ef4b68139d03682b9e7c794b6ec), this would seem to work as expected (except when input file is fed via stdin...)
I compiled the current version and it's looking really good. This is going to be super useful.
$ jpegoptim-test --nofix -v *.jpg
hidden.jpg 570x362 24bit N IPTC JFIF (Extraneous data found after end of JPEG image) [WARNING] [ERROR]
prehidden.jpg 570x362 24bit N IPTC JFIF [OK] 110390 --> 110390 bytes (0.00%), skipped.
$ jpegoptim-test -n -v *.jpg
hidden.jpg 570x362 24bit N IPTC JFIF (Extraneous data found after end of JPEG image) [OK] 6127023 --> 110390 bytes (98.20%), optimized.
prehidden.jpg 570x362 24bit N IPTC JFIF [OK] 110390 --> 110390 bytes (0.00%), skipped.
Only thing that struck me as slightly odd... if I typo an argument (like "--no-fix" instead of "--nofix") it outputs an error but then goes and ahead and processes anyway (potentially doing something undesired). I think most programs will abort if an unknown argument is encountered, in fact, I don't remember ever seeing a program that would just ignore the unknown argument and continue running. Is this as intended?
$ jpegoptim-test --no-fix *.jpg
jpegoptim-test: unrecognized option '--no-fix'
hidden.jpg 570x362 24bit N IPTC JFIF (Extraneous data found after end of JPEG image) [OK] 6127023 --> 110390 bytes (98.20%), optimized.
prehidden.jpg 570x362 24bit N IPTC JFIF [OK] 110390 --> 110390 bytes (0.00%), skipped.
Thanks, I guess nobody had noticed the weird argument parsing until now.
I updated the arguments parsing, it was also not giving any error if some option was passed, but no input file argument at all...
43fae9d15805dd441fd5d4e1ca3ffdaa208588c6
In certain cases files with corruption are repaired automatically:
It would be very useful to have an option to skip processing files for which corruption such as this is detected
I know you can do a dry run but I'd prefer not to have to do a dry run every time I use the software just in case there are any damaged files (which there usually aren't)
Compare to optipng (a similar program but for PNG files), which by default just outputs a warning for damaged files, and only repairs them if the "-fix" option is used. Repairing probably should be the desired default for most people but could there not be a "-nofix" option for those like me who want to examine the files more closely before deciding whether to repair or not?