Hi, All (and, hello to my colleague, Lisa) -
As primarily a _user_ of manuscripts and MS images online, I first want to chime in with those arguing against plugins. Although zoomify, Virtual Vellum, and DjVu all get the job done, they're not particularly pleasant to work with. (A quick glance at the OpenSocial plugins that Troy linked to below suggests they're pretty slick, and Mac/iPad usability is particularly welcome, though zoom/pan functionality didn't actually work on my iPad.) Plugins are _always_ a hassle, and after a year or two has passed, often a nightmare (e.g. the Windows-only SID plugin used by the Auchinleck project).
The fundamental issue that David raises remains unanswered, largely because there are a series of overlapping use-cases that don't neatly resolve to decisions about file format/file size/appropriate magnification, let alone against the different resolutions and dpis of screens and printers. Both f. 30v and 284r are nominally readable, although the horizontal distance between the full-text transcription and the ms image make it rather a pain in the neck. (This is, I assume, why T-PEN and Quentin Miller's Diplomat software offer transcription space just below ms lines, rather than adjacent, but as David indicates this is for transcription _checking_, the gap is an inconvenience rather than a deal-breaker.) The higher-quality image of f. 30v is vastly easier to work with, particularly with the magnifier tool, where the low resolution of f. 284r becomes noticeable. Were I transcribing f. 30v, I think the overview/zoom view are pretty much spot on - it's difficult for me to imagine scenarios when transcribing or checking a transcription that would require different levels of zoom (other than switching from a desktop to a laptop/ipad. That said, I did open the underlying image in a separate window at what it's reporting as 1970x2666, since the magnifying tool precludes that). If I were teaching with this image, however, I would want a third or fourth level of zoom: complete page, maybe 1/4 of a page, and then the max-zoom of the current magnifier. If you're not anticipating people teaching with these images, these aren't intermediary image sizes you need to provide, nor do you need to resort to more capable plug-in zoom tools.
Again, as an end-user, lossless files are unwieldy - I have plenty of 50mb tiff files scanned from microfilm on my computer that are easier to avoid, whenever possible, even with a decently recent computer. If I'm transcribing them, I'll work from perfectly readable 72dpi versions of 3325x2409 Tiff images of bifolia, and only return to the originals in rare cases. I don't mind the minor compromises of a lossy codec for the speed and convenience of a 2-3MB file, as long as you 1) warn me that's what you're providing, 2) make those sizes and zoom options consistent across a single manuscript, and ideally all of a project's manuscripts, and 3) offer options for accessing larger images (or, explain that you can't for licensing, revenue, or other reasons, cf. Irish Script on Screen or Stanford/Parker on the Web.)
So, in short, from my perspective, f. 30v is about right - you're fudging things by condensing the image into the frame on the right, which depends on the user's browser window size, and may be less readable on a laptop than the desktop I'm currently working on. The javascript magnifier is nifty, though it's a bit annoying that it can't be turned off, rather than only tucked away in a corner. And none of this brings you any closer to best practices for the back end.
Kind regards, Matthew
Matthew Fisher Assistant Professor Department of English University of California, Los Angeles
On Jun 19, 2012, at 11:22 AM, McAulay, Elizabeth wrote:
Hi all,
I'll add my perspective from working in digital libraries and from working on the St Gall Monastery Virtual Library (http://www.stgallplan.org/). Pan and zoom is my preferrered viewing interface. We use zoomify in our application, but just because it's our best choice right now. The biggest drawback is the flashviewer. Rules out ipad and iphone users from even knowing the images exist. So we're interested in going with jpeg 2000 and we will through the islandora package soon. I'm curious to hear others findings about Jpeg2000.
Best,
Lisa McAulay Librarian for Digital Collection Development UCLA Digital Library Program http://digital.library.ucla.edu/
On Jun 19, 2012, at 5:11 AM, "Troy A. Griffitts" scribe@crosswire.org wrote:
I am excited to see discussion on this topic. We host an online repository of images, transcriptions, and collation tools for scholars doing text criticism on the New Testament. Often, holding institutions of the ~5600 manuscript copies will not give us permission to house digital images on our own site, but insist on us feeding the images to our users from their website. This makes providing a seamless experience for our users a challenging task.
Our system is composed of a suite of OpenSocial gadgets and one of those gadgets is an image viewer which provides drag to pan, wheel (or 2 fingers up/down on a mac) to zoom, brightness/contrast adjust, box annotations, and persistent URLs back to an adjusted view. It's all javascript and requires no server side or extra client side components beyond the web browser and can view remote URLs for pretty much any image with a link on the internet. It's all freely available for your use-- easy dropin if you're working inside an opensocial container, or we have a standalone version too which is a simple popup webpage.
You can try the gadget out here:
http://ntvmr.uni-muenster.de/manuscript-workspace?docid=10001 (click on a thumbnail and it will load the full image)
and the standalone version can be seen by clicking the permalink icon ("Embeddable External Viewer Link To This Image") to generate a return link to your view of the image. (The "Discuss" button doesn't really do anything if you're not logged in, so avoid that one unless you create an account)
We also have a firefox plugin which will construct the appropriate link for viewing an image in the image viewer. You simply install the plugin, browse to any internet page with an image in which you are interested in, and then on the plugin, press "Annotate". It's crude and assumes the largest image on the page is the one you'd are interested in, but mostly does what our users expect. It can read images from some sites which use custom viewers by piecing tiles together, but mostly the images must be simple jpg, png, gif images.
Hope this is helpful. Please feel free to contact me if you have questions,
Troy
Virtual Manuscript Room Institut für Neutestamentliche Textforschung
On 06/19/2012 11:53 AM, Tony Harris wrote: Hi David
This is a really good question. I came into academia with an established background as an digital imaging scientist and as far as I can see at the moment, there are no real standards for image digitation or reproduction in the academic world that can be used effectively by scholars. For example TEI says a lot about how you reference your images but (unsurprisingly) doesn't attempt to give any guidance on how you get them into an appropriate resolution or colour depth in the first place. JISC also give some guidance here but many of their project specifications often seem to favour 4800dpi in 24bit colour. Not very helpful if (for example) you are scanning First World War black and white photographs which have a relatively low lines per inch resolution (search for lpi to dpi calculators online) or if you are using a scanner which has a maximum optical resolution of (say) 2400dpi and everything else is interpolated resolution. These things will of course differ from project t o project
which is why it is so difficult to lay down accurate guidelines.
I ran a workshop at Kalamazoo which dealt with some of these issues ('Digital Imaging for Medievalists'). Interestingly enough I scanned and printed some conventional (pre-digital) black and white and colour photographs at various resolutions and colour depths and not one person out of the 30 people who came to the session correctly identified which ones were which out of each set. In my view, what we really need are some standards and accurate guidelines and I am researching this area at the moment. For example, not many people realise that some pre-digital transparencies are between 2,000 and 4,000 lines resolution (lpi) which puts many digital cameras in the shade.
Moving to your question, I think the important thing to understand is that screen resolutions are still extremely low when compared with (say) printer resolutions. For example a typical laptop screen at 1024x768 is between 75dpi and 100dpi depending on the physical screen size. Many modern mobile phone/smart phone dpi tends to be around 150dpi. Of course these are all generalisations and there are many web based calculators such as http://tiporama.com/tools/pixels_inches.html which can give you a better idea of resolution capability on a device by device basis. Compare that with an EPSON printer at 1440dpi horizontal resolution and you will understand and appreciate the comparison. So it is important to understand that the image you display at any one time on the screen can be relatively low (for performance reasons), but the underlying source image (the original scan) needs to be high and lossless to allow the best level of zoom as you move closer and closer into the page. As a pal
aeographer, I want to be able to see 'the big picture' (i.e. the whole page) at any one time but then I also want to be able to zoom into sections of the manuscript and then down to the individual characters (without pixellation) to determine if that character really is an "S" or an "A" (palaeographers will get the joke here). The problem with most lossy compressions is that the 'big picture' is great but, as you zoom in, you start to see significant degradation of the image (a by-product of the way the compression is done) which gets in the way of scholarly interpretation. For example take a high resolution TIFF image, compress it at various JPG levels and then print it full page on a high resolution printer. You will find that all the samples are virtually indistinguishable from each other until you bring out a magnifying glass and then all will become depressingly clear in terms of the drop in image quality/fidelity at the lowest file sizes.
As other contributors have indicated, there are various solutions (e.g. http://djvu.org/resources/whatisdjvu.php and Virtual Vellum) which can also help, but the resolution, compression and colour depth of the underlying image is still key. As James implies, it is also important to select a software solution that has longevity and is not going to disappear or change once your research project is completed. There are a number of Flash based viewers around but (as James also implies), Adobe's track record at maintaining backward compatibility (and even retaining technology) has not been that great in the past. Having said that, Adobe Flash has installations that run into at least the tens of millions so it is unlikely to disappear overnight but we all know Apple's stance on Adobe Flash!
So in closing, I think the most important thing to ensure, for any manuscript project at least, is that the underlying image is at the highest resolution possible (lossless) and the capabilities to zoom into 'snapshots' of that image are flexible in terms of the zoom factors allowed. However, the image 'snapshot' that gets displayed at any one time on the screen can be relatively low for optimal performance but it still needs to be an accurate subset of the original image and as a result downscaling resolution from a lossy compressed original is unlikely to work very well. As I recall, this downscaling is something that Virtual Vellum does well as does Photoshop of course but to identify one of the many tools and plug-in's which operate in a similar and appropriate way for your particular needs and custom website will of course need your further research.
Hope this helps
Best regards
Tony Harris Kellogg College, Oxford
-----Original Message----- From: dm-l-bounces@uleth.ca [mailto:dm-l-bounces@uleth.ca] On Behalf Of Birnbaum, David J Sent: 19 June 2012 01:42 To: dm-l@uleth.ca Subject: [dm-l] best practice: photographc facsimile?
Dear Digital Medievalist,
For a couple of new Internet editions of medieval manuscripts I've procured high-resolution tiff images, which I'm publishing with a "magnifying glass" overlay. This is in a "responsive" context, so the components of the page, including the images, resize to fit the window dimensions. There's a sample at:
http://suprasliensis.obdurodon.org/pages/supr001r.html
The current images were prepared quickly for a demo, and are not of consistent size or resolution. I would now like to go back to get this part of the site up to production quality, and I would be grateful for advice about how to manage the images, an area where I don't have much (= any) knowledge of best practice. I'd like small image files that load quickly, and I think I don't mind slightly lossy compression if that would reduce the file size substantially--but if that's a mistake, I'd be grateful for a warning. I think there are two questions:
1. What's an appropriate file format and resolution (size, dpi, color depth, etc.) for the base image, the one that is displayed in full to the right of the transcription, and that resizes as the user resizes the window? Currently the image files are in jpg format and vary in size from about 2M down to 250k. I can regenerate them all at a common size, resolution, color depth, etc. from the original tiffs, but I don't know whether there is any sense of best practice concerning what that size should be. If I go the lossy route, what's a reasonable value?
2. What's an appropriate degree of magnification for the magnifying-glass inset view? Currently the magnifying glass inset always shows the image at 200% of the actual file size (not the size of the page as displayed without magnification in the browser window!). You can see the difference by comparing, say, folio 30v (about 2MB) to 284r (about 270k), where the magnification is much greater in the former than the latter. I can set the level of magnification anywhere I'd like, but is there any agreement about best practice here?
By way of orientation in the question: the purpose of the full image is to allow the user to see the image conveniently alongside the transcription, verifying any moments where our editorial judgment might appear surprising or questionable. The point of the magnified inset is to let the user examine details that may not be visible at lesser magnification, such as erasures, corrections, etc. My casual impression is that 30v looks pretty good and loads reasonably quickly (although quicker would be better), but I don't place great confidence in my own casual impressions.
Thanks,
David djbpitt@pitt.edu
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gidI320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gidI320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gid=49320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l
Digital Medievalist -- http://www.digitalmedievalist.org/ Journal: http://www.digitalmedievalist.org/journal/ Journal Editors: editors _AT_ digitalmedievalist.org News: http://www.digitalmedievalist.org/news/ Wiki: http://www.digitalmedievalist.org/wiki/ Twitter: http://twitter.com/digitalmedieval Facebook: http://www.facebook.com/group.php?gidI320313760 Discussion list: dm-l@uleth.ca Change list options: http://listserv.uleth.ca/mailman/listinfo/dm-l