Cover changes | Report cover problems here #2

I just pushed some major changes to how LibraryThing handles book covers on work pages.

In brief they are:

1. Popular works no longer show the "Popular covers" at the initial load, but load themselves in after the page has loaded. (This effect is called "ajaxing.") Because covers always load after the page anyway, it doesn't really feel any different. But because loading and calculating data on covers is no longer "holding up" the rest of the page, it can load much faster. The average improvement is small, but for works with thousands of covers we see gains of 0.5–3.0 seconds. Books with lots and lots of covers (War and Peace!) got a LOT faster.

2. The look and feel of the page where you upload and choose covers has improved somewhat. It now shows two rows of each category—custom and Amazon—rather than the previous, fixed number, which looked ragged. The upload section is smaller and columnar, and other covers are listed under "Potential covers." Potential covers are shown larger. I restored sorting by larger images first, then by popularity within the larger/small groups. The Potential Covers area now "ajaxes" in, so popular books no longer have interminable waits to load the cover page.



3. For speed and simplicity reasons covers are more cached for a given work now. Basically, we've moved from recalculating all covers every time some years ago, to recalculating covers from cached information (yesterday) to using cached information. You can still use "Recalculate cover" to recalculate a work's default cover image. But it will not change the order of cover popularity, etc. Cover data is, however, recalculated every day. As there are two levels of caching, 48 hours is the outside limit.

Feel free to submit cover problems. I'm sure there are some out there. As we've learned from other threads, many cover problems are really about publishers reusing ISBNs, etc. But not all by any means.

I am the only one with the work at http://www.librarything.com/work/12449137/covers/84505271 however over on the right it displays two (identical) popular covers.

Checking another of my books, at http://www.librarything.com/work/3607634/work/83159830 I see four popular covers on the right. If I click on the "Combined page" on the left I now see five popular covers on the right. If I select "Change cover" I am shown 1 user uploaded cover, and three from Amazon. Over on the right under "Popular Covers" there are still five. I can't quite tell which one the duplicate is of.

>2 rodneyvc:

Fixed. Thanks.

Even as I was typing a more comprehensive description! Good work.

Yeah. Those covers were ALSO picked as the appropriate covers by ISBN. But, obviously, they're the same cover in the end.

Yeah. Those covers were ALSO picked as the appropriate covers by ISBN. But, obviously, they're the same cover in the end.

That Basic Flavoring series needs to be series-ed. Anyone want to help out?

A problem for you tomorrow, sleepy Tim:
http://www.librarything.com/work/2129347/covers/81547616

Why does it show one member cover. Probably a 1x1.

Are there more than Clare Gordon-Smith's books? I added Vinegar (which has the same Flavoring With header above the main title as the other Basic Flavoring books), but you'd done the others.

When member uploaded images shows a number greater than 0, it doesn't seem to show the image until I upload one there.

Minor issue, but see: http://www.librarything.com/topic/137802

Not sure if this is related, but on the work pages I now see the "standard" black cover for books for which I've either picked a blank cover or have no cover, instead of MY default cover. My default cover appears in my catalog, but not on the work pages even after I went back and reselected my default cover. Not overwhelmingly important, but mildly annoying.

All of this cover-talk has made me think of how I'm uploading my cover images. Back when I started doing scans of all my new books, I somewhat randomly picked 300x450px as the general image size for my LT uploads. Now, my actual scans run closer to 900x1350px, and I'm wondering if the full-size scans would be a "better" size (obviously, there is part of me that worries that my uploaded covers won't get the "high quality" label!).

Of course, the reason that I opted for a smaller image size is that there is a very substantial difference in the file size, generally speaking 300k vs. 3mb ... and being a geezer who still has lingering floppy-drive storage models (360kb!) lurking in his head, I'm always concerned about "taking up too much space" on a server.

Frankly, since the images displayed on LT rarely exceed (from what I've seen) 148x218px, I doubt that there would be any use for a 3mb scanned image ... but I was wondering if there might be a reason to "go big" with the images. Are there any specific guidelines (that I'd, evidently, missed) for size of uploaded cover images?

 

Picture quality isn't just about pixels / inch - it's also very much about how many bits you're prepared to invest in accuracy of colour.

(Not sure if LT picks up on this though).

When member uploaded images shows a number greater than 0, it doesn't seem to show the image until I upload one there.

Fixed.

I like the changes, especially the larger covers.

There are so many ponies the cover page always makes me wish for. A way to see the FULL sized cover that doesn't involve going to the catalog, finding the book and click click clicking the size+ button. A float over box that tells you the resolution of the cover. A marker for which cover in the list you are already using. Counts for how many members are using each cover. The list goes ever on.

Not sure if this is related, but on the work pages I now see the "standard" black cover for books for which I've either picked a blank cover or have no cover, instead of MY default cover. My default cover appears in my catalog, but not on the work pages even after I went back and reselected my default cover. Not overwhelmingly important, but mildly annoying.

Fixed. I changed it so that it uses the default cover of the user who added the book or, if there is no book, your default cover.

>15 brightcopy:

All coming. One question I have: Should I add a "info" icon that floats over the cover when you are over it, taking you to the info lightbox, or should the click now take you to the lightbox directly--where you can choose the cover as your own?

Thanks. I actually meant my book page, now the combined page, so I'm glad you understood what I meant, not what I said!

#17 by @timspalding> A bit of a conundrum. Your lightboxes don't work well on mobile devices. But hovering doesn't work at all on mobile devices.

So, lightbox, I guess. :D

Thanks for the detailed explanation . . .

Visually (and because I avoid Amazon covers whenever possible) I wish there was a thin horizontal bar (or something ) separating the "Potential covers" from the "Amazon covers" . . .

BTW, the book I checked just to look at the new interface didn't say "Member-uploaded covers" anymore . . . which is different from your screen shot above . . . late change?? If so, it is no longer obvious that "Potential" means "Member uploaded" . . . does that mean that "Potential" actually includes covers from some other source that I might want to know about in case I want to avoid it as much as Amazon? (Basically, I don't want my catalog and images to link directly to any commercial site.)

Will be adding more covers tonight and will report any more observations after I actually use it for a while.

Gotta run . . .

Whoops! now I see . . . "Potential" = "Member uploaded" + "Amazon" . . . my bad . . . still could use that separation . . . more later.

12> When I started adding covers, my upload would time out on any image larger than about 350k - so I was putting up full-quality jpgs at 500px high. Something changed - I got a faster internet connection and LT made quite a few cover changes - and now I don't time out, but I don't want to upload my 3mb scan, either (yes, scars of floppies!). So I upload 1000px high images, usually (scan at full size and 300dpi, pretty it up (remove blemishes, increase contrast, etc) and resize to 1000). Looking at what others have uploaded - I actually don't like a good many of those with enormous pixel sizes, at ~2000px high I see a lot of moire. I like my 1000s.

20> I agree, I'd like something - a thin horizontal rule? - between Member-uploaded and Amazon. It doesn't need a full header, but some sort of divider besides the words would be visually helpful to me.

I religiously resize my cover scans to a little over 600 pixels tall -- close enough to claim at least partial adherence to the Gospel According to Tim, Anno Rei 2.5 (see message 6), yet just enough in excess of that number to maintain a modicum of respectful irreverence.

I scan LT covers at 100 pixels/inch and crop to the size of the cover. This seems to reliably keep the files below the 2MB limit that used to be listed on the change covers/upload page. (Perhaps that has changed?) And until recently, I had an old computer and hard drive space was at a premium, so I couldn't spare more room for larger files. Very rarely, there's a cover that seems to need a higher resolution to be "readable", but even then I only go to 150 pixels/inch. PPI is the easiest thing to set as constant on my scanner, so that's how I've got the "LT covers" scanner profile set.

I only rarely try to fix scratches or flaws in the cover. Sorry, I just don't have the time and energy for all that.

Back to the original thread: I added a pile of books and new covers this evening. Unfortunately, I was streaming baseball games while I was working, so I didn't notice anything being faster . . . actually seemed slower waiting for the potential covers to load . . . but that was likely due to using bandwidth for the games . . . (more heartbreak from my Twins and Cubs interrupted for a few innings by the excitement of Johan Santana's no hitter for the Mets . . .) No big complaints or comments, but will try to give it a fairer test in the next couple of days . . .

Tangential, but do I understand correctly that if I have a best guess member uploaded cover, and Amazon assigns a cover to that ISBN, the cover on my book automatically switches to the Amazon cover?

Re.#23: "Gospel According to Tim, Anno Rei 2.5"

Ah, I must have missed that ... it makes me feel bad that I've been being "too chintzy" with the pixels at ≅300x450px! I'll make a mental note to bump my LT images up to ≅400x600px from now on (as I noted, my initial sizing choice was somewhat randomly arrived at when I started scanning in my covers).

 

25> Yes, looks like.

It shows you a cover in the following cascade:

A. The member cover you uploaded yourself or chose yourself
B. The Amazon cover for your ISBN, if there is one.
C. The LibraryThing best-guess for your ISBN, if there is one.

Quoting Tim from http://www.librarything.com/topic/137521#3415198

Which is why it's a good idea to go through the best guess list and confirm or correct it (confirm=choose the same cover - puts it into Chosen by You (which doesn't change); correct=choose a different cover (which also puts it into Chosen by You)).

27> Thanks. I had previously assumed that as long as I had a member-uploaded cover I was "safe", but I noticed in conjunction with the covers shakeup that a number of my books now had Amazon covers, despite my efforts over the winter to get rid of all such. This explains it, but unhappily means I'll have more work to do.

>26 BTRIPP: what am I missing about why anyone would used fixed dimensions for images? . . . my books are all different sizes and dimensions . . . they aren't like photos. Personally, I hate it when the images have extra space around the cover . . . or parts of the cover cut off . . . why force them to be a specific size?

No matter really. When I don't like a Member cover, I just scan my own . . .
I'm just wondering why people are so set on a specific number? . . . that quotation from Tim was about maximums, not a rule (at least by my reading).

I hesitate to say it, but the maximum is now 8MB. But that's just there to not annoy anyone who doesn't understand picture sizes. On balance, I'd rather deal with some monster images than annoyed users. But, if you can, you shouldn't go that big. Besides, there's just no point in uploading an image that large. We'd never show that much detail.

As for pixel size, I doubt we'd ever size it larger than the screen, with lots of space around it. That means we'd never go more than, say, 700 wide. We're not doing anything close to that now.

Re.#29 ... the reason I was using the "approximately equal to" symbol was to indicate that was the general pixel size for what would typically run for a scan of a 6x9" cover ... it's not a frame or anything, just a "ballpark" ... in this case I was talking about moving to doing "around" 400x600 instead of 300x450 pixel size images. Typically, I'll aim for constant image heights and let the width be whatever it is in relation to the height.

The reason for "standard" dimensions is that I use different graphics for different purposes, while the initial scan might be 940x1424px I'll reduce that to a more manageable file size for upload to LibraryThing (previously ≅ 300x450px, now moving to ≅ 400x600px), and for illustrations in my review blog, I'll further reduce that to ≅ 100x150px - although sometimes with link coding to the full-size scan graphic. Having consistent "general sizes" makes it a lot easier keeping a file of hundreds of scans.

 

31> Typically, I'll aim for constant image heights and let the width be whatever it is in relation to the height.

Exactly. I do the same. No blank space. No chopping.

The specific height that I use (a little over 600 pixels) is based not on the size of the book itself (which would be meaningless, since LT resizes images to fit available space), but rather on the maximum size that the image is likely to ever be displayed (based on Tim's comments).

Sounds like we're accomplishing similar things by totally different means . . .
Checking my most recent scans, which were made at 100 ppi paying no attention to final pixel dimensions at all, each ended up around 300-400 KB and 600-800 wide by 900-1000 tall (based on book size). This is what I upload to LT, but they never appear in those sizes (that I'm aware of), only much smaller. If LT is going to reduce them to fit the various sizes it needs, is there any reason for me to spend time shrinking them on my end given that the file sizes are already far below the limit?

Still feel like I'm missing something here, but it might just be my "old-school" methods (just use different ppi for screen and print and let that determine everything else).

Is there somewhere in the Wiki that explains the different sizes of images that appear in different places in the LT catalog? (e.g., in Wordpress, every time I upload a photo, three different sizes are created. The interface tells me those dimensions in pixels. I also can see all of them on the server.) On LT, up until now, I just tried to be below the maximum size listed and as long as my images weren't distorted when I view my catalog I figured everything was fine . . . but perhaps I need more instruction on how/where the images I upload are being manipulated.

Bumping over from thread #1: Recalculate Cover isn't choosing one of the available covers for www.librarything.com/work/11001296 -- there is now one cover available, but the work cover stubbornly remains blank/default/generic. (The other cases I mentioned later in the thread are now working.)

Before reposting I tried recalculate cover a few times, with no improvement. After posting the message I clicked the work link one last time and it had the right cover. So, never mind.

33> Still feel like I'm missing something here

Not really. It's just that thinking of photo quality in terms of ppi (or dpi) is useful when talking about scanning and printing (where you can squeeze more information into the same space), but not so much when talking about images displayed in a web browser (where the displayed ppi is constant -- based on your selected screen resolution). That's why the terms of the conversation tend to change to dimensions (height and width) when talking about images intended to be displayed on a computer screen.

When you scan a very large book and a very small book using the same dpi (like nearly all of us do), you get two image files with very different dimensions. Because LibraryThing dynamically resizes all books to fit the same area (e.g., slots in your catalog), the difference in size of the two image files is pretty much ignored. This is intentional. It's what allows images of two books made at different resolutions (say, two images from amazon) to be displayed side by side and not look like Gulliver next to a Lilliputian.

So what's important is that you upload image files that contain enough data (pixels) to support the largest display sizes. Otherwise, you get blurry images when the images are rendered at larger sizes (since the resizing algorithms will have to create pixels to fill in the gaps). Since, for most monitors, the height is the smaller dimension, many of us find it convenient to think of maximum image sizes in terms of the number of pixels that can be displayed vertically at screen resolutions that we find comfortable to work with (for me, this corresponds fairly closely to Tim's 600 pixel injunction). So, to not waste server space, we resize our images to that maximum height. Our images will look just fine if LT ever displays them full-screen (hint, hint). Of course, if Tim were to ever change his mind and decide to support zooming, then we'd all be screwed -- but I don't see that happening; the data's just not there.

Incidentally, the reason that the LT Wiki doesn't list all image sizes displayed sitewide is that the sizes aren't fixed. Yes, there are some fixed sizes (based on different image widths) in the catalog and on various pages -- but LibraryThing also provides you with the ability to display cover images (at a size specified by you!!!) on your profile page, in your talk messages, on external web pages or blogs, etc. This is done using the coverthing_dynamic feature -- a URL that gives you the cover image for a specified book in LT, resized based on a width supplied by you.

At any rate, I hope none of this seems like I'm talking down to you -- because from an image quality standpoint, what you are doing is just fine. I'm just trying to explain why many of us use fixed image heights for our uploaded images...Hope this helps.

Thanks, SIAW - finally what Tim and others have been saying all along about DPI not mattering for LT covers makes sense to me! I'll think about if I want to alter what I'm doing for size and DPI, but at least now I'm doing it with understanding.

Now the covers I have uploaded since the change are NOT showing as high quality.
I know they are!

It used to take only a day or so for my covers to be marked as high quality - is this no longer happening... or what?

http://www.librarything.nl/work/9676725/covers/86385937 shows 1 cover that is not for this particular work (the astrid lindgren one)

>33 LucindaLibri: THANK YOU! Definitely makes more sense now . . .
BTW, I go back to when webpages were designed with fixed pixel widths and most screens were 600x800 (so ppi mattered there as well) . . . but I get that much is different now . . . and for the better.

Relieved that what I'm uploading is probably okay, even if eventually bigger images are presented . . . (my scanner takes MUCH longer to scan any higher resolution than what I'm using, so I doubt I'll go higher). Also, I AM assuming that my original image at its original uploaded size exists somewhere on the system, even if right now I never see it . . . is that true? (I don't think I've never seen anything larger than 250 in one of the dimensions . . . though I haven't tried that coverthing feature you mention).

Anyway, the reason I came back to this thread was to report that, to me, the new cover system seems MUCH slower. The only thing that seems faster to load is if there are more covers to look at than those initially shown. Now they come up faster if I ask. But the initial waiting to see what images are available seems much slower to me . . . I get to look at a spinning wheel for almost every change cover page I go to, even if there are no covers available. And when I upload an image I see two different messages while I wait . . . one about sending a request to LT and then another about waiting for LT.

I have DSL, not the fastest, but not the slowest either. I've now tried this when I'm not using bandwidth on other things (originally I was working on LT and streaming baseball at the same time). The original message above mentioned something about speed . . . I'm just reporting that I'm not experiencing any improvement . . . just FYI, not really a complaint.

39> even if right now I never see it . . . is that true?

Actually, LT recently introduced the ability to view covers at larger sizes on the Change Cover (Cover Images) page and also on the various Work pages -- see this thread for details. This maxes out at 635 pixels high, so you're not actually seeing your original images, but rather a screen-filling version of your uploaded images -- still, as far as I'm concerned, this fits the bill wonderfully.

As for the new cover page seeming much slower to load -- that may be somewhat of an illusion. Previously, the page would not display at all until the covers were loaded--so there was a wait (which felt like an internet-related delay, rather than a cover-loading delay) and then the page would display all at once. Now, the page comes up immediately and then gradually fills in the images. The overall time feels (to me) to be about the same -- the difference is that with the new approach, you can do stuff (like load your own image or navigate to another page) before the covers finish loading. I may be wrong, but I think that it just feels longer because the page is already showing...

I'm aware of this perceptual difference, but it's not what I'm experiencing . . . I actually look at the clock and count seconds now . . . and there shouldn't be a such delay when there are no images to load . . .

Hmm...

I also mentioned slowness in another thread, and it isn't as fast as it was originally, to me either.

Tim - I wonder if your cover changes might possibly have caused this bug:

http://www.librarything.com/topic/138374

I can no longer change my covers using FireFox and have to switch to Chrome each time. I turned off Adblock Plus for LT and it made
no difference.

ETA: The popup doesn't appear in FF when I scroll over my choices. (It's FF 13.0, btw.)

That's odd. I use FF13.0 as well and experience no such problems.

It's got to be some add-on I'm using. I'll have to diddle with them a bit.

Got it! It was the AVG SiteSafety 11.1.0.4 plugin.

Good for you. Well, not that you have to deactivate a plugin of course...

It wasn't something I sought out. Last time I updated AVG it was 'suggested' that I add it. I'm just glad it wasn't AdBlock! :oD

Yeah, AVG and ZoneAlarm insist on installing their totally useless (to me, at least) toolbars/plugins/addons - grrr! And they're a pain to get rid of, too (they deactivate OK, but then hang around like grey ghosts...). Of course, McAfee and Norton do at least as badly...bah.

I was losing things (not here, another site) because of Adblock, but it was a bad filter rather than the addon itself (whew!).

Out of curiosity, when you start Firefox in safe mode does it disable these parasites as well? Just asking because that's often something people suggest to debug if an addon is causing a problem. Just want to be aware.

#52 - Yeah, it does. I had started it in safe mode to see if one of the addons was the problem. Just had to restart it, and disable my plugins one by one. Luckily for me they're in alphabetical order! ;o)

Is it just me or does the whole site (and functions) seem slower and more error prone lately. I have had two "rooms of trained monkeys" error flags just today!
Perhaps our all switching to High Quality covers is swamping those nice new servers?

I've had a few errors when doing something as simple as trying to look at series pages, but it varies whether it works or not.

Not sure if this is related to cover changes and belongs here, or is a bug, or a suggestion, but the system selected work image for Socialite Evenings is pretty bad. It's choosing a poor quality Amazon cover, when there's an excellent member uploaded cover available.

#56 by @r.orrison> Isn't this (unfortunately) always how the covers work? The only cover that's auto-selected for your work upon adding it is an amazon cover. Member-uploaded covers only get chosen if you specifically go in and change your cover. The most popular cover is chosen for the work cover. So the horrible side effect is that amazon is almost always the most popular cover on books with an amazon cover. If you look at all the people with this work, the most popular cover is that crappy amazon one.

I'd love that to change, but I think that's how it's always (well, for some value of "always", I'm sure) been.

I think it's worst than that. Recently Tim mentioned that the algorithm is to first choose the Amazon cover that goes with the ISBN. Only if there is no Amazon cover, or no ISBN, does the system go to the most popular user-uploaded cover.

#58 by @jjwilson61> Thanks. I vaguely remembered something ISBN-related, but I couldn't quite remember what was involved.

It'd be really interesting if Tim ever posted a breakdown of amazon vs MU covers used as work covers. I have the sneaking suspicion it'd be practically all amazon.

The amazon cover shown here does not belong.
http://www.librarything.com/work/4346454/covers/87184215

>60 bookel:
I've submitted a wrong image report on the Amazon product page. Let's see if they fix it.

Otherwise it might be an abuse of ISBN by the publisher.