Squoosh-with-CLI icon indicating copy to clipboard operation
Squoosh-with-CLI copied to clipboard

Wish: option not to change extension

Open markstos opened this issue 6 months ago • 2 comments

Is your feature request related to a problem? Please describe.

I'm trying to optimize 2,000 images across many directories.

A challenge I'm running into that my ".jpegs" have been renamed to ".jpg".

Because all the new images need to have the exact same path at the end of the project, it would be more convenient if a file that started out was a ".jpeg" stayed a dot ".jpg".

Describe the solution you'd like

First possibility is to change the behavior so that when the output format matches the input format, always preserve the extension.

Second possibility is to preserve backwards compatibility with the current behavior, add a flag --preserve-extension so when the input and output format matches, keep the extension only if the user explicitly asks for that.

Does other service/app have this feature?

I presume.

markstos avatar May 12 '25 15:05 markstos

Hi @markstos, the CLI currently supports the --suffix <suffix> flag. Would this help resolve the issue given your workflow?

aggregate1166877 avatar May 19 '25 10:05 aggregate1166877

@aggregate1166877 The --suffix option to force the extension of the output files would help here, yes.

I still think it's a better default behavior to preserve the extension if it doesn't need to change.

Imagine a folder of images for a Wordpress site. Changing all the extensions from ".jpeg" to ".jpg" would break all the links. I can't see how that's a better default behavior than leaving a valid JPEG extension alone.

markstos avatar May 19 '25 14:05 markstos

Here's an eample of a real bug I encountered by the automatic renaming behavior: In the input data set, there were WordPress feature images with default file names. And for some reason there were files with names both names like "feature-1.jpg" AND "feature-1.jpeg". When running this tool in bulk over many files, the effect was a collision, as the contents of both "feature-1.jpg" and "feature-1.jpeg" were written to the same file.

The possibility of collisions like this is a second problem in addition to breaking/changing input file paths.

markstos avatar Jun 06 '25 02:06 markstos

@markstos Ah, I see what you mean. I had assumed you were trying to avoid overwriting existing files. This could certainly be a useful feature.

If it's not too difficult, it might also be helpful to include some very basic checks that issue a warning when something appears obviously incorrect, e.g. "Warning: Saving a PNG file as JPEG. This is likely a mistake."

aggregate1166877 avatar Jun 09 '25 00:06 aggregate1166877