Aura ONE Kobo Aura One owners thread

[DNSB]

Originally Posted by Mingyar

As I said, It's not 6000 but 4000 books max if you generate cover images for each book. With 4000 books on the device, 3 Go for the cover images ...

I have to wonder just how large your cover images are. 3 gig for 4000 cover images is about 805KB per image set. When I look at the properties of the .kobo-images directory on my KA1, it has about 470MB with ~2600 ebooks loaded.

[Mingyar]

To be sure the Kobo has generated all the covers, you have to scroll all pages in list view of your library.
For each book, if I'm right, Kobo fw generates 4 files for the cover.

I can't answer you for the size of the covers in all my books. I just can say I did this test :
1) Load 4000 books in the Kobo by Calibre,
2) Get free memory in technical parameters
3) In list view mode, display the 667 pages of 6 books per page.
4) Get again free memory.
Result, 3 Go lost.

[davidfor]

Originally Posted by Mingyar

To be sure the Kobo has generated all the covers, you have to scroll all pages in list view of your library.
For each book, if I'm right, Kobo fw generates 4 files for the cover.

I can't answer you for the size of the covers in all my books. I just can say I did this test :
1) Load 4000 books in the Kobo by Calibre,
2) Get free memory in technical parameters
3) In list view mode, display the 667 pages of 6 books per page.
4) Get again free memory.
Result, 3 Go lost.

Sorry, you are wrong. Firstly, recent firmware only uses three sizes for the cover image. There was a fourth used for a while, but they stopped using that ages ago.

The images are generated as needed. And only the sizes needed are generated. Paging through the list will only generate one size. If you open a book, then the largest size will be generated. The third size is used when you view the details page for the book. And it is only generated when you open the details page.

If you are using calibre to send the books, have you configured the driver to send the covers as well? With this turned on, it will generate all three covers images (or four for the appropriate firmware) and put them on the device. This could have been using more space up until the latest version of calibre. In the past, the cover was sent unchanged for the largest version used as the screensaver. This worked, as the device resized when displaying the screensaver. But, it wasted space and didn't match what Kobo did for downloaded books. If you want to reclaim some space, you can use my Kobo Utilites plugin to resend the covers with the new sizing. Or simply delete all the covers images and let the device regenerate them as needed.

(Hmm, I should add an option to the cover delete to only delete the screensaver cover. That way space could be reclaimed for books that have been finished but are still on the device)

[Mingyar]

Thanks for your detail answer davidfor.
With Calibre, I only use the plugin to send epub as kepub (KoboTouchExtended 2.8.2).
The Load covers (Charger des couvertures in French) is not checked.

I understand all what you say, but, how do you explain that my test detailed above results in 3 Go lost only to draw 4 book covers in the list mode ?
No book has been opened, only list of the entire library.

[PeterT]

Any chance you could share info on some of the books in question?

Sent from my Nexus 7 using Tapatalk

[rashkae]

With 680 books loaded on my H20, my .kobo-images folder is 527MB, so tracking about the same as Mingyar. It's worth noting that the Kobo generated a full screen size image for all the books, not just the ones I opened. Since the full screen resolution on the One will be significantly higher, I expect the full screen image sizes are probably at least 10 to 20% larger as well.

The large image that Kobo generated are all 1440 px tall, and range in size from 470KB to 1.1MB

Edit: On further investigation, I see the problem,,, the 'Full' Images kobo generated are all saved with jpeg compression at 100, (according to Gimp scale, when saving with original quality, it defaults to 100, and generates about the same file size.)

This behaviour is probably unique to sideloading Kepub. When Kobo sends the file, do they also send optimized cover images?

[davidfor]

Originally Posted by Mingyar

Thanks for your detail answer davidfor.
With Calibre, I only use the plugin to send epub as kepub (KoboTouchExtended 2.8.2).
The Load covers (Charger des couvertures in French) is not checked.

I understand all what you say, but, how do you explain that my test detailed above results in 3 Go lost only to draw 4 book covers in the list mode ?
No book has been opened, only list of the entire library.

It looks like I have to eat my words. I had a look earlier and it appears that the screensaver six image is being generated when the list size image is. I assume they are rendering the full image, saving and then sizing it for the list size. I am sure that this is a change, but it has been a while since I looked. But, I have no idea what firmware it was.

The annoying thing for me was that I was doing some playing with the cover images recently and kept opening the book to have the full size image generated. This convinced me of some changes I put into the last calibre release.

I'll have to do some experimenting, but I think I'll add something to the Kobo Utilities plugin to remove the full size cover. There is no need for it unless you are actually reading the book. I just have to check it gets recreated OK.

[rashkae]

Letting the Plugin generate and send the covers is a good solution. It uses a much more sane Jpeg compression level, (approx. 80)

Here is comparing the image files from a single book with different sending options:

Edit: There is a problem with this board and PNG images,, they were scaled to twice their size. You can get the screenshots here: https://transfer.sh/LXQbN/screenshots.7z

(I removed the images before the mods did.)

[davidfor]

Originally Posted by rashkae

With 680 books loaded on my H20, my .kobo-images folder is 527MB, so tracking about the same as Mingyar. It's worth noting that the Kobo generated a full screen size image for all the books, not just the ones I opened. Since the full screen resolution on the One will be significantly higher, I expect the full screen image sizes are probably at least 10 to 20% larger as well.

The large image that Kobo generated are all 1440 px tall, and range in size from 470KB to 1.1MB

Edit: On further investigation, I see the problem,,, the 'Full' Images kobo generated are all saved with jpeg compression at 100, (according to Gimp scale, when saving with original quality, it defaults to 100, and generates about the same file size.)

This behaviour is probably unique to sideloading Kepub. When Kobo sends the file, do they also send optimized cover images?

On the device, for epubs, the first page is rendered and saved. For kepubs, the image that is marked as a cover is extracted, sized appropriately and saved. Both of these are saved with colour and I have never looked at quality level for the images no matter how they were produced. When downloaded from Kobo, the covers are always grey scale ("always" here means "all the ones I looked at and can remember"). From a comment elsewhere, the conversion the server does probably isn't that good.

The calibre image generation is what was there when I took over maintaining the driver. Or I copied it from another driver and only change the size of the images. I've forgotten which now Graphics and image manipulation is not one of my areas of expertise. I know just enough to be dangerous.* If someone wants to suggest some better parameters for generating the covers, I'll look at them. Or maybe a space saving option vs a hires option. Adding options to the driver is a lot easier now, so

* If "a little knowledge is a dangerous thing", I am a very dangerous person.

[DNSB]

Originally Posted by Mingyar

I understand all what you say, but, how do you explain that my test detailed above results in 3 Go lost only to draw 4 book covers in the list mode ?
No book has been opened, only list of the entire library.

Hmmm... looking at my images, I normally send them from Calibre and I've been generating the cover image from a converted to 4 bit greyscale and dithered image so in most cases, a bit smaller image than the more or less standard 24 bit colour image. Sending from Calibre/Kobo Utilities does put all 3 images used by the Kobo firmware on the device much as scanning through the library listing does without the wait per page as you browse through the library for the images to be created. If you scrolled through the 667 pages of the library listing for 4000 ebooks, you are a much more patient person that I have ever been.

As a quick test, I switched back to the full colour cover images and uploaded them. After this, I show 2.84GB used in the eLibrary folder (where my sideloaded ebooks live) and 834MB used in the .kobo-images folder.

Hmmmm... I removed the images for a couple of ebooks and looked at them in search view. This only generated two image files (the FULL and LIBRARY_GRID). For one ebook, the FULL file was clocked in at 854KB (1404x1872) compared to 337KB (1248x1872) for the Calibre/Kobo Utilities generated FULL image. I'd suspect that this is the source of the massive space used by your cover images.

[Mingyar]

Originally Posted by PeterT

Any chance you could share info on some of the books in question?

Sent from my Nexus 7 using Tapatalk

Yes, any chance
I can send you one of the 4000 books loaded in the kobo.
But not sure the problem is on the books.

You want one ?

[Mingyar]

davidfor & DNSB, thank you very much for your explanations.

With my other Kobo readers, I've no problem, using 32 Gb SD card.
I found this images issue (not sure issue is the good word) with the Aura One, trying to send all my library (about 8000 books).

I understand that solutions are accessible to optimize space used by cover images.
I'll use these tips with my next reader.
Thanks again.

Someone answered my first message that he doesn't understand why people want to send thousands books in a reader. This subject is recurrent, is it necessary to explain again ?

[davidfor]

Originally Posted by Mingyar

Someone answered my first message that he doesn't understand why people want to send thousands books in a reader. This subject is recurrent, is it necessary to explain again ?

Personally, I don't think it needs an answer, but there are lots of people who don't understand. Or maybe I should say don't work in the same way. My 4000 is cumulative - I add books and never remove them. I used to do a cleanup whenever I needed to do a factory reset, but I haven't needed to do one of those for ages. Or at least not a forced one were I couldn't prepare for it.

Now, there is at least one person here who only keeps four or five books on their ereader. That I don't understand. I mean, why would you make you reading choices so limited?

[ratinox]

Originally Posted by davidfor

Now, there is at least one person here who only keeps four or five books on their ereader. That I don't understand. I mean, why would you make you reading choices so limited?

If a book in my library is not on my short term to-read list then I'm not going to read it in the foreseeable future. Not having it on my reader is therefore not a limitation.

[Mingyar]

Originally Posted by davidfor

(..)
I mean, why would you make you reading choices so limited?

That's the answer ;-) Having the choice ...

I played a bit with the KoboUtilities calibre's plugin since my last post here.
It seems to be usefull for many tasks. Thanks !