CC Prerelease V3.4.0e & V3.4.0f

[jackie_w]

@chaley,

I've sent the debug log from my Android alter-ego id. I also include here a link to 4 screenshots of Book Details of the same book. Actual calibre cover size 669x1024.

Galaxy Note3 (1080x1920) portrait - BD cover size Medium - actual size 31x47mm of total screen size 71x125mm
Galaxy Note3 (1080x1920) portrait - BD cover size Large - actual size 41x63mm of total screen size 71x125mm
Galaxy TabPRO 8.4 (1600x2560) portrait - cover size Large - actual size 29x45mm of total screen size 113x180mm
Galaxy TabPRO 8.4 (1600x2560) landscape - cover size Large - actual size 29x45mm of total screen size 180x113mm

I'm not sure of the right approach either merely food for thought. If it's a choice between a smaller sharper image or a bigger fuzzier image I think I'd choose the former, but as usual with these things, it's not until you've tried both that the personal 'winner' emerges.

So far I've been using CC in portrait on the tablet. Not necessarily because it's better but because it 'feels right' because I'm so used to CC on the phone.

[chaley]

Originally Posted by jackie_w

@chaley,

I've sent the debug log from my Android alter-ego id. I also include here a link to 4 screenshots of Book Details of the same book. Actual calibre cover size 669x1024.

Galaxy Note3 (1080x1920) portrait - BD cover size Medium - actual size 31x47mm of total screen size 71x125mm
Galaxy Note3 (1080x1920) portrait - BD cover size Large - actual size 41x63mm of total screen size 71x125mm
Galaxy TabPRO 8.4 (1600x2560) portrait - cover size Large - actual size 29x45mm of total screen size 113x180mm
Galaxy TabPRO 8.4 (1600x2560) landscape - cover size Large - actual size 29x45mm of total screen size 180x113mm

I'm not sure of the right approach either merely food for thought. If it's a choice between a smaller sharper image or a bigger fuzzier image I think I'd choose the former, but as usual with these things, it's not until you've tried both that the personal 'winner' emerges.

So far I've been using CC in portrait on the tablet. Not necessarily because it's better but because it 'feels right' because I'm so used to CC on the phone.

A "standard" android device has a DPI of 160. This is arbitrary, chosen by Google simply as a value to allow scaling. Such a device would have a "density" of 1. My N7 has a density of 1.331 meaning it has a DPI of 213 (its real value is 216). Your TabPRO (the 8.9 version?) is reporting has a density of 2, so its DPI should be 320. It is really 360, and I don't know why it is reporting a smaller density number.

A "large" CC cover is 320x320 preserving aspect ratio, so the height will win. On your device, a large cover will consume 640x?, or 4 real pixels per image pixel. On my N7 a large cover will be 426x?, which turns out to be 50mm hight. A cover on your TabPRO should be approximately the same physical height as a cover on my N7, and indeed they are.

All this is in preparation for an example. I added an "Extra large" cover spec with a size of 400 "standard" pixels, but used the 320x320 cover to generate it. That means that on my N7 the expansion is no longer 1.331 but is instead 1.665, resulting in a displayed cover size of 666x?.

Here are examples of two covers. The original covers in calibre were both larger than 320x320, so were downscaled. The screen captures are actual size showing medium, large, and extra large covers. My take: on my device the extra large cover isn't bad. It doesn't seem to have more artifacts than the large cover. Of course, a 400x400 downloaded cover would be sharper, but I am not convinced that the cost is worth it. YMMV.

[jackie_w]

Am I understanding this correctly? You are saying that the existing 320x320 extracted/reduced thumbnail would be re-inflated to 400x400, i.e. a 25% increase in both dimensions - therefore on a TabPRO a 29x45mm cover should display roughly as 36x56mm? The unknown quantity being how pixellated the average cover would appear. I'm guessing some will look better than others.

In an earlier version of CC, covers with large areas of solid red were a bit problematic (happily fixed). I've just looked at a couple of them on the TabPRO and they look OK at the existing Large size. Would these be the ones most likely to deteriorate if 'blown up' to 400x400?

If adding the pseudo-x-large is 'easy', maybe suck it and see? People will use it or not if the pixellation is excessive. The risk is that people may like the physical size but ask for a better resolution extract from the source, which is probably not what you want.

Hmmm?

[chaley]

Originally Posted by jackie_w

Am I understanding this correctly? You are saying that the existing 320x320 extracted/reduced thumbnail would be re-inflated to 400x400, i.e. a 25% increase in both dimensions - therefore on a TabPRO a 29x45mm cover should display roughly as 36x56mm? The unknown quantity being how pixellated the average cover would appear. I'm guessing some will look better than others.

Yes, that is what my experiment did.

In an earlier version of CC, covers with large areas of solid red were a bit problematic (happily fixed). I've just looked at a couple of them on the TabPRO and they look OK at the existing Large size. Would these be the ones most likely to deteriorate if 'blown up' to 400x400?

This is exactly the problem. Some people are extremely touchy about image quality. I worry that giving the option to show a reduced-quality bigger image will increase chatter. If that chatter is from people like you and PatNY then there is no problem. If the chatter appears as 1-star reviews then there is.

If adding the pseudo-x-large is 'easy', maybe suck it and see? People will use it or not if the pixellation is excessive. The risk is that people may like the physical size but ask for a better resolution extract from the source, which is probably not what you want.

Hmmm?

I am thinking that I need to simply suck it up and offer an option to control the size of the cover downloaded from calibre. That way a person can choose small covers displayed large (lower quality), large covers displayed small (very high quality), or large covers displayed large (normal quality). The issue for us is how to explain what the option means and what it does.

The next release will contain an attempt at the option. I hope that you in the prerelease community will help me with the option text. As I have said before, such text is something that I am really bad at. I tend to be wordy, and some people say I give too much of the wrong kind of info.

[chaley]

Here are images of the settings screens including the new downloaded cover size preference.

Any suggestions for improving the wording? Shorter is better, longer is not.

[jackie_w]

It reads OK to me, but brevity isn't my strong suit either. Do you think the word 'thumbnail' should appear in there somewhere? Lest anyone thinks CC is interfering with the actual cover on page 1 inside the book.

ETA: If known, how about adding the disk space currently used by covers on the last line to give people an idea of the overhead?
e.g. Current value = 320 pixels (nnnMB)

[kaufman]

It looks good to me with a couple of possible changes.

1) Is size in pixel the horizontal or vertical number? Or both? People are going to ask that question, so you might want to tell them up front.

2) If the current default is 320, maybe it makes more sense to have only one smaller and two larger. Devices are tending to get bigger and higher resolution, not smaller and lower. How about adding a 640 instead of the 160?

3) I had a thought about this today. Maybe this should be an option, or maybe it should just be the default. Why don't you just store the book database in the same folder as books? If someone puts their books on an SD card, then the extra space of the larger covers will not have much of an impact even if they have a large library. I checked, and my database is currently 120meg for 4500 books. If it increased to (for example) 360 meg with large covers, I wouldn't care as long as it was on the SD card. Is there any reason not to store the book database with the books? Or perhaps in a folder under the books?

[PatNY]

So glad to see we may be getting even more goodies in the next release!

I’m very satisfied with the quality of the covers in CC as is. However, the highest screen resolution I have on my current devices is 256 ppi, and I can easily see needing higher resolution covers when I eventually move to a 300+ ppi device. Even with my current devices, I will definitely opt for the higher res covers and larger thumbnails if those choices are available (so long as they don’t slow down the interface of the program). I don’t mind longer download times whatsoever. It’s a very small price to pay for better quality and/or larger covers.

As for the wording, I don’t know if the following is any improvement, but it is a tad shorter:

Cover Resolution

Choose the resolution of covers imported from Calibre. More pixels give better images but increase download times and storage requirements on the device. Changing the value causes all book metadata to download on the next wireless connect. (Default = 320 pixels)

To make it even shorter, "on the device" can be deleted from the second sentence.

--Pat

[chaley]

Originally Posted by jackie_w

ETA: If known, how about adding the disk space currently used by covers on the last line to give people an idea of the overhead?
e.g. Current value = 320 pixels (nnnMB)

We don't know. It depends on the cover, the compression, and the phase of the moon.

Originally Posted by kaufman

1) Is size in pixel the horizontal or vertical number? Or both? People are going to ask that question, so you might want to tell them up front.

Size of the largest dimension, almost certainly vertical.

2) If the current default is 320, maybe it makes more sense to have only one smaller and two larger. Devices are tending to get bigger and higher resolution, not smaller and lower. How about adding a 640 instead of the 160?

We have had requests from people who use phones to make the images smaller. Doing so will increase metadata sync speed, perhaps substantially, and also increase performance when using the content server. A phone user will gladly trade off speed for image size, assuming they are using small thumbnails.

3) I had a thought about this today. Maybe this should be an option, or maybe it should just be the default. Why don't you just store the book database in the same folder as books? If someone puts their books on an SD card, then the extra space of the larger covers will not have much of an impact even if they have a large library. I checked, and my database is currently 120meg for 4500 books. If it increased to (for example) 360 meg with large covers, I wouldn't care as long as it was on the SD card. Is there any reason not to store the book database with the books? Or perhaps in a folder under the books?

We have thought of this. Our concern is that people will hack on the db or even delete it, then complain that the program doesn't work. Keeping the db hidden ensures that we control it. Of course people with rooted phones can do what they want.

Originally Posted by PatNY

So glad to see we may be getting even more goodies in the next release!

I’m very satisfied with the quality of the covers in CC as is. However, the highest screen resolution I have on my current devices is 256 ppi, and I can easily see needing higher resolution covers when I eventually move to a 300+ ppi device. Even with my current devices, I will definitely opt for the higher res covers and larger thumbnails if those choices are available (so long as they don’t slow down the interface of the program). I don’t mind longer download times whatsoever. It’s a very small price to pay for better quality and/or larger covers.

You were one of those I had in mind when I was noodling about permitting larger covers. Some people like you care a lot, and some people like me don't care at all. I will probably cut the cover size down.

As for the wording, I don’t know if the following is any improvement, but it is a tad shorter:

I like that. Taking kaufman's comment into consideration, I will make it

Choose the maximum resolution of covers imported from Calibre. More pixels give better images but increase download times and storage requirements. Changing the value causes all book metadata to download on the next wireless connect.

I added "maximum" in hopes that it says that a dimension can be less than that. I removed the "default" because the user will see that number as the "current value".

Note that if the cover in calibre is smaller than the requested resolution, that cover will be transferred as is.