Forgot password? | Forgot username? | Register
  • Index
  • » Users
  • » lfg
  • » Profile




Assuming you have ImageMagick on your server, you could cron a nightly script to run convert's -density option on thumbnails. Here is a simplistic one you can modify, I cron it nightly to insure that unneeded profiles are chopped out of thumbnails generated that day (makes them truly tiny).


repository="/multimedia/images" # path to your EMu Multimedia Repository
rm="/usr/bin/rm" # path to your version of rm
cp="/usr/bin/cp" # path to your version of cp
awk="/usr/bin/awk" # path to your version of awk
echo="/usr/bin/echo" # path to your version of echo
find="/usr/bin/find" # path to your version of find
touch="/usr/bin/touch" # path to your version of touch
convert="/usr/local/bin/convert" # where convert lives



files=`$find $repository -name '*.thumb.jpg' -mtime -1 -print`
for source in $files
target=`$echo $source | $awk 'BEGIN {FS = "."} { print $1 }'`
$echo $target
$cp -p $target $tmpfile
$convert $tmpfile +profile iptc +profile exif +profile xmp $target
$touch -r $tmpfile $target
$rm -f $tmpfile

A comment from a general perspective.

Some KE clients will legitimately desire such scientific names to be represented as the name sensu stricto, and others will legitimately desire the author and/or date to be incorporated.

The default KE behavior might be to apply a consensus opinion that is established by polling clients, but the option to modify locally should be retained. In practice, this means retaining (and/or cleaning up by consensus) the extant code logic that builds ClaScientificName, AutAuthorString, and the associated etaxonomy columns.



In principle, it is straightforward to build your own web application using data from EMu, using whatever mechanism you might wish (e.g., JSP, etc.). The practice of how to do so is another issue - but proof of concept is available from several institutions who have done just that. I'll quickly summarize one way we have done so.

At the Peabody Museum, all our collections use EMu, and in large part whatever material they have online at any given time is pushed to the web and accessible through locally written scripts acting as the search routines. See for example:

These online data are updated daily, automatically, out of EMu as follows. A dump of each collection's catalogue data is made each night via texpress (the backend database) using the texexport command wrapped in a script. Dumps are also made of the support modules (Parties, Collecting Events, etc.) A second script on a backup server subsequently picks up all those dumps via ssh, merges the dumps together using various post processing rules that have been decided upon on a collection-by-collection basis, and prepares data for web consumption that have a simple flat file like structure (e.g., allowing for certain classes of multivalued EMu data to be dealt with somewhat more readily). The prepared data are subsequently picked up again via ssh by a third server (a campuswide production machine run centrally by Yale and dedicated to various online research projects), and this third server rotates in the newly prepared files for web consumption after archiving the prior two night's copies (a bit of version and backup control). Server side scripts on that campuswide production machine then act as the gateway to the data that you see from the web URLs.

Once the scripts and such are written and in place, it is then not difficult to modify things when curatorial staff come up with changes from time to time. The other good thing is that it's automated. The bad thing is that the data you see aren't truly real time as they are in the KE-provided PHP web applications... but hey, we normally run on "museum time" as I suspect your institution does as well, and so a web view of the way it was yesterday is quite current enough for this particular purpose for us. Your mileage may vary, but the general point is if you wish to build it yourself, there are some fairly easy to use tools available in the KE product to help you do what you might want (e.g., texexport on the backend, the standard reporting tools on the frontend, etc.). So go for it.




We're an EMu site here at the Peabody Museum of Natural History, but I use texpress/backend tools frequently for admin, maintenance, and development purposes. You're definitely not alone. An array of the Australian museums crank stuff through texpress, for example, nearby colleagues of mine at the New York Botanical Garden do so, etc. I just posted a reply in the Web Development forum that touches on texpress. I use the menu-driven applications less frequently (e.g., texadmin, texforms) and certainly in only a cursory manner compared to sites using texpress and not EMu per se. You're welcome to contact me offline via lawrence.gall at if you wish.




For one or a few fields the EMu Help is a great solution as Joanna says. But if you want all column names, then look for a file called that is located in the ~emu/utils directory (at least that is where it lives on our Unix server). You will need to edit it in a way that will make sense for you, but it seems to contain all columns for one's installation.

Larry at YPMNH

Chris, I'm not sure what version of EMu you have, but the LatLon tab used by a number of the North American natural history clients has the ability to do some autoconversion and also to record multiple georeferencing events that apply to the same Sites record. These tabs have relatively minor subclassing differences. There is also a SIG working on building some proposed standards for the LatLon (and subsequently Mapping) tab, and if you want to email me directly I'd be happy to chat more (lawrence.gall at That SIG will be bringing the proposal into EmuUsers.Org once it's more fully baked.

Hi folks,

At the recent Chicago meeting, I gave a brief overview of JPEG 2000
and why this imaging standard might prove beneficial, and described
how EMu could fairly easily be made "JPEG 2000 aware" using a short
Unix script and several freely distributed software programs.

I've posted the script here in JP2THUMB.DOC, along with some background
data and hopefully reasonably readable instructions in THUMBNAIL.PDF

Feel free to take a stab at implementation in your EMu environment,
we've found "JPEG 2000 aware" EMu to be helpful here at Peabody.
(You can try me directly if you wish, should you hit a wall, at



Attachment: jp2thumb.doc
Attachment: thumbnail.pdf

  • Index
  • » Users
  • » lfg
  • » Profile

Board Info

Board Stats
Total Topics:
Total Polls:
Total Posts:
User Info
Total Users:
Newest User:
Kate Bywater
Members Online:
Guests Online: