Thread: Kobo Aura One screensaver cover low-res?
View Single Post
Old 09-04-2017, 01:27 AM   #7
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,905
Karma: 47303824
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by mgrimace View Post
Thanks jackie_w, I tried the grayscale but I think the issue is that the resolution is dropping whenever I use the 'upload covers' option in the driver, and then upscaling on the device for the screensaver resulting in blocky/jaggy gradients.
That shouldn't be happening. The driver has the sizes for each cover type and device and generates a cover image from the cover in the calibre library. Unless I messed this up in a change earlier this year to clean up the code a bit. I haven't tested this with my Aura ONE, so I'll have a look tonight.

Of course, it is possible that Kobo have improved the image handling here. They have made at least two change in the area this year, but I didn't think they would really affect the cover images.
Quote:
I say that because I also just tried the polish books plugin (update the cover in the book files - selected) and resent over the book (with the 'upload covers' option turned off in the driver) and now the screensaver cover looks fine.

Seems like its a problem whenever I select 'upload covers' in the driver, regardless of the other options.

Temp fix is manually using polish books manually before sending, and turning off the upload covers option. Any thoughts about the driver?
With the way this works, there shouldn't be a difference between polishing first and relying on calibre to update the cover during the send. They do function differently, but the effect should be the same. During the send, calibre looks for the cover image in the book and replaces it. If it can't find the cover, it will add the image and mark it in the OPF as the cover but it won't be displayed while reading the book. Some of this can be turned off. In older calibre, if calibre couldn't determine which image was the cover, nothing was done. This was changed as it caused problems on some devices, but an option was added to turn it off. With this, if calibre can't replace the cover, then it should mean that the device won't find it either and it will use the default cover (title plus format name)

The Polish does largely the same (looks for the cover and replaces it if it can find it), but makes sure the cover image is displayed as the first page of the book. If the current cover can't be found, it adds the cover and a new first page in the book. This cover could be resized based on the conversion settings you normally use. But, if you have the output profile set to Tablet, the cover should be left full size.

With all that, you should be getting exactly the same cover image in the book in either way. And the device should be using it and resizing it in the same way. And because of how the cover image is extracted from the kepub, sending the covers using the driver has never been as useful as for epubs and other formats.

I'll have a play and see if I can see anything. Finding a book suitable for testing could be the problem.
davidfor is offline   Reply With Quote