Calibre Companion prerelease 3.1.1c

[jackie_w]

Originally Posted by chaley

Could be, but we would be pushed very hard to add the custom columns.

You know what they say ... always leave 'em wanting more ...

Originally Posted by chaley

This sounds a bit like the UI we have in CC's format/folder setup dialog. It shows a list of valid book formats. The user can reorder the list using up/down arrows, can select which formats s/he wants to receive using a check box, and can change the folder where the format will be stored.

Of course I'd completely forgotten about that. I set up that page early on and haven't needed to change it since.

[PatNY]

I have noticed that on a few thumbnails in the book details page, the color is very splotchy. It is ONLY apparent with covers with big areas of a bright red color. I don't notice it on any other colors, or even on darker reds/maroons. Just bright red. See attached screenshot of one such book.

Does android not like the color red?

Seriously, is there any way to avoid this? If the tradeoff were a much larger database or a slower import, I fully understand the preference to keep things the way they are. But perhaps there can be some tweak that doesn't negatively impact some other area?

I have my thumbnails set to large in the book details page. The book cover image is 1406 x 2104 pixels and is 274 KB. I have book covers on my device that are larger than that but don't notice any peculiarities in the thumbnails like with the red ones. And viewed at 100% on my computer it looks fine. If you'd like, I can send you the actual cover image.

--Pat

[PatNY]

Originally Posted by jackie_w

Might it be an option, for starters, to consider only the calibre standard fields, as they wouldn't vary by library or by user?

High on my wishlist too!

--Pat

[jackie_w]

@Pat,

Re: red in covers. I've noticed that calibre itself also seems to have a problem with large areas of red when you drag/drop the cover to update the metadata. I've always assumed it was something to do with jpg compression but as I don't understand the nitty-gritty of image processing I've never pursued it. In calibre I can get round it by renaming the original (good-looking) image to cover.jpg and manually copying it to the calibre book folder but I've no idea how to get round it in CC.

[PatNY]

Jackie -- Yes, when the jpeg image ends up looking a lot worse, it is usually due to compression artifacts.

In the case of Calibre, I never had an issue with compression artifacts because I import book covers differently -- through the "Browse" button in the metadata editor window. Calibre won't resample your images if you do it that way -- so long as the image's resolution (pixel dimensions) doesn't exceed what is set in Calibre. You can tweak this threshold too. I have mine set to really really large so Calibre will never resize/resample my cover images.

In the case of CC, it think the compression is done to optimize import times and database size. Personally, I would be willing to sacrifice both as I have plenty of storage room and normally only import books a couple at a time. But I understand if Charles doesn't want to go in that direction. I was just wondering if maybe there was another way to get around it.

--Pat

[chaley]

Originally Posted by PatNY

I have noticed that on a few thumbnails in the book details page, the color is very splotchy. It is ONLY apparent with covers with big areas of a bright red color. I don't notice it on any other colors, or even on darker reds/maroons. Just bright red. See attached screenshot of one such book.

Does android not like the color red?

Seriously, is there any way to avoid this? If the tradeoff were a much larger database or a slower import, I fully understand the preference to keep things the way they are. But perhaps there can be some tweak that doesn't negatively impact some other area?

I have my thumbnails set to large in the book details page. The book cover image is 1406 x 2104 pixels and is 274 KB. I have book covers on my device that are larger than that but don't notice any peculiarities in the thumbnails like with the red ones. And viewed at 100% on my computer it looks fine. If you'd like, I can send you the actual cover image.

--Pat

Originally Posted by jackie_w

@Pat,

Re: red in covers. I've noticed that calibre itself also seems to have a problem with large areas of red when you drag/drop the cover to update the metadata. I've always assumed it was something to do with jpg compression but as I don't understand the nitty-gritty of image processing I've never pursued it. In calibre I can get round it by renaming the original (good-looking) image to cover.jpg and manually copying it to the calibre book folder but I've no idea how to get round it in CC.

CC does nothing special with covers. To be precise, when CC connects and asks for metadata:

0) You add a cover to calibre. I don't think that the cover is processed at all.
1) Calibre creates a cover "thumbnail", usually 320 pix by 320 pix, aspect ratio respected. Tool = imagemagick, format = jpg, compression quality = .7
2) Calibre sends that thumb to CC.
3) When needed, CC explodes the jpg into a bitmap with standard Android tools. Usually the image is sized down (made smaller), but it is possible that it might be sized up a bit.

My guess is that it is the step in calibre/imageMagick that doesn't like red, but I don't know that. If you send me the cover I will try to find out what tool is causing the problems.

[chaley]

Originally Posted by PatNY

In the case of CC, it think the compression is done to optimize import times and database size. Personally, I would be willing to sacrifice both as I have plenty of storage room and normally only import books a couple at a time. But I understand if Charles doesn't want to go in that direction. I was just wondering if maybe there was another way to get around it.

The space issue is secondary. The real issue is network time. The amount of data to transfer is proportional to Height x Width. In other words, if a 100x100 bit image takes time T, then a 200x200 will take 4T . When you have 1000 books, factors of 4 start to matter a lot, especially during the metadata update cycle.

[PatNY]

Charles, I just sent you the actual jpeg for the cover to your email address.

The thumbnails for this book look just fine in Calibre. In fact I've never once had an issue with how a book cover was rendered in the program.

Calibre does process (resample/resize) original cover images when they exceed a certain size. But that size is configurable with one of the tweaks. In my case the threshold is set so high in the tweak that my covers are never processed by Calibre. At any rate, even when Calibre does resample images, I noticed it doesn't use a high compression, so it produces little artifacts.

--Pat

[jackie_w]

@Charles,

Oops, not quick enough! I've emailed you 3 sample covers. Sorry for my low taste in literature

[PeterT]

I wonder if the tweak

ID: cover_trim_fuzz_value

The value used for the fuzz distance when trimming a cover.
Colors within this distance are considered equal.
The distance is in absolute intensity units.

might be relevant?

[chaley]

Originally Posted by PatNY

Charles, I just sent you the actual jpeg for the cover to your email address.

OK, I see what is happening. As I mentioned, calibre uses a .7 compression quality index when creating the thumbnails. For this cover, it produces a size of 7,000 bytes. If I change the quality to .9 then the size goes up to 12,000 and the compression artifacts are largely gone. See the attached cover.

I will add a tweak (or something) to calibre to let you set the compression quality. The question is should this be by-device or calibre wide?

[chaley]

Originally Posted by PeterT

I wonder if the tweak

ID: cover_trim_fuzz_value

The value used for the fuzz distance when trimming a cover.
Colors within this distance are considered equal.
The distance is in absolute intensity units.

might be relevant?

No, this controls how aggressive calibre cuts off borders when trimming the size of covers. It won't change how the thumbs are produced.

[theducks]

Originally Posted by chaley

I will add a tweak (or something) to calibre to let you set the compression quality. The question is should this be by-device or calibre wide?

Why do you have to ask the hard questions

Some folk are touchy on file sizes sent to devices. IMHO the tweak should be at the device driver) level.

BUT! Isn't the result contingent on the Calibre stored cover? Should there be a (device driver) limiter that prevents trying to squeeze more out of an already less?

[PatNY]

Originally Posted by chaley

OK, I see what is happening. As I mentioned, calibre uses a .7 compression quality index when creating the thumbnails. For this cover, it produces a size of 7,000 bytes. If I change the quality to .9 then the size goes up to 12,000 and the compression artifacts are largely gone. See the attached cover.

Oh, that looks great! Thanks for taking the time to troubleshoot.

I will add a tweak (or something) to calibre to let you set the compression quality. The question is should this be by-device or calibre wide?

I don't know enough about how Calibre operates to give an informed opinion. I guess either way is good for me, so long as severe compression artifacts can be avoided on the device.

What I don't understand is that you seem to be saying that Calibre makes a thumbnail of a particular cover just once -- and then uses that single thumbnail both for its own internal use (cover browser etc.) and for sending to devices when exporting books. If that's the case, how come this particular cover (Mudbound) looks perfect in my Calibre interface (I can detect no compression artifacts at all) but it looks so splotchy in the book details page of CC? It's like night and day?

--Pat

[chaley]

Originally Posted by theducks

Why do you have to ask the hard questions

Some folk are touchy on file sizes sent to devices. IMHO the tweak should be at the device driver) level.

BUT! Isn't the result contingent on the Calibre stored cover? Should there be a (device driver) limiter that prevents trying to squeeze more out of an already less?

Calibre doesn't upscale a cover. If the cover is smaller than the normal CC thumbnail size (320 x 320) it is sent as is. CC might upscale it, though.

And I agree with you -- I did it in the device driver.

Originally Posted by PatNY

What I don't understand is that you seem to be saying that Calibre makes a thumbnail of a particular cover just once -- and then uses that single thumbnail both for its own internal use (cover browser etc.) and for sending to devices when exporting books. If that's the case, how come this particular cover (Mudbound) looks perfect in my Calibre interface (I can detect no compression artifacts at all) but it looks so splotchy in the book details page of CC? It's like night and day?

No, I didn't say that. Calibre makes thumbnails all over the place and in varying sizes. Some examples are book details, cover grid, the cover in the book itself, thumbnails on the device, and cover view.

We are talking here about the thumbnail used on devices. These also can vary in size. Example, the "standard" for calibre is 68 x 68. Many devices use larger numbers. CC uses 320x320. We are also talking about the compression quality number. Calibre used 70 (.7) for device thumbs, which is quite highly compressed. It used higher numbers in other places, producing bigger thumb "files" (many are only in memory) with better quality.

My guess is that your huge covers are actually just slowing calibre down and buying you almost nothing. It will never be shown full size, so it is always being downscaled. The only advantage of keeping an original cover is to avoid multiple jpg compressions passes, because each one loses a little bit of quality.

Here are the sizes of the mudbound cover at various compression levels:
50: 9273, 70: 12558, 80: 15482, 85: 17802, 90: 28341, 95: 38352. We can see that switching from 70 to 90 makes the cover 2.4 times bigger. As such, roughly 18kb per book will transfer down to CC for each change, and up to calibre on each connect. This may be worth it for you, but it certainly won't be for many people. Fortunately people can set it how they want.