Roger Hyam

I have been doing some thinking about capturing images of herbarium specimens so as to facilitate the “taxonomic process” - whatever that might be. The trigger for writing this down was a quote from an excellent series of papers on digitisation of specimens:

“Plant sheets are usually scanned at somewhere around 1000 DPI (600 DPI being now generally considered the absolute minimum requirement), which renders images in the hundred-megabyte range.” Ariño and Galicia (2005) in Christoph L. Häuser, Axel Steiner, Joachim Holstein & Malcolm J. Scoble. (eds) (2005) Digital Imaging of Biological Type Specimens: A Manual of Best Practice. ENBI, Stuttgart

If you take a picture of a herbarium specimen with a modern (10 to 20 megapixel) digital SLR you will get an image that is around 300 dots per inch (dpi) measured on the specimen. This is relatively cheap and easy to do. To capture images above this resolution requires very expensive cameras or flat bed scanners suspended upside down on special rigs or something equally complex. More importantly capturing images above this stepping point in resolution slows down the capture process enormously - so that fewer specimens are imaged.  This simple requirement of 600+ dpi is actually a hurdle to the digitisation of herbaria so there must be a good reason for it. I am not so sure that there is and here I explain why.

What Botanists Actually Do

Take a look at a botanist working in a herbarium. Their work can be broken down into six phases. What resolution images would it take to carry out these stages in a virtual way with all the advantages of digital specimens?

1. Discovery Find that the specimens exist and where they are located. This is largely text based. It requires the filing name and geographic origin data to be captured in the herbarium catalogue. Text capture is a side effect of imaging the specimen with its own inherent problems but does not require images above 300dpi.
2. Retrieval Gain physical access to the specimens by removing folders from cabinets and placing them on a work bench or requesting a loan from a separate herbarium. This is easier with lower resolution images but can be achieved with any resolution image. Just about any resolution above 100dpi will require some form of zooming/thumb-nailing of images for manipulation in an interface so 300 dpi would be fine 600+ requires more resources but is equally OK.
3. Selection Each specimen is looked at it turn. This is typically little more than a glance at a distance of approximately twice normal reading distance (>700mm). The botanist is getting the gist of the specimen. Some specimens are selected to be examined. The selection criteria may be based on label information or whether the specimen appears to contain suitable material e.g. whether it is fruiting or flowering.
4. Examination If a specimen is selected in step three then it is examined in more detail. It may be picked up and held closer to the face at about a reading distance of 350mm. Measurements down to 0.5mm may be taken using a rule.
5. Detailed Examination The botanist may use a hand lens or long arm binocular microscope to examine parts of the specimen at 10x to 60x magnification. Depending on the taxonomic group this stage may come very quickly after stage 4.
6. Further Study The capsule may be opened and contents examined. Parts of the specimen may be removed, boiled, dissected and returned to the capsule. No resolution of image will permit this activity!

Of these six stages the resolution is only pertinent to phases 3, 4 and 5 - so what resolution is require for these stages?

Visual Acuity and DPI

Visual acuity is the ability to see clearly. (Here is the Wikipedia page to save you searching for it). Some one with good normal vision (20/20) can distinguish two lines when the angle of view subtended at the eye is 1 arc minute (1/60th of a degree or 0.016667 degrees). This is under ideal, high contrast conditions where the lines are vertical or horizontal. Under other conditions discrimination will be worse. The nearer they are to the subject (down to the minimum distance they can focus) the smaller the things they can see - somewhat obvious - but here we have a rule of thumb for what normal people can distinguish and we can use good old high school trigonometry to calculate what they should be able to see at different viewing distances.  How does this relate to dpi?

When a digital imaging device is capturing the real world you can think of it as sampling a surface at regular intervals - like placing a piece of graph paper over the subject and recording the colour under each square. A higher resolution is a finer gridded graph paper. You may be tempted to think we can estimate the size of grid squares on the basis of the angle subtended and we can but a fudge factor is needed. Because the camera is sampling reality there is built in error connected to the sampling rate. The grid may not line up with points that exist in reality so a tiny dark spot may be on the boundary between two grid squared and neither of them pick it up faithfully. I am going to call this the Nyquist fudge factor (NFF). It is correctly related to the Nyquist Rate but the math is beyond this blog. Basically to avoid the anti aliasing errors you have to more or less double the sampling frequency (NFF of x2).

Armed with these two pieces of information, the 1 arc minute angle subtended and the NFF of x2, we can work out what resolution images we need to meet the requirements of the botanist in phases 3, 4 and 5.

At normal reading distance (as used in phase 4) visual acuity is around 0.1mm which implies dots need to be twice as frequent (NFF) to capture this level of detail - each dot or grid square should be 0.05mm across. Converting this to inches we get 500 dpi. This figure should guarantee to capture two line 100microns apart. We can double these measurements at the 700mm viewing distance suggested for phase 3 equating to 250 dpi.

What about at phase 5, where the botanist takes out a hand lens or binocular microscope? The most common magnification for a hand lens is 10x. No lens is perfect but this would imply resolutions in the region of 5000dpi. To reproduce the effect of a good quality binocular microscope is going to require capturing specimens at around the 10,000 dpi mark which is technically totally impractical and even if it was may not be desirable.

There is a big jump here. 250dpi -> 500dpi -> 10,000 dpi. Conventional photographic capture techniques can only hope to simulate a limited range of what a botanist does with a specimen. They can’t get anywhere near simulating the use of optics so we shouldn’t bother trying to do that.

Sanity Check

If you are reading this at a PC or Mac you probably can’t see the dots that make up the screen image. If you measure from your eye ball to the screen you will find it is in the region of 700mm away.  In computer displays common dot pitches are 0.31mm to 0.25mm. My lovely iMac screen (no bias there) has a dot pitch of around 0.254. If I go down to my close focus distance of about 150mm I can just see the dots. The dot pitch of screens is a difficult measure because they have three sub-dots making up each colour dot. The dots may be arranged in different patterns but it is a worthy comparison for our purposes. Try this on your monitor with your own eyes. What dots can you see? The size of dots on your screen will be at least 250% bigger than the dots we are hypothesising capturing on specimens at 500dpi. i.e. imagine seeing something half to a third the size of the dot on your screen with your naked eye. Now imagine it is not brightly lit like a screen but part of a herbarium specimen.

You can cheat and use a hand lens to look at your screen if you like but remember you are then jumping to warp drive - and we are still only able to do impulse drive.

Looking at this sanely I can only conclude that 500dpi is the maximum needed to simulate phases 3 and 4 of a botanist’s work and that phase 5 simply can’t be done at the level of capturing the whole specimen. 300 dpi is probably plenty.

Conclusions

This is just my opinion expressed to stimulated thought rather than as the basis for some ultimate standard approach but I hope that it illustrates a danger. 600dpi was the old rule-of-thumb-resolution for producing images for printed materials. It maps well to the 300 lines per inch (lpi) used in standard quality half tone screens for printed works (think of the Nyquist fudge factor now applied to the conversion from dots in the computer back to lines on a page) but has been brought forward into the purely digital age where the images are unlikely to be printed. This single figure of 600dpi has affected the whole culture of digitising herbarium specimens in large herbaria.

I have only discussed a tiny aspect of the digitisation chain. I’ve not mentioned the importance of focus, camera shake, noise, colour or compression of files. The interesting stuff really starts with the electronic workflow that could be handling the images coming out of these workstations in an entirely automated way. But that is another story…

(Thanks to Bob Morris for some comments on this)

There is no doubt that Globally Unique Identifiers (GUIDs) are important and not just because I have been hammering on about them for the last few years. It is hard to imagine a world where biodiversity data can flow from one application to another without some kind of tagging of that data to show its provenance. The question we can’t get beyond is how to tag the data.

TDWG recommends the use of LSIDs -which are pretty restricted to the life science community (the clue is in the name). Publishers see books, journals and papers as “assets” and therefore legitimately use DOIs. Neither of these technologies play nicely with Semantic Web technologies al la W3C and so some people prefer PURLs or even Plain Old URL.

All these types of GUID are resolvable. Each can act as a form of address (by a variety of mechanisms). An implication of this is that each must be associated with some form of issuing/resolving authority. If you or your PC comes across one of these things it can look it up and get an authoritative answer as to what data it represents and who “owns” or curates that data.

Running some form of authority implies having access to some technical resources such as a web server and possibly DNS server. In the case of DOIs it implies paying some one else to run the infrastructure for you. This is not easy for many data suppliers.

UUIDs to the rescue! UUIDs are great. Just get the computer to make up a string of random digits that is complex enough to be guaranteed globally unique. Anyone should be able to tag anything with a GUID. This solves the multiple routes problem. If a consumer receives two pieces of data that bear the same UUID then they can assume that the two pieces of data are actually the same thing and one can be ignored.

But what happens if the two pieces of data tagged with the same UUID differ? Perhaps one has an extra field or two. How do we know which is correct? Perhaps one was originally created as the result of a search and the other was harvested as an RSS feed and the two mechanisms give different versions or views of the object identified by the UUID. Or perhaps one has been changed by some intermediary. How does the consumer of the information resolve the situation?

One way would be to approach an indexing service that has recorded the occurrence of all the UUIDs. Google’s pretty good at this kind of thing but it would not be possible to differentiate on Google between pages that mention the UUID and those that contain the authoritative data associated with the UUID. To do this we would need a real register that maps UUID to data source. At this point we are close to recreating the Handle system that drives DOIs and the advantages of UUIDs are slipping away. You can’t just use UUIDs you must use registered UUIDs!

It gets worse. Suppose I have created the preferred description of a taxon. I tag it with a UUID to uniquely identify it. Other people refer to it using the UUID. All is well in the world until an awkward person disagrees with me. Perhaps I haven’t added new data to my description or corrected errors. So the awkward person puts up their own description of the taxon and tags it with the same UUID - they redefine the meaning of that UUID by cutting and pasting it to a new authoritative description. They want to say “this is the correct description”. Nobody owns the UUID so there is no arbiter. If their is a register of UUIDs then they could perhaps sort it out but they couldn’t stop other people from setting up their own registers that favour different interpretations of particular UUIDs. This situation is very similar to the taxon name problem we have. No one owns a name so who has the definitive description of the taxon that name should be used for - nobody!

So UUIDs are dangerous. They appear to give a simple way to uniquely tag things but it is likely humans will mess this up. The fact that machines will not generate the same UUID twice is irrelivant if humans can cut and paste them with impunity.

What’s the Problem?

Imagine you are a biologist looking at a group of organisms. You may be interested in these organisms because they occupy similar ecological niches or the same geographical region or for any other number of reasons. In order to study these organisms you need to gather data from different sources. As you gather data you learn more and your requirements change. You may start by requiring taxonomic and distribution data but move on to needing molecular and descriptive information. At the same time you will produce data of your own that you want to share with your collegues and the wider community. Scientific etiquette dictates that you must credit your sources and you want to make it easy for people to validate your work by reproducing it - so fine grained provenance information is important.

To summarise, biologists are interested in combining heterogeneous data from distributed data sources, adding value to that data, and then publishing it back to the community. Neither the form nor the location of the data is known at the outset. The provenance of data must be maintained throughout.

How would you do this today? You may go to a data aggregators like GBIF, Orbis and Species2000 for your occurence and taxonomic data. If you want to store this on your laptop you would probably build your own database in Microsoft Access or Excel and cut and paste data into it. You might be technical enough to write your own import routines to consume data from Species2000/SPICE, DiGIR/DarwinCore and BioCASe/ABCD providers and map them into you own, internal data model. By the time you have incorporated molecular data from Genbank and phylogenetic trees in NEXUS format you will probably have spent far more time writing software than examining the original biological problem.

Why XML Schema is NOT the answer.

The use case requires that a biologist consume data and map it to an internal data model. What form should this internal model take? The biologist/programmer could adopt one of the existing XML Schema based standards, such as ABCD, and create a version of that in Access or even in a native XML database. They could then map data that they come across in other formats into this model - extending it for the data types that aren’t already covered. The result is that they have a unique data model (only they have come across their combination of different data types and adopted them in their particular way). The fact that all the data they have come across has been in XML Schema controlled documents has been of only minor use. It may have enabled them to automatically validate the data they recieve. It may even have helped them generate Java or C# code that represents the data in memory but it has not helped them store it or link it to the data they already have.

Combining data in multiple, unpredictable XML formats is not just “non-trivial” it is almost impossible. The only projects that are attempting to consume data from multiple XML based source in the biodiversity informatics community are portal projects with dedicated programmers. Nobody (to my knowledge) is attempting to write clientside code that does this.

From the data publishers point of view it is confusing as well. Each XML Schema is effectively a syntax definition for a new language that must be understood and mapped to their internal structures.

XML Schema is a syntax definition language. For two people to understand each other they must share both syntax and semantics.

What would an answer to the problem look like?

There are three things that would help a great deal:

• Globally Unique Identifiers (GUIDs) for the data objects so that when two pieces of data from different places are about the same object ( e.g. a ppecimen record) we can join them together automatically.
• GUIDs for the concepts of things so that when two pieces of data are of the same kind (e.g. the collection number field of the specimen record) we can treat them the same.
• A single transport model so that we can digest all this data with the same code.

How would we solve this in an ideal world?

What if all the data sources that a biologist wanted to use were endcoded in RDF with GUIDs for objects and concepts (ignoring the more naturally binary data like images for the moment)? We would still need to visit an aggregator or indexer to find where the data was but it would be easy to expand on the answers the aggregator gave us because the data would be tagged with GUIDs. We would be able to go back to the original source and get the full version of an object and we would be able to follow links between objects like following links on the web. If we used a triple store to hold the data on our laptop then we would know that any data we retrieved from any data supplier could be stored in it - because they would all follow the same model. As we added data to the store it would be linked together automatically because the concepts and the objects used would be linked by their GUIDs. We could query our combined data either by writing SPARQL queries or by using graphical tools that did it for us.

But Triple Stores don’t Scale - I don’t want to put all my data in a triple store!

Note that the vision above does not included the data suppliers having their data in triple stores. It only assumes that their responses are given in RDF. Neither does it assume that the suppliers are particularly RDF aware - they could simply serve XML data that happens to be compliant RDF - perhaps from a simple file on a webserver. The important thing is that the data that is shared is mapped into a “triple shaped world”.

What about the binary stuff?

This system does not handle binary data but it helps find and curate the binary data and feed it into the correct programs to handle it.

RDF - a Saviour?

The Biodiversity Informatics use case is not unique. The same use case applies to anyone doing research in a complex domain: historians, geologist, lawers etc. Imagine a travel agent researching a trip for a party of school children. They would need to go through more or less the same process of gathering heterogenious data from multiple sources, combining and analysing it. This is the challenge that faces the web as a whole and is being addressed by the Semantic Web project. It is not an easy problem to solve and is unlikely to solved within any one domain. Indeed, as the problem concerns integrating data across domains, it has to be solved by cross domain collaboration like the W3C effort.