Prevent bigger file sizes if original is smaller about caesiumph HOT 8 CLOSED

Definitely a), b) would be very confusing. Can you provide one or more of the images that actually have a size increase after compression? I'd like to have a look at them for testing purposes.

from caesiumph.

Can i just drop them here? Or will they get compressed or something by github? Or should I e-mail them?

from caesiumph.

I think they won't be compressed by GitHub, but, just to be sure: caesiumph {at} saerasoft [dot] com

from caesiumph.

okay, email has been sent :)

from caesiumph.

While I investigate on the compression results to completely avoid increasing the size - although it's impossible to be 100% sure it won't happen sometimes - there's the fix. Since we can't exactly predict the output filesize due to EXIF, the file is actually compressed and then the software will check whether the output is bigger or not. If this happens, the output file is removed and is replaced by a copy of it. More precisely, if we wanted to overwrite the originals, the output files are actually compressed in a temporary directory and eventually moved over the originals. The temporary folder is destroyed when CaesiumPH is closed.

from caesiumph.

Sounds great, so if we won´t overwrite the originals, let's say we sent the compressed images to a custom folder or subfolder it will

1. compress images and send to the selected folder
2. will now compare this folder with the temporary files?

Or will it be just on the fly image after image?

from caesiumph.

On the fly. For each compressed file, it performs the check and copy the original file into the subfolder/custom folder.

This is the flow if we don't want to overwrite the originals:

1. Compress the file into the new folder (or with a suffix)
2. Compare sizes
3. If the compressed is bigger, remove it and replace it with a copy of the original

Instead, if we want to overwrite them:

1. Compress the file in a temporary folder (which is different everytime CaesiumPH is started)
2. Compare sizes
3. If the output is smaller, move the file from the temporary folder into the original one, overwriting the file (the original is actually being removed before moving the new one). If it's bigger, do nothing as the original is already in the right place
4. Destroy the temporary folder on CaesiumPH exit

This way is a bit slower than the previous process because we need to remove/move some files in a few cases, especially when overwriting them.
Also, doing this on the fly for each file ensures the right behaviour upon cancelling the process or if an unexpected error kicks in.

from caesiumph.

Okay, sounds exaclty the right way. Sure, speed is a bit slower, but I think in the end the result is the more important thing ;)

from caesiumph.