Add Request for a Few More Options

[mgrhm]

This is already a great utility, and I appreciate its simplicity. It makes using guetzli much easier.

I have a couple of suggestions for additional options that would make it more versatile without complicating it too much.

The options:

• -recursive: so that it will recurse into subdirectories and compress all images found in there.
• -overwrite: to replace the original with the compressed image.
• -originals: where to move the original images when using the -overwrite option.

[romainmenke]

Thank you for the positive feedback!

side note : I just reworked the cli flags and args to be in line with the original Guetzli cli.

I will add the recursive option a.s.a.p (was already on my list)

I also think we can do with just an overwrite bool flag. If only the source argument is provided, images will be overwritten, if also the output argument is provided it will use the output dir to store the original files while overwriting the originals.

[mgrhm]

I don't think having dual-purpose flags is an improvement. It buries complexity for the sake of fewer flags.

Simplicity, in the form of explicit flags, is always preferable even if it increases the size of the program.

[romainmenke]

Wasn't thinking clearly yesterday :-)
Not keeping the originals is not an option as that would break this tool. It needs a folder with the originals to determine if they need to be compressed or not.

-originals: where to move the original images when using the -overwrite option.

This can already be managed by setting input and output folders to fit your needs.

I will leave this ticket open for the -recursive flag. I feel it would add to much complexity at this point but will come back to this later when the current code base has been proven to be solid.

[mgrhm]

The use case I'm advocating is for compressing an iPhoto library without interfering with the way it's organised.

The iPhoto/Photos library is a series of quite deeply nested directories which are structured by the software. The ideal tool to compress this would:

1. recurse into each directory;
2. copy the original to somewhere else;
3. compress each images it finds; and
4. remember which images it has already done for future runs.

simple-guetzli does part of this, but not all of this.

I found another tool that does recursive compressing and overwrites the originals, but it doesn't track which images it has already done and doesn't give me the option to copy the originals elsewhere.

[romainmenke]

Guetzli is primarily focussed on generating smaller images for websites although it can and will have a wider use, it is not my intention to serve all those needs with this tool.

As a web developer I have these requirements of this tool :

• be non destructive (no deletes or overwrites of original images)
• work nicely with git
• be transparent (the log is in json because it is readable/manageable for devs)
• be as fast as possible (only compress those images that have to be done)
• conform to generator semantics (running it twice will have the exact same result)

The changes you are requesting would break all the rules :)

---

Just to give you some info about the inner workings :

• image_1 is added to folder A
• simple-guetzli is run
• it gets the mod time and computes a hash of image_1.
• no log exists
• it compresses image_1 to folder B as image_tiny_1
• it stores the log

---

• image_2 is added to folder A
• simple-guetzli is run
• it gets the mod time and computes a hash of both image_1 and image_2 .
• a log exists for image_1 and both the mod time and hash haven't changed.
• no log exists for image_2
• it compresses image_2 to folder B as image_tiny_2
• it stores the log

---

• image_1 is updated to folder A
• simple-guetzli is run
• it gets the mod time and computes a hash of both image_1 and image_2 .
• a log exists for image_1 and both the mod time and hash have changed.
• a log exists for image_2 and both the mod time and hash haven't changed.
• it compresses image_1 to folder B as image_tiny_1
• it stores the log

As you can see it is critical to keep the originals as these are used to determine if one needs to be recompressed or not. Overwriting the originals would alter them which would cause simple-guetzli to compress them again.

[mgrhm]

Thanks for clarifying. It definitely seems like I'm looking at a different use case than you. The choices you've made suit your own use case perfectly.

Sorry -- accidentally closed this issue.