Comments (13)
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.
Related Issues (20)
- Bring Physical Dimensions into core Presentation 4
- Processing requirements for bgColor and linked canvas/scenes
- 3D: angles are not defined consistently HOT 1
- Definition of RotateTransform in the draft 3D API HOT 2
- Latest stable version is missing from Change Discovery 1.0 API header HOT 2
- Clarify transform applied to camera and light in 3D draft HOT 2
- Added field size property to OrthographicCamera HOT 6
- Content State links to 0.9 spec for "section 6"
- URI encoding in Content State HOT 5
- Bodies and targets clarification in content-state section linking HTTP GET Parameter HOT 1
- Inconsistent terminology for intensity units of lights in draft 3D api and example manifest
- Possible discrepancy between Pres. API spec. and JSON-LD Context re. viewingDirection HOT 2
- painting motivations in search examples are unclear
- Recipes will need to deal with versions for 3.0 and 4.0
- Can Ranges reference Canvases in *other* Manifests?
- Can't distinguish between seek to time X and stop, versus seek to X and play HOT 1
- Conflict between GeoJSON and Prezi 4 term `transform` ?
- Allow navPlace and navDate on Annotations?
- Does `lookAt` track an object or is it a shortcut for a point? HOT 1
- Can `lookAt` look at an arbitrary volume? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from api.