MRTG Image Origin Size
→ Information about submission as TDWG standard
→ MRTG Wiki Homepage
→ Current Schema Draft. This version is under internal review as part of the submission to TDWG.
→ Audubon Core Non normative document
→ MRTG Development History
→ MRTG Meeting Notes
→ MRTG Best Practices
→ XML Schema representation of Audubon Core
→ RDF representation of Audubon Core
→ MediaWiki Help
This schema is missing an important element which (as far as I know) isn't present in other schemas. For lack of a better name, I call it "PixelDimension" and it represents the length (or height) of an image pixel in mm. I was part of a rather lengthy discussion involving a number of live plant photographers in which the issue of placing scales on images was discussed. Most felt that it was important to establish the scale of the primary object in the image so that measurements of features could be taken from the image if desired. However, some photographers felt very strongly that it was a bad idea to place a scale on the image itself, since that would render the image unsuitable for many purposes. The consensus solution to this problem was to include the PixelDimension in the metadata for the image. If the PixelDimension were known, a calculated scale could be superimposed on the image by software without actually modifying the image itself. More sophisticated software could allow a user to click and drag across the image to make measurements. Any unit could be used, but mm was suggested as the standard since PixelDimension can be calculated from the focal length of the lens (normally expressed in mm) and the distance of the object from the lens. PixelDimension also has the desirable property that it is not affected by the magnification at which the image is displayed and it is not ambiguous like "magnifications" such as "1000x". Although PixelDimension is not currently recorded for most images, when herbarium specimens are imaged, they routinely include a distance scale and it is likely that at some point in the future, PixelDimension will be calculated for many specimen images based on the scale on the image. So an element should be included in the schema that can handle this information. --Steve Baskauf 06:58, 28 April 2009 (CEST)06:58, 28 April 2009 (CEST)
It is part of ANSI/NISO Z39.87-2006 and so easy for us to add if important, which I think it is. --BobMorris 18:08, 30 April 2009 (CEST)
- OK, after some digging, I found them: Z39.87-2006,p.71-75, specifically: 9.1.2.1 xSamplingFrequency and 9.1.2.2 ySamplingFrequency. These elements go along with 9.1.1 samplingFrequencyPlane which would have a value of 2 for direct digital images, and 9.1.2. samplingFrequencyUnit which defines whether the units for 9.1.2.1 and 9.1.2.2 are in inches or cm (value of 3 for cm). Thus my earlier comment on "PixelDimension" should be modified to change the recommended value from mm to cm for consistency with this standard.--Steve Baskauf 12:53, 1 May 2009 (CEST)
Note that a single dimension may be insufficient in some cases, such as natural scenes taken at high depth of field (including automontage???), Z39.87 supports X,Y,Z dimensions and the ability to specify the units. Even if restricted to MKS units, specifying a single measure, such as mm, seems ill-advised due to the need to support everything in scale from SEM images to pictures of the Sahara desert. --BobMorris 07:16, 1 May 2009 (CEST)
- For this particular item, Z39.87-2006 states "Though range or depth data (i.e."z" dimension) can be digitized with specialized 3-D imaging devices, these are outside the scope of this document."
I disagree that a single unit of measure is ill-advised. A single unit of cm would be no problem: an SEM image can easily use a value of 0.0001 and the Sahara desert can easily be 1000000 (or whatever orders of magnitude are appropriate). Having a standard unit would be important if software were to automatically generate scale bars or allow for direct measurements on images using "click and drag". I have also tested using EXIF data from lenses to calculate these values automatically and have had reasonable success. Since lens focal lengths are given in mm as a standard, having a fixed unit would make sense as it would allow the values of these elements to be generated automatically using software. --Steve Baskauf 13:03, 1 May 2009 (CEST)
Spirtually related to this is a problem that deserves its own discussion, namely color correction. We are silent on such things as ICC color profiles and characterizing the illuminant. Putting standard color bars in the image is almost certainly a best practice, but will have the same social issues. Also, it is not sufficient if you don't characterize the the illuminant. --BobMorris 07:16, 1 May 2009 (CEST)
- This issue was discussed by a number of live plant photographers and although it was agreed that archiving metadata related to color was a good idea, no one had a practical suggestion on how to implement it. Adding color bars is a routine practice in imaging herbarium specimens, but there was widespread sentiment that this would be a bad practice when live plants were involved. With reference to the MRTG "important uses" number 4 (Identification aids), having color bars present as a part of a live plant image (or any live organism in its environment) would be distracting in the same way as a scale bar. In particular, there are visual recognition applications of images that would be rendered ineffective or impossible if extraneous objects were included in live organism images (reference Bruce Kirchoff's work on visual recognition and identification) and it would be a burden to make it necessary for users to have to "Photoshop out" unwanted extraneous objects that were included to satisfy best-practices recommendations. What we need is a creative solution analogous to the solution provided by the xSamplingFrequency element for the scale bar problem, i.e. a way of recording color information that does not require messing with the image itself. I suspect somebody somewhere has the answer to this question.
--Steve Baskauf 16:16, 1 May 2009 (CEST)
- The name "Pixel dimension" may be unsuitable. I would misinterpret this this to contain truly a "dimension" (e.g. 1, 2, or 3), not a length measure. I suggest MillimeterPerPixel or similar as a name. --GregorHagedorn 23:31, 3 May 2009 (CEST)
- I agree about the desirability for e.g. microscopic images, but where is it defined at which distance the "main object" is? which of the 3 plants on a habitus image is the main one, the distance of which is to be defined in this measure? --GregorHagedorn 23:31, 3 May 2009 (CEST)
