ePUB Optimizer

[Toxaris]

Originally Posted by Freeshadow

Some ideas:
For metadata removal only you could use jpegoptim too.
Similar could be done with SVG: http://code.google.com/p/svgmin/

I will check out svgmin. However, there must be a version available for Windows, Linux and OSX or it must be available for build. Otherwise I will not use it. The same applies for jpegoptim, although for that one I also will have to check the additional advantage.

Originally Posted by Freeshadow

Are you recompressing with Zopfli?
AdvanceCOMP:
Advpng for the images;
Advzip for the finished epubs.

When I was digging for shrinking tools for Hitch I also searched for minification tools which could be applied to the epub's CSS and sources, but found only *. js stuff for use with webservers. Have no idea how to utilise it. Minification could be worth being looked up too.

No, I do not use Zopfli. I know it compresses even more, but the speed is ridiculous compared to the saved space. I just use the highest compression level. BTW, Sigil uses the same compression. I will check about minification, but I don't expect much from it.

Originally Posted by Freeshadow

Apart from that - what you are doing here: intelligent standalone tools for font subsetting; storage footprint optimisation (I'm a compression fan myself ) - what you do is exactly literally what I had in mind. It's development in the direction that matters. Bleeding edge, tailor made best possible epubs. Kudos and big big thanks for what you do.

Yes, I have created the tools for font subsetting myself and it is using intelligent algorithms to check the actual glyph usage. I can stand that I haven't solved the OTF issue so far... For the imaging I am using standard applications which are available and the standard zip-routines (although not a standard zip-library).

[Toxaris]

Originally Posted by JSWolf

There is a way to optimize JPG images even more than is done with ePUB Optimizer. That requires using jpegtran with a specific scan order for RGB jpeg and a specific scan order for greyscale jpg. But you have to be careful. Using the wrong scan order will cause your image to be 0 bytes.

If you want to know about this, I can post what you is needed to get that extra bit reduced.

I was not able to get this to work in a reliable way. Often the images were scambled or reduced to 0 even if the right scan order was used.

[Toxaris]

Originally Posted by eschwartz

I get great results out of zopflipng -- just remember to set it going overnight it takes a while.

Really? I think that optipng already is taking a long time.

[Toxaris]

Originally Posted by JSWolf

I get even better results converting to JPG as most time, the images in PNG don't need to be PNG.

Really? Most of my images are better in PNG (graphs, B/W drawings). In those cases the PNG a whole lot smaller than the JPG of the same.

[Toxaris]

Originally Posted by GrannyGrump

@Toxaris, Yes, please do share your parameters. I am looking for ways to get smaller image files, because it seems like every project I start on a whim turns out to be very image-heavy. Especially now, when I have decided to go with higher-resolution images instead of 600x800.

The important parameters I use:
JPEGTRAN: -optimize -progressive
OPTIPNG: -force -o7
GIFSICLE: -O2

[JSWolf]

Originally Posted by Toxaris

I was not able to get this to work in a reliable way. Often the images were scrambled or reduced to 0 even if the right scan order was used.

I've not (yet) had a problem with scrambled images. But I have seen the 0 bytes images when the wrong scan order is used. One thing I have seen is B&W/grayscale images saved as RGB (from the publisher). Would there be anyway to automate converting those to proper grayscale?

[eschwartz]

Originally Posted by Toxaris

No, I do not use Zopfli. I know it compresses even more, but the speed is ridiculous compared to the saved space. I just use the highest compression level. BTW, Sigil uses the same compression. I will check about minification, but I don't expect much from it.

Originally Posted by Toxaris

Really? I think that optipng already is taking a long time.

That is why I wouldn't recommend using it unless you specifically know what you are getting into...

There are plenty of time-wasting things that I would never sit around watching which I am more than happy to leave running overnight.

zopflipng is definitely not something to use in a generic automation routine.

I am happy to set it running on a directory overnight and reopen books to update the images, if it means space reduction -- even minor. It doesn't really cost anything (except preparation) and overly large books make me sad.

[eschwartz]

Originally Posted by JSWolf

I get even better results converting to JPG as most time, the images in PNG don't need to be PNG.

Originally Posted by Toxaris

Really? Most of my images are better in PNG (graphs, B/W drawings). In those cases the PNG a whole lot smaller than the JPG of the same.

^^ This...

[Freeshadow]

Originally Posted by JSWolf

One thing I have seen is B&W/grayscale images saved as RGB (from the publisher).

Sometimes saving as grayscale gives you bigger images than rgb (even if it doesn't make sense at 1st glance) I haven't archive the links to explanations but in short it's because the difference in which data is saved in both types (rgb in col. vs. I think satur. in grayscale type images) so it can be what you have seen.
As to your other statement: suggested converting from a losless (PNG) into a lossy (JPG) format as an optimisation (sic!) step is :facepalm:.
Go and wash your mouth out for that (or your hands - you were typing)

[JSWolf]

Originally Posted by Freeshadow

Sometimes saving as grayscale gives you bigger images than rgb (even if it doesn't make sense at 1st glance) I haven't archive the links to explanations but in short it's because the difference in which data is saved in both types (rgb in col. vs. I think satur. in grayscale type images) so it can be what you have seen.
As to your other statement: suggested converting from a losless (PNG) into a lossy (JPG) format as an optimisation (sic!) step is :facepalm:.
Go and wash your mouth out for that (or your hands - you were typing)

A lot of PNG is not needed to be PNG. I see covers in PNG that are a lot larger then they need to be and saving in JPG cuts the size. I do compare the two images to see if there is a difference and usually not anything noticeable.

[Barto]

Hi Toxaris,
I have been trying to add your plugin to Sigil (0.8.6) but to no avail.
The notification is: 'Error: not a valid Sigil Plugin'.
Can you tell what could be the cause of this?

[Toxaris]

Please report this in the corresponding plugin thread, because there are differences...

Please describe what you are doing exactly there.

[Hitch]

Originally Posted by JSWolf

A lot of PNG is not needed to be PNG. I see covers in PNG that are a lot larger then they need to be and saving in JPG cuts the size. I do compare the two images to see if there is a difference and usually not anything noticeable.

Dumb Q?: why not just save it as PNG-8?

Hitch