DPI of image in image information response

[Robert Casties]

Hi,

I would like to propose to add DPI information about the image to the
image information response.

The information would be optional but it would enable the client for
example to display a correctly scaled cm/inch scale with the image.

In our digilib[1] viewer we also have a feature to calibrate the
resolution of your screen by measuring a given pixel-scale and then
display the server's image in its original size.

My proposition is to add an optional "dpi" member to the JSON object
returned from the image info request.

Or should we call it "resolution" and add "dpi" or possibly other units
to the value (more difficult to process).

Do we need separate values for "dpi_x" and "dpi_y" for non-square-pixel
images?

What do you think?

Robert Casties

[1] http://digilib.sf.net

[coms...@g.harvard.edu]

Hi.

While I'm not a developer, I am an IIIF enthusiast. I was surprised to read Robert Casties' suggestion that the image capture resolution value should be included in the list of image parameters made available via the API. I assumed this was already the case, in part because I've playing with Harvard's test-instance of Mirador and I think the scale is a *terrific* feature. If we can provide applications with image pixel dimensions and a capture resolution value, those are the only bits of data needed to draw a correct scale.

Keep up the good work!

-- Bill

-- 

Bill Comstock
Head of Imaging Services
Harvard Library Preservation
Widener, D70C
Harvard Yard
Cambridge, MA 02138
--
P 617-496-5241
F 617-495-0403
http://imaging.harvard.edu/
--
* Digitized collections at Harvard *
http://library.harvard.edu/digital-collections

[Robert Casties]

Hi Bill,

On 09.04.14 14:33, coms...@g.harvard.edu wrote:
> While I'm not a developer, I am an IIIF enthusiast. I was surprised to read Robert
> Casties' suggestion that the image capture resolution value should be
> included in the list of image parameters made available via the API. I assumed
> this was already the case, in part because I've playing with Harvard's
> test-instance of Mirador and I think the scale is a *terrific* feature. If
> we can provide applications with image pixel dimensions and a capture
> resolution value, those are the only bits of data needed to draw a correct
> scale.

Mirador currently requires you to add the correct size of the image
manually in the frontend. The displayed scale is rendered accordingly.

With dpi information from the server the scale could be calibrated
automatically.

Additionally I'd like a detachable scale or an interactive measurement
function in Mirador to mark a line on the image and get the length of
that line :-)

Best
Robert

[Henshaw, Christy]

Hi Robert,

I am just curious - do you mean a scale bar in relation to the size of the object that was photographed? Wouldn't the client need to know what the scale of the pixels are (e.g. 1 pixel = 4mm)? It seems to me that could be highly variable, and most people wouldn't even capture that information - but I don't have the best grasp of these things!

Regards,
Christy

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


This message has been scanned for viruses by Websense Hosted Email Security - www.websense.com

[Robert Casties]

Hi Christy,

On 09.04.14 10:42, Henshaw, Christy wrote:
> I am just curious - do you mean a scale bar in relation to the size
> of the object that was photographed? Wouldn't the client need to know what
> the scale of the pixels are (e.g. 1 pixel = 4mm)? It seems to me that
> could be highly variable, and most people wouldn't even capture that
> information - but I don't have the best grasp of these things!

I was mentioning two different ideas that both rely on knowledge of the
resolution of the image.

The first and most obvious use would be to have a cm/inch scale in the
client display like Mirador already has. Currently you have to manually
specify the real image size but that could be done automatically. The
scale changes the when you zoom in so you always have a comparison to
real cm/inches regardless of your screen resolution.

The other feature I mentioned is already built in to our digilib image
server: you can calibrate your screen resolution by physically measuring
the length of a displayed rule and entering the length into the client.
Then the client can display the image at its real physical size on your
screen (when it gets the image resolution from the server). Seeing the
image at its real size is admittedly only useful in a small number of
use cases, we built it for our art history colleagues studying
architectural drawings.

Does that make it clearer?

Best regards

Robert

[Henshaw, Christy]

Hi Robert,

Ok, I understand how you could do a measurement on a scale bar captured with the item to indicate original size to the software for print/screen scaling (ala Photoshop). I don't really understand how that could be done automatically though. Unless the scales are positioned in a standard area of the image and the software could somehow read the scale. Sorry if I'm being dense! I'm just thinking if you were to use the same camera/lens setup to photograph the Eiffel Tower and another of a postage stamp, how would any software be able to automatically work out the original size of the field of view covered by these images?

I'm asking, as I'm trying to work out whether this is information we would definitely want to capture and make available via the API when we eventually move over to IIIF.

Cheers,
Christy

[Robert Casties]

Hi Christy,

On 10.04.14 10:03, Henshaw, Christy wrote:
> Ok, I understand how you could do a measurement on a scale bar
> captured with the item to indicate original size to the software for
> print/screen scaling (ala Photoshop). I don't really understand how
> that could be done automatically though. Unless the scales are
> positioned in a standard area of the image and the software could
> somehow read the scale. Sorry if I'm being dense! I'm just thinking
> if you were to use the same camera/lens setup to photograph the
> Eiffel Tower and another of a postage stamp, how would any software
> be able to automatically work out the original size of the field of
> view covered by these images?

No, the software would not be expected to guess the resolution of your
image, you would need to somehow supply that information explicitly on
the server. My proposition is just to forward the information to the
IIIF client if it already exists on the server.

> I'm asking, as I'm trying to work out whether this is information we
> would definitely want to capture and make available via the API when
> we eventually move over to IIIF.

Generally, when scanning books or manuscripts in a fixed setup it is
relatively easy to calculate the resolution of the resulting pixel
image. Either your equipment already does this or you can measure the
pixels on a captured scale like you said and apply the measurement to
all images shot at the same distance.

I would always suggest to capture the dpi information as well as a color
profile or at least a captured color chart with any digitization if
possible. Its easier to capture it right away and it makes the images
much more useful to the researcher even if the information isn't used
from the beginning.

Best

[Henshaw, Christy]

Thank you Robert! That all makes sense now.

Best wishes,
Christy

[coms...@g.harvard.edu]

Regarding Robert's more specific questions and requests for feedback, I would suggest including three resolution values: samplingFrequencyUnit (inch | cm | no meaningful value), xSamplingFrequency, ySamplingFrequency. [These are three of the four resolution values correspond to MIX, the fourth (which I've omitted) being samplingFrequencyPlane.] In Exif speak, these would be ResolutionUnit, XResolution, and YResolution.

"ppi" would be better than "dpi", though I don't think it matters.

-- best, bill comstock

On Tuesday, April 8, 2014 6:51:34 AM UTC-4, Robert Casties wrote:

[Jon Stroop]

As the image info is serialized as JSON-LD, I think typed literals could be used to express the unit, e.g.:

{
    ...
    "height": 7200,
    "width": 5454,
    "height_res": { "@value" : 236, "@type" : "http://sweet.jpl.nasa.gov/2.3/reprSciUnits.owl#centimeter" },
    "width_res": { "@value" : 236, "@type" : "http://sweet.jpl.nasa.gov/2.3/reprSciUnits.owl#centimeter" }
    ...
}

i.e., the resolution is 236 pixels per cm. for both dimensions.

-Jon

--

[Robert Sanderson]

I agree with typed literals, no need to reinvent the wheel on that one... assuming that there's a good type to use.  I don't think, for a resolution, that cm is correct -- it's not 236 cm, it's 236 pixels per centimeter.  The name of the key in the JSON also needs to be thought about a little -- height (especially with a CM value) implies to me that the /total/ height is 236 cm. So the resolution would be (7200 / 236) pixels per centimeter.

How about:

   "phys_height" : 12.3^cm    // height of the thing in the image is 12.3cm

or:

   "resolution_x" : 236^ppi    // resolution is 236 pixels per inch, and need to find good set of types

A higher level question is where does it belong, if anywhere?

-- Image API: it's technical information about a particular image only.  From that information you can generate a scale depending on the image being displayed, regardless of how and where.

-- Presentation API:  it's the relationship between the "ideal" digital page (the canvas) and the real world.  From that information you can generate the DPI for all of the images associated with a particular canvas.  For canvases with only partial images, the math becomes somewhat more complex.

-- Nowhere: it's so rarely reliably available that it's not worth including at all.  

(and clearly not the to-be-defined search or annotation APIs)

My preference order is Image, Nowhere, Presentation.

Rob

--

Rob Sanderson

Technology Collaboration Facilitator

Digital Library Systems and Services

Stanford, CA 94305

[Jon Stroop]

Doh, you're right...not 236 cm!!!

[Tom Cramer]

It seems to me that...

   "phys_height" : 12.3^cm    // height of the thing in the image is 12.3cm

belongs in the Presentation API. Note that items with rich, full bibliographic description coming from Libraries may already have physical dimensions recorded in the the MARC 300 field: http://www.loc.gov/marc/bibliographic/bd300.html, so this data will exist for some IIIFy materials. 

Further, 

   "resolution_x" : 236^ppi    // resolution is 236 pixels per inch, and need to find good set of types

belongs in the info.json response of the Image API, as it is particular to the image, not the physical object. And some number of images may actually have this represented in their technical metadata (sometimes--often?--in the headers). 

Rob--it seems to me that your proposal fully covers Bill's EXIF/MIX-inspired attributes of X and Y sampling frequency / resolution, and that with a few other examples ("good set of types") we could easily make clear the units (Bill's 3rd variable). 

Bill or other image experts on this list--would you be able to suggest a few archetypes of other units / resolutions, such that Rob could express them in types? 

- Tom

[Robert Casties]

Hi Tom,

On 11.04.14 05:05, Tom Cramer wrote:
> It seems to me that...
>
>> "phys_height" : 12.3^cm // height of the thing in the image is 12.3cm
>
> belongs in the Presentation API. Note that items with rich, full bibliographic description coming from Libraries may already have physical dimensions recorded in the the MARC 300 field: http://www.loc.gov/marc/bibliographic/bd300.html, so this data will exist for some IIIFy materials.

Its important to note that the size of the item/book will generally not
be the same as the size of the visible image area for the scans.

So while I think this information could belong to the Presentation and
could be shown to the user it should not be used to calculate the
resolution of the images.

> Further,
>
>> "resolution_x" : 236^ppi // resolution is 236 pixels per inch, and need to find good set of types
>
> belongs in the info.json response of the Image API, as it is particular to the image, not the physical object. And some number of images may actually have this represented in their technical metadata (sometimes--often?--in the headers).

I also think it belongs in the info.json of the image.

For our image server we store reliable resolution information in
separate metadata files because the resolution in embedded EXIF fields
is mostly not reliable and especially its hard to know when it is and
when it isn't.

> Rob--it seems to me that your proposal fully covers Bill's EXIF/MIX-inspired attributes of X and Y sampling frequency / resolution, and that with a few other examples ("good set of types") we could easily make clear the units (Bill's 3rd variable).

Do EXIF or MIX have a JSON-LD mapping? Could we borrow from one of those?

> Bill or other image experts on this list--would you be able to suggest a few archetypes of other units / resolutions, such that Rob could express them in types?

I'm fine with pixels per inch.

Best
Robert C.

--
Dr. Robert Casties -- Information Technology Group
Max Planck Institute for the History of Science
Boltzmannstr. 22, D-14195 Berlin
Tel: +49/30/22667-342 Fax: -299

[coms...@g.harvard.edu]

Tom,

Could you give me some additional direction regarding your request, "Bill or other image experts on this list--would you be able to suggest a few archetypes of other units / resolutions, such that Rob could express them in types"?

Is this the sort of example you're looking for?

<mix:mix xmlns:mix="http://www.loc.gov/mix/v20">

            <mix:SpatialMetrics>

              <mix:samplingFrequencyUnit>cm</mix:samplingFrequencyUnit>

              <mix:xSamplingFrequency>

                <mix:numerator>118</mix:numerator>

                <mix:denominator>1</mix:denominator>

              </mix:xSamplingFrequency>

              <mix:ySamplingFrequency>

                <mix:numerator>118</mix:numerator>

                <mix:denominator>1</mix:denominator>

              </mix:ySamplingFrequency>

            </mix:SpatialMetrics>

-- Bill

[Robert Sanderson]

On Fri, Apr 11, 2014 at 3:05 AM, Robert Casties <cas...@mpiwg-berlin.mpg.de> wrote:

On 11.04.14 05:05, Tom Cramer wrote:
> It seems to me that...
>>    "phys_height" : 12.3^cm    // height of the thing in the image is 12.3cm
> belongs in the Presentation API. Note that items with rich, full bibliographic description coming from Libraries may already have physical dimensions recorded in the the MARC 300 field: http://www.loc.gov/marc/bibliographic/bd300.html, so this data will exist for some IIIFy materials.

Its important to note that the size of the item/book will generally not
be the same as the size of the visible image area for the scans.

Agreed, and agreed that it belongs in Image API's info.json, however the intent of the canvas is only to represent the actual page ... not any outside space that might exist in images of the page.  So in theory you could calculate DPI ... in practice only very rarely when there is a tight crop.  And then not very accurately. 

 

> Rob--it seems to me that your proposal fully covers Bill's EXIF/MIX-inspired attributes of X and Y sampling frequency / resolution, and that with a few other examples ("good set of types") we could easily make clear the units (Bill's 3rd variable).

Do EXIF or MIX have a JSON-LD mapping? Could we borrow from one of those?

There is an exif ontology: http://www.w3.org/2003/12/exif/

I can't find an existing context, but we would need to copy the definitions anyway or require a reference to the other context.

Exif has xResolution, yResolution and resolutionUnit... which doesn't use the data typing technique, but at least doesn't require inventing datatypes or predicates.

resolutionUnit however has only three possible values:  1 (meaning unknown/none), 2 (meaning inches) and 3 (meaning centimeters)

So 300 DPI would be:

{

  ...

  "xResolution" : 300,

  "yResolution" : 300,

  "resolutionUnit" : 2,

  ...

}

Rob

[Jon Stroop]

See: http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/#horizontalResolution

I wonder if this approach of constraining the unit of measure by the definition of the property ("Expressed in DPI") might be an simpler approach. I don't love it, but I've never heard anyone talk about 'dots [or pixels] per centimeter' either. That may well be a lack of experience on my part.

(As an aside, a mapping of the IIIF Image info properties to the above ontology may be worth exploring in general. I will raise it with the other editors.)

-Jon

[coms...@g.harvard.edu]

Hi Jon.

When we speak about resolution we are usually (always?) referring to capture resolution. How many samples did our image capture device record per unit of measure, relative to the source material -- our subject.

 The "horizontalResolution" element you link to below refers to output resolution: "Horizontal resolution of an image (if printed). Expressed in DPI." This is something different. This value refers to the number of samples you are going to render (e.g., print) per unit of measure relative to the output media (e.g., the paper stock in your printer).

 We only care about the capture resolution because knowing this value allows us to calculate the scale of the image, and therefore the size of any objects in the image frame.

 FYI:

 The JP2 format includes a resolution "box" that accommodates both a Capture Resolution value and a Default Display Resolution value. "The units of both quantities are canvas grid points per meter."

For better or worse, PPI and DPI are used interchangeably, with DPI being the more common of the two. To be persnickety, PPI is really about capture resolution: How many photosites (pixels) are set against the subject of the capture. PPI is about inputs; DPI is, to be persnickety, about outputs. Those "dots" per inch are dots of ink printed, or they are individual display elements.

Again, DPI is used commonly to refer to both input and output resolutions.

 -- Bill

[Jon Stroop]

Bill,
Thanks, this is really useful information! To be clear, I was more interested in the approach for the unit of measure, i.e. just assume it's inches rather than making the info.json data structure (perhaps) unnecessarily complex.

Thanks for clearing up DPI vs PPI as well--I'd always associated DPI with printing, but just assumed everyone else knew something I didn't. If I understand you correctly, PPI is our real concern, despite the original request.

Thanks again,
-Jon