In database, cover.jpg should be reduced in size and quality to conserve space

[PhilippeBruno]

I just inspected the "C:\Users\%username%\AppData\Roaming\EDRLab.ThoriumReader\publications-dev" folder and I see it contains folders for all the ePubs in the bookshelf. In each of the numbered subfolders, I see two files:

• book.epup: a straight byte-for-byte copy of the original ePub (only the date stamp is different)
• cover.jpg: a straight byte-for-byte extraction of the cover image from the above ePub

That's a lot of redundancy. I am sure it is designed this way for performance reasons, but as way too many ePubs are badly designed and contain overly large cover images, often larger in size than the entire text content of the book, this represents a lot of wasted space.

In my view, for the benefits of displaying a cover image of the ePubs contained in the bookshelf, a miniature version of lower quality should suffice.

For example, let's take a typical novel:
book.epub 2,048 KB
cover.jpg 1,532 KB [a 1400x2032 pixels JPG with a quality of 98]

If I reduce the JPG to a reasonable 300x435 pixels (same aspect ratio) and I lower the JPG quality to 80, I obtain a much more acceptable file size of 21 KB!

I would attach the JPGs to prove my point, but somehow this editor keeps inserting them as pictures.

[danielweck]

Interesting suggestion.

Note that the publication cover image is rendered in two different “modes” in the Thorium GUi:

1. the small thumbnail displayed in the library window’s list of available publications.
2. the larger expanded image in the “publication info” popup modal dialog, when the thumbnail is clicked.

Oversized cover images are obviously unnecessarily large given their current use in Thorium, but we would need of think carefully about the runtime cost implications when processing images at import time, and whether or not it would be desirable to keep the original high-res file as a stand-alone asset (external to the EPUB) for future features (e.g. full screen render)

[danielweck]

Moving this to a "discussion" as the merits of a solution and the tradeoffs of its technical implementation need to be evaluated (bug triage, we are trying to keep the issue tracker actionable for development planning).