New term proposal: ac:scaleConversionFactor

[kymillev]

I'd like to propose a new term called the scale conversion factor (name may be improved). This additional field describes a scale conversion factor (single number), which can be used to convert the scale of an image (or measurements made on it) from pixels to a standardized unit (centimeters). So, a scale conversion factor of 100 would mean a distance of 100 pixels equals 1 centimeter. So, to convert measurements, one can simply divide their pixel measurements by this factor. We could also use millimeters as the standard unit, if that is more common.

Use case

Specimen traits are invaluable for biodiversity research. These can either be measured in-situ or on a digitized image of the specimen.
Specifically for traits concerning shape or size, annotating them on the image is far easier with the help of digital tools. However, these annotations are made in pixel units and depend on the image resolution.

To normalize these annotations to a metric unit like centimeters, they need to be converted. A standard way of doing this is to measure the average pixel distance of a single centimeter or inch on an included ruler in the image. Manually measuring rulers on every page is troublesome, and automated methods are being developed (LeafMachine, Mothra, and my own) to tackle this and measure specimen traits. Adding this scale conversion factor to the specimen metadata enables the standardization of any current or future annotations made on the image. Furthermore, it gives insight into the total size of the specimen sheet (e.g., for herbaria) and quality of the digitization (more pixels per cm denote a higher quality).

The "scale conversion factor" can be calculated for any specimen that has a digitized image with a ruler or other fixed-size object, but the main benefit will be for those photographed from the top (e.g., herbaria, botany, entomology) or the side/front (e.g., zoology). Additionally, specimens digitized with a scanner or similar technology can already offer this conversion factor out of the box during the calibration of the setup.

Note: to be more exact, this scale conversion factor is different for the x and y directions and depends on where it is in the image (due to camera lens warping). However, I expect this difference to be small and would not include this in the standard initially. Also, rulers are typically placed horizontally or vertically, so the pixel distances between ruler ticks in one of these directions are minimal, resulting in large differences (errors) for the conversion factors if measurements are off by a few pixels. I'm planning to measure these errors in the future.

[danstowell]

Two related reactions from me: (1) I don't see why "cm" would be a hard-coded unit; if anything, you should use the SI unit and thus "m".. (2) I think this can be generalised. Anything measured on a grid could have an intrinsic scale mapping back to the world. This could be in metres, seconds, Hertz, ....

So from my perspective: how about ac:scaleFactor (a number) and ac:scaleFactorUnits (probably a controlled list)?

You write: "scale conversion factor of 100 would mean a distance of 100 pixels equals 1 centimeter." (This means that the true units are in fact cm^-1, not cm.) Why do you define it by division, rather than multiplication? I see it as more common to define scaling factors the other way, e.g. dots-per-inch (DPI) in printing means that you multiply the pixels by the DPI to get the measurement. Is there some standard usage that you wish to align with? Can you show examples?

(I agree with your note: it would be excessive for us to try and adapt to uneven scaling factors.)

[kymillev]

@danstowell that's a great suggestion to split the factor and the units. This would indeed make more sense and allow the same field to be used for other data types, which I hadn't thought of. For each relevant SI unit we can then have a list of the common variants (e.g., km, m, cm, mm, nm, etc.). Making this change in the application code would then be trivial. I now normalize everything to cm to make processing easier (and cm was chosen arbitrarily).

For the second point, it may also be better to define it that way. It does make the numbers less "intuitive" as they now become fractions (for instance, 175.5 pixels per cm becomes 0.00570), but indeed it aligns more closely with other standards such as DPI.

I have some examples on a demo website of processed specimens and rulers using my method.

[edwbaker]

@magpiedin @rebeccasnyder Just highlighting this for potential input from 3D Task Group

[magpiedin]

Thanks @edwbaker & @kymillev

At first glance, it sounded like this term might overlap with proposed 3D terms for ac:pixelXSpacing & other Y/Z pixel-spacing terms (included here on the "ac_3d_terms" tab), but at a closer look, they might actually complement each other instead.

@kymillev if you have a chance to look at the definitions for the 3D pixel-spacing terms, what do you think?

@rebeccasnyder might have more input too -- e.g. regarding workflows & ease/difficulty for data providers to provide conversion factor values for large data/media sets. (She also pointed out that isn't necessarily a problem if the new term is optional)

[kymillev]

@magpiedin The pixel spacing terms are similar, but describe the distance for each dimension separately. With this term, we describe it using a single distance. Imo it would be error-prone to split it into x/y, as rulers are typically oriented along the x or y direction. This means that small differences in pixel distances can lead to large differences when converting units and likely larger errors.

We can however, use the same bf:Unit to specify which unit should be used.

[magpiedin]

Thanks @kymillev -- I think those points make sense.

Recipes might be helpful, too, if we need to recommend that an Audiovisual Core record should use either the scale-conversion term or the pixel-spacing terms -- but not both -- depending on that record's media type. (In which case, all good to use the same bf:Unit term)

(...Sounds like pixel-spacing terms are more specific to 3D data after all -- e.g. properly recording+interpreting CT data along these lines -- while the scale-conversion term would help properly interpret measurements in 2D media or audio & other more linearly scaled media-types as you & Dan pointed out above. All ears though if I'm mangling anything @rebeccasnyder @JocelynTriplett )