[OPEN-ILS-DEV] Uploading Cover Images?

Mon Dec 14 09:59:52 EST 2009

I chatted briefly in channel with dbs about how we do covers here but
figure I'll send it for prosperity too as it appears to overlap with
many sentiments. We're currently on sopac/locum and a bit away from
evergreen so apologies on any misconceptions of how EG works. We're
still trying things out and wrapping our head around it.

First some background. We originally were syndetics only and prior to
their move to a CDN were constantly having performance issues with
what were perceived slowness by patrons when syndetics was not
working. We switched reviews over to a cache and decided on an upgrade
that covers would need to be cached as well.

Like some in here have mentioned, another goal was custom covers as we
have things like art prints, tools, etc that don't have an isbn, upc
but should really have a picture of some sort. Because of the various
types we decided that the images would be named via the bib record
number. I think if Mike's change allowed use of the record
identifier/number instead of just ISBN it would make our code fairly
reusable and also make it easier to cache the more unique items. I
might be wrong here as we don't have standard numbers in a lot of our
records but maybe EG requires it? Using the bib as the key allows us
to do title searches on sources for items with incorrect or missing
standard numbers and still attempt to get a result.

Example unique items:

Energy meter: http://www.aadl.org/catalog/record/1187615
Art Print: http://www.aadl.org/catalog/record/1338831

## What we're doing

Example record: http://www.aadl.org/catalog/record/1350795
Cached 200: http://media.aadl.org/covers/1350795_200.jpg
Cached 250: http://media.aadl.org/covers/1350795_150.jpg
Cached 100: http://media.aadl.org/covers/1350795_100.jpg
Cached 50: http://media.aadl.org/covers/1350795_50.jpg

A record where no images are cached gets a random colored cover not
found: http://www.aadl.org/sites/default/modules/sopac/images/nocover1_200.jpg

We decided that we didn't want to generate the sizes on demand so we
cache the various sizes we use (widths are set in a config file since
it will vary across libraries). We also use these cached images for
things like video displays in the library.

1. Each night a script is ran that goes through and gathers all the
items that were added since the last run and looks for covers. It then
also goes through and checks again for any items that don't have
covers
2. If there is a standard number it will check the defined services
for the image. amazon, librarything, open library, syndetics, netflix,
etc. If no standard number it tries a full title search on services
that support it.
3. Currently it will check all of them and choose the service with the
largest image. This obviously means a lot of calls and for things like
LibraryThing you would probably want to only check it if the others
failed to have anything and possibly only for new items.
4. If it finds an image it generates the various sizes and saves them
to the file system. For locum we also write in the record that we
found an image as locum has a field for cover images (that takes a
url).

Since the script more or less just writes the file to the filesystem
I'm guessing it could be changed to write the files to the directories
that Mike's change looks for. You would probably only need to change
the parts that look for records that are missing covers. I'm not sure
what the easiest way to do that or if you would want to note in the
record somewhere whether a cover was found or not.

Code: http://dobby.darienlibrary.org/svn/locum/contrib/plugins/locum-covers/

We'll probably also put up a version at some point to http://github.com/aadl/

## Staff Interface

Going back to the art prints and tools, we also decided to add a staff
interface for removing cached images and providing a url to an image
to add one. The removal is used when open library (user generated
content yay!) or a title search turns up the wrong item or
inappropriate image. As an example:
http://www.aadl.org/catalog/record/1334071 ended up with
http://www.amazon.com/dp/B00153ZQTQ/ which has led us to be more exact
with title searches (original goal was to get as many covers as
possible).

Since we use drupal we just wrote a module that when someone logged in
with a staff role puts their mouse over a cover they get an edit
option which takes them to a form that lets them delete the cache, see
what syndetics/worldcat/amazon has for the identifier (one click
change), or put in a url to an image somewhere that will then be
processed and cached.

While I thought it was mostly useful for the art prints/tools we've
now had around 15,000 covers changed by staff, many in our foreign
language collection.

Code: http://dobby.darienlibrary.org/svn/sopac/contrib/covercache/

Again since the calls deal mostly with the file system if you use
drupal for your main site you could probably set up some sort of
redirect from EG to your site's editing interface and get the benefits
without too much EG dev time.

## Long story long

Long story long, we've found a local only store w/ caching process to
work out really well. Having it separate from everything and just a
nightly cron job has also worked out well. The staff interface was
also more of a boon than we expected so may be worth the development
time.

Ryan Eby
Ann Arbor District Library

>>> -----Original Message-----
>>> From: open-ils-dev-bounces at list.georgialibraries.org
>>> [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Mike
>>> Rylander
>>> Sent: December 8, 2009 15:40
>>> To: Evergreen Development Discussion List
>>> Subject: Re: [OPEN-ILS-DEV] Uploading Cover Images?
>>>
>>> On Tue, Dec 8, 2009 at 1:44 PM, Duimovich, George
>>> <George.Duimovich at nrcan-rncan.gc.ca> wrote:
>>> >
>>> > I'd very much like to see support for multi-providers too.
>>> >
>>> > But I still like the ability to point to local repository of cover
>>> > images, since we likely wouldn't have interest in having our staff catalogue
>>> > directly in OpenLibrary first. It would be easier to support local images,
>>> > and then post to public site (LT or OL, etc.) eventually.  We have a tonne
>>> > of government documents that nobody else has..
>>> >
>>> > Just today I was asked about another use scenario: we will be managing
>>> > some equipment in Evergreen (audio-visual stuff, etc.) and my colleague
>>> > wants to see the "cover image" of the A/V equipment in the bib record
>>> > details (picture of device). Since our "Panasonic P2 170 HPX camera" etc
>>> > won't be in OpenLibrary, it would be nice to have the pic show up in the
>>> > cover image content area. For this particular case, we'll just link to an
>>> > image via 856 field for now.
>>> >
>>>
>>> The changeset at http://svn.open-ils.org/trac/ILS/changeset/15105
>>> attempts to allow local content to be served in preference to any remote
>>> added content.  If, for example, you have a single apache server (no
>>> separate added-content server) and you place an image at:
>>>
>>> /openils/var/web/opac/extras/ac/jacket/small/0123456789
>>>
>>> (note the lack of a filename extension!) and gave your "Panasonic P2 170
>>> HPX camera" record that ISBN (0123456789), then you should see the image you
>>> put there as the "cover image" for the record.  After applying that
>>> changeset, and restarting apache, of course.  If anyone tests this, please
>>> let us know how it works for you!
>>>
>>> --miker
>>>
>>> > George Duimovich
>>> > NRCan Library / Bibliothèque de RNCan
>>> >
>>> >
>>> >
>>> >
>>> > -----Original Message-----
>>> > From: open-ils-dev-bounces at list.georgialibraries.org
>>> > [mailto:open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of
>>> > Dan Scott
>>> > Sent: December 7, 2009 12:31
>>> > To: Evergreen Development Discussion List
>>> > Subject: Re: [OPEN-ILS-DEV] Uploading Cover Images?
>>> >
>>> > Sure... but the advantage of the OpenLibrary route is that a) the
>>> > plugin already exists and b) you can get more from OpenLibrary than just
>>> > covers, for free - just tables of content today, mind you, but the same
>>> > principle could be used to pull the description, first sentence, etc from
>>> > the OpenLibrary metadata that's returned by the call.
>>> >
>>> > LibraryThing offers more than just covers to Evergreen systems via
>>> > LibraryThing for Libraries
>>> > (http://www.librarything.com/forlibraries/),
>>> > but that's a paid service.
>>> >
>>> > Getting back to added content, it's a bit of a painful limitation to be
>>> > limited to selecting only a single service provider. I dream of the ability
>>> > to stack added content services so that a library could tell their Evergreen
>>> > system to check OpenLibrary, LibraryThing, Google Books, Amazon, Syndetic,
>>> > SOPAC Insurge, publisher services, etc for cover images, reviews, etc, so
>>> > that sites could provide the best coverage, or pick and choose services.
>>> >
>>> > For example: we might be happy with the covers provided by OpenLibrary,
>>> > but be willing to pay Syndetic for their reviews. In the existing
>>> > architecture we would have to create a custom added content Perl module to
>>> > achieve that goal.
>>> >
>>> > There are other pieces of open source software that have already
>>> > covered some of this ground - Umlaut, for example - and it might be a good
>>> > thing to borrow or integrate that work, rather than continuing to roll our
>>> > own. But that level of refactoring would require significant work, too, so
>>> > until somebody has the time to invest, we can keep rolling with what we've
>>> > got. OpenLibrary is the only service provider that I'm aware of to which
>>> > libraries can contribute cover images and their own added content and that
>>> > content is then freely and immediately available to others to use, which is
>>> > why I lean in its direction.
>>> >
>>> > While I'm day-dreaming and totally on a tangent, I'd love to see
>>> > somebody take advantage of the very low-hanging fruit of augmenting their
>>> > catalogue records by turning the tables of contents / author notes / etc
>>> > available from OpenLibrary and often from loc.gov itself into proper MARC
>>> > fields to enhance keyword searching. Should be easy to do... maybe as a
>>> > hackfest project, if nobody gets around to it before then.
>>> >
>>> > Dan
>>> >
>>> > On Mon, 2009-12-07 at 10:48 -0600, Josh Stompro wrote:
>>> >> Another similar option would be to create or update entries in
>>> >> librarything, (http://www.librarything.com).  You could add the cover
>>> >> art and then use the librarything cover art service.
>>> >> http://www.librarything.com/blog/2008/08/million-free-covers-from-lib
>>> >> r
>>> >> arything.php
>>> >>
>>> >>
>>> >> It could be that there is some crossover between librarything and
>>> >> openlibrary, so by adding cover art to one it shows up in the other,
>>> >> but I'm just speculating... looks like maybe not.
>>> >> "*In the past, we had been talking to the Open Libary
>>> >> <http://openlibrary.org/> project about a joint effort. We even sent
>>> >> them all our covers and a key to the identifiers that linked them.
>>> >> But nothing came of it. To some extent that was our fault, and to
>>> >> some extent not. (I think them and us would differ on the blame
>>> >> here.) In any case, I was tired of the time and transactional
>>> >> friction, and wanted to try a different approach." (from page above)
>>> >>
>>> >> Josh
>>> >>
>>> >> Dan Scott wrote:
>>> >> > On Sun, 2009-12-06 at 08:44 -0500, Ryan wrote:
>>> >> >
>>> >> >> Hi all,
>>> >> >> It seems we have hit a bump in using Evergreen, we have a
>>> >> >> collection of cook books that need to be cataloged. These cook
>>> >> >> books are fundraiser cook books so they are not sold by Amazon or
>>> >> >> cataloged by the Library of Congress. We can catalog the books
>>> >> >> with out a problem but can we scan the cover images and upload
>>> >> >> them to our Evergreen server? Where would these files have to be
>>> >> >> placed if so?
>>> >> >>
>>> >> >>
>>> >> >
>>> >> > You could catalog them in OpenLibrary (http://openlibrary.org/),
>>> >> > upload the cover images there, and use the OpenLibrary added
>>> >> > content plugin instead of Amazon
>>> >> >
>>> >> > (http://svn.open-ils.org/trac/ILS/browser/trunk/Open-ILS/src/perlmods/OpenILS/WWW/AddedContent/OpenLibrary.pm)
>>> >> > - which didn't make it into 1.6.0.0, unfortunately, but should work as-is if
>>> >> > you pull it directly from trunk.
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Mike Rylander
>>>  | VP, Research and Design
>>>  | Equinox Software, Inc. / The Evergreen Experts  | phone:
>>>  1-877-OPEN-ILS (673-6457)  | email:  miker at esilibrary.com  | web:
>>>  http://www.esilibrary.com
>>
>>
>>
>> --
>> Ryan Laverdiere
>> Head Webmaster: http://www.my-ne.com
>> Blog: http://www.capecodtoday.com/blogs/index.php/Tracker
>
>
>
> --
> Ryan Laverdiere
> Head Webmaster: http://www.my-ne.com
> Blog: http://www.capecodtoday.com/blogs/index.php/Tracker
>