Add gravity to metadata about api HOT 13 CLOSED

My opinion is that this is quite subjective and would make a good extension feature. Have a look at #20. The goal there was to, among other things, make it possible to describe the capabilities of the server beyond the specification and/or in-between the published levels of compliance.

If you specify how it's going to work and assign a URI for that feature, then others can implement your extension and claim compliance using the mechanism described. The capabilities doc would look something like this.

Watermarking is another example of a capability that we want to avoid discussing, but would make for a great extension specification.

What do you (and others) think?

from api.

@jpstroop My proposal is not about server capabilities. I want to describe the image. I need something similar to the property viewingDirection from Sequences. The holy demo image has this info:

{
  "width": 5213,
  "height": 5706,
…
  "profile": "http://library.stanford.edu/iiif/image-api/1.1/compliance.html",
  "@context": "http://library.stanford.edu/iiif/image-api/1.1/context.json",
  "@id": "https://stacks.stanford.edu/image/iiif/ff139pd0160%2FK90113-43"
}

My proposal would change to this info:

{
  "width": 5213,
  "height": 5706,
  "gravity": {
    "left": 1400,
    "top": 1200,
    "width": 2500,
    "height": 1075
  },
  …
  "profile": "http://library.stanford.edu/iiif/image-api/1.1/compliance.html",
  "@context": "http://library.stanford.edu/iiif/image-api/1.1/context.json",
  "@id": "https://stacks.stanford.edu/image/iiif/ff139pd0160%2FK90113-43"
}

from api.

No, I get it (and I liked the "x,y,w,h" version more as it could be fed directly to the server 😉). In my suggestion you'd enhance your server's capabilities.json document by adding another context (inline or a second URI) that defines "gravity_info", and then describe what that means in the "extension" attribute. It could look something like this:

{
  "@context" : [
    "http://iiif.io/api/image-api/context.json",
    {
      "ab" : "http://penibelst.de/iiif/", 
      "ab:gravity_info" : {"@type" : "xsd:boolean"}
    }
  ],
  "@id" : "http://libimages.princeton.edu/loris",
  "contact" : "mailto:[email protected]",
  "content_negotiation" : "true",
  "default_format" : "jpg",
  ....
  "ab:gravity_info" : "true", // <--------
  "extensions" : [
    {
      "@id" : "ab:gravity_info",
      "description" : "When true, info.json may include a suggestion about the logical focal point for the image in the attribute 'gravity'."
    }
  ] 
}

Then you could do exactly what you proposed. Is my suggestion clearer? This is for the next version of the spec, so any feedback is most welcome.

@azaroth42 : Does this look right to you? I'm bothered by the fact that the newly defined attribute ("gravity") isn't also in a different namespace. I don't think we've thought of this. Should the info.json doc add a second context as well? E.g.:

{
  "@context": [ 
      "http://library.stanford.edu/iiif/image-api/1.1/context.json",
      {
        "ab" : "http://penibelst.de/iiif/", 
        "ab:gravity" : {"@type" : "xsd:string"}
      }
  ],
   ....
  "width": 5213,
  "height": 5706,
  "ab:gravity": "1400,1200,2500,1075"
}

from api.

Shouldn't this be in the Presentation API, as it's not technical
information about the image?

On the other hand, it is a good example of the extensions idea. We don't
have the concept of extensions in info.json yet, but I could see what you
propose above as being workable. It makes the "protocol" key even more
important though, as checking context would become dangerous/more
complicated to determine what the json is.

from api.

So ... -1 to adding an official gravity field.

On Tue, Mar 11, 2014 at 9:06 AM, Robert Sanderson [email protected]:

Shouldn't this be in the Presentation API, as it's not technical
information about the image?

On the other hand, it is a good example of the extensions idea. We don't
have the concept of extensions in info.json yet, but I could see what you
propose above as being workable. It makes the "protocol" key even more
important though, as checking context would become dangerous/more
complicated to determine what the json is.

On Tue, Mar 11, 2014 at 6:13 AM, Jon Stroop [email protected]:

No, I get it (and I liked the "x,y,w,h" version more as it cold be fed
directly to the server [image: 😉]). In my suggestion you'd enhance
your server's capabilities.json document by adding another context (inline
or a second URI) that defines "gravity_info", and then describe what that
means in the "extension" attribute. It could look something like this. If
you wanted to define:

{
"@context" : [
"http://iiif.io/api/image-api/context.json",
{
"ab" : "http://penibelst.de/iiif/",
"ab:gravity_info" : {"@type" : "xsd:boolean"}
}
],
"@id" : "http://libimages.princeton.edu/loris",
"contact" : "mailto:[email protected]",
"content_negotiation" : "true",
"default_format" : "jpg",
....
"ab:gravity_info" : "true", // <--------
"extensions" : [
{
"@id" : "ab:gravity_info",
"description" : "info.json includes a suggestion about the logical focal point for the image in the attribute 'gravity'."
}
] }

Then you could do exactly what you proposed. Is my suggestion clearer?

This is for the next version of the spec, so any feedback is most welcome.

@azaroth42 https://github.com/azaroth42 : Does this look right to you?
I'm bothered by the fact that the newly defined attribute ("gravity") isn't
also in a different namespace. I don't think we've thought of this. Should
the info.json doc add a second context as well? E.g.:

{
"@context": [
"http://library.stanford.edu/iiif/image-api/1.1/context.json",
{
"ab" : "http://penibelst.de/iiif/",
"ab:gravity" : {"@type" : "xsd:string"}
}
],
....
"width": 5213,
"height": 5706,
"ab:gravity": "1200,1400,1075,2500"}

Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-37288752
.

from api.

Right now in Section 5 of 1.1 we say:

...additional properties not specified here may be included but should be ignored if not understood.

Maybe that's enough?

from api.

That's enough, but it's weird to have explicit extensions in the profile
and then "just throw stuff in" for info.json. We should be consistent, at
least.

On Tue, Mar 11, 2014 at 9:28 AM, Jon Stroop [email protected]:

Right now in Section 5 of 1.1 we say:

...additional properties not specified here may be included but should be
ignored if not understood.

Maybe that's enough?

Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-37308685
.

from api.

Good point. Submitted as #53.

from api.

Thank you for explanation. It wasn’t clear to me, what context is for. I have to learn more about JSON-LD. I will extend the meta in the suggested way.

Look how my old image meta looks: images.yaml Can’t wait to change everything to your specs.

from api.

What about abusing the viewingHint property for the focal point information?

A hint to the viewer as to the most appropriate method of displaying the object. It is valid on the Manifest, Sequence of Range as per viewingDirection. This field can be any string, …

As @jpstroop said:

I liked the "x,y,w,h" version more as it could be fed directly to the server

{
"viewingHint": "1400,1200,2500,1075"
}

Do you think you could allow viewingHint for image content? Now it’s not applicable.

Viewing hints for images are very natural. When people meet and show each other photos, they emphasize the most important part of the image. “Look at her shoes, I bought the same last week.”

from api.

To me, areas on a Canvas that are important should be highlighted by an
annotation. We could mint a "gravity" motivation to make it clear what the
annotation is about. And it could, but doesn't have to, also have a
comment such as the example "look at her shoes!"

Thus:

{
  "@type": "oa:Annotation",
  "motivation": "iiif:gravity",
  "on": "...canvas/1.json#1400,1200,2500,1075",
  "resource": {"chars": "Look at her shoes!"}
}

On Wed, Mar 12, 2014 at 2:14 AM, Anatol Broder [email protected]:

What about abusing the viewingHint property for the focal point
information?

A hint to the viewer as to the _most appropriate method of displaying_the object. It is valid on the Manifest, Sequence of Range as per
viewingDirection. This field can be any string, ...

As @jpstroop https://github.com/jpstroop said:

I liked the "x,y,w,h" version more as it could be fed directly to the
server

{"viewingHint": "1400,1200,2500,1075"}

Do you think you could allow viewingHint for image content? Now it's not
applicable.

Viewing hints for images are very natural. When people meet and show each
other photos, they emphasize the most important part of the image. "Look at
her shoes, I bought the same last week."

Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-37384130
.

from api.

Sorry, also ... what will a viewer do with the information of the gravity
in a practical sense? I understand the use case from a descriptive sense,
but not how that information would be used in code. Thanks! :)

On Wed, Mar 12, 2014 at 10:11 AM, Robert Sanderson [email protected]:

To me, areas on a Canvas that are important should be highlighted by an
annotation. We could mint a "gravity" motivation to make it clear what the
annotation is about. And it could, but doesn't have to, also have a
comment such as the example "look at her shoes!"

Thus:

{
  "@type": "oa:Annotation",
  "motivation": "iiif:gravity",
  "on": "...canvas/1.json#1400,1200,2500,1075",
  "resource": {"chars": "Look at her shoes!"}
}

On Wed, Mar 12, 2014 at 2:14 AM, Anatol Broder [email protected]:

What about abusing the viewingHint property for the focal point
information?

A hint to the viewer as to the _most appropriate method of displaying_the object. It is valid on the Manifest, Sequence of Range as per
viewingDirection. This field can be any string, ...

As @jpstroop https://github.com/jpstroop said:

I liked the "x,y,w,h" version more as it could be fed directly to the
server

{"viewingHint": "1400,1200,2500,1075"}

Do you think you could allow viewingHint for image content? Now it's not
applicable.

Viewing hints for images are very natural. When people meet and show each
other photos, they emphasize the most important part of the image. "Look at
her shoes, I bought the same last week."

Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-37384130
.

from api.

what will a viewer do with the information of the gravity in a practical sense? I understand the use case from a descriptive sense, but not how that information would be used in code.

Take a look at that original photo of a sleeping woman in the left-bottom corner.

I decide that she is the most important part, an set gravity to lb. Then I put the image on a website in full screen. I don’t know how big user’s screen is. But my script (js) always set the region in a way the left-bottom part stay visible.

On a 16:9 screen in landscape mode the user get:

image.jpg&gravity=lb&widht=800&height=450

On a 16:9 screen in portrait mode the user get:

image.jpg&gravity=lb&widht=450&height=800

The woman is always there.

from api.