Show a single static image

[tomcrane]

Given a IIIF Image Service, I want to render the /full/ image at a particular size, as a static image.
As if I had just used an img tag.

I might want to constrain by width, by height, or by both.
I might want the component to select an appropriate source image that might not exactly match the size I specified. I want to control this behaviour.
I might want the component to select a higher resolution source than my constrained dimension(s) so that it looks good on retina displays (the w,h of the pixel sources might be different from <img style="width: 100px" />).

Given a IIIF Canvas, I want to render the Canvas as a single image in the same way.
In this case, the 99.99% path would be to observe that the Canvas only has one image and targets the whole Canvas, so the behaviour and impl is the same as above - just take that image service.

But the 0.0..01% case will require image composition.

Accessibility considerations

I should be able to tell the component to use the label it finds on the Canvas (with aria-label etc) or on the (v3) image service
I should be able to provide alternative or additional strings
I should be able to control what IIIF-sourced properties are used for what alt, title, aria-label properties, overriding the sensible default behaviour, including not asserting an accessibility property if there is reason not to.

[stephenwf]

I have a question on this one. Is it always desirable that only a single image is used – maybe from the "sizes" property in an image service, especially if a thumbnail service is used. Or should it, from a developers point of view, work as if it were a single image?

So to use it, something like this if it was a web component

<img-service src="..." style="width: 200px; height: 500px" />

But under the hood it might decide to position 6 256x256 tiles. So I guess the question is, should the developer care which approach is used and should they have any control over it?

[tomcrane]

What does the HTML as seen by the browser in the DOM, and hence by assistive technologies, look like?

[tomcrane]

If a screen reader sees it as an img tag (eventually) it will be more accessible.

[tomcrane]

But maybe it's an option, with default behaviour. E.g., component is allowed to render as HTML5 Canvas from multiple tiles if it wants to. I don't know what the accessibility best practice is, but we should ensure that it is as accessible as possible - more than it would be using OSD alone, for example.

[stephenwf]

To support assistive tech the tag img-service or whatever it may be would have to have any aria or title attributes. If there was a set of tiled images however, a screen reader would only see one tag. That might be an advantage, as there is likely only one description for the whole image.

[stephenwf]

Non-web component example of positioning multiple <img /> elements instead of using a canvas: https://atlas-viewer-storybook.netlify.app/?path=/story/static-renderer--default-static-tiles

[tomcrane]

For all the "show image" use cases...
The resource to hand might be an image service, or canvas (that very likely has come from a manifest, but in theory could exist on its own). How would the developer want to specify the input?

Problem... I have some resource and I want to use it to render an image.

different props:

image-service=https://imageserver.org/my-image-service
canvas=https://presentationserver.org/my-standalone-canvas
canvas=https://presentationserver.org/my-canvas-id partof=https://presentationserver.org/my-manifest

or

iiif-content=https://imageserver.org/my-image-service
iiif-content=https://presentationserver.org/my-standalone-canvas
iiif-content=https://presentationserver.org/my-canvas-id partof=https://presentationserver.org/my-manifest
iiif-content=https://myserver.org/my-content-state

where the partof indicates "load this first, then look for the iiif-content (or canvas) value within it"

If the value of the prop is a content state, the component needs to evaluate it (is it an encoded anno? Is it a fetched content state?) and process - wouldn't need the partof because that would be part of the content state anno. But the component would still need to support the combo of "id of thing to render" within "thing you can actually dereference" - two values. You might even be processing a content state outside of Canvas Panel and then using CP to render it.

[stephenwf]

I think those should be distinct, loading an image service vs. loading from IIIF directly. The image service one can be used without being tied into a method for data-loading (manifesto, manually fetching etc.). Whereas one that parses and understands IIIF not only needs some way to load and parse the data, but also make decisions.

<img-service canvas=" ... " manifest=" ... " />

Would this still only be rendering a single image service? Should it render only the first if there are 2, or simply not rendering anything if it's a different type of annotation?

[stephenwf]

So when thinking about the data side, to enable this component we need:

• An easy way to extract an image service from a canvas
• An easy way to determine if an image only has a single image service

Which should be enough to make a determination as to wether you should use this component to render it.

[tomcrane]

If you have those easy ways at the library level, then as a developer you know what you have available to pass to the rendering component.

So - I know what I have in my hand so I can either do:

<img-service src=https://imageserver.org/my-image-service />

or

<canvas iiif-content=https://presentationserver.org/my-canvas-id partof=https://presentationserver.org/my-manifest />

or perhaps

<canvas iiif-content=https://myserver.org/my-content-state />

and

<canvas iiif-content=[encoded content state] />

[tomcrane]

Reading the thinking on https://canvas-panel.digirati.com/developer-stories/cp1.html...

This hypothesised a web component something like this (wouldn't use is now though):

 <div is="canvas-panel-1" id="cp1" class="canvaspanel"
    data-canvas-uri="https://wellcomelibrary.org/iiif/b22047347/canvas/c24"
    data-partof-uri="https://tomcrane.github.io/webcomponents/wunder.json"> 
 </div>

...and then argued that this in fact wasn't canvaspanel but a light wrapper around it. On https://canvas-panel.digirati.com/developer-stories/cp2.html I suggest:

 <!-- The v2 Canvas Panel Component -->
 <div is="canvas-panel-2" id="cp2" class="canvaspanel"></div>
 
 <script>
    async function init(){
        let uri = "https://tomcrane.github.io/webcomponents/wunder.json"
        let response = await fetch(uri);
        let manifest = await response.json();
        // manifest = normaliser.normalise(manifest); // skip for now 
        cp2 = document.getElementById("cp2");
        cp2.canvas = manifest.items[8];
    }     
    init();
</script>

NB this markup is just copied from the stories, not necessarily a suggestion for now - it would be using vault...

It suggests that the thing in the previous comment called <canvas /> is actually something like <canvas-loader />.

Not sure if this discussion is meaningful :)

I guess it's about what does normalisation. <canvas /> could be a pure thing that requires a normalised P3 canvas, so that it doesn't itself do any internal fetching, traversing and normalising (doesn't depend on vault).

Then <canvas-loader /> could be the thing that you can just throw IIIF at via

<canvas-loader iiif-content=https://myserver.org/my-content-state />`
<canvas-loader iiif-content=https://presentationserver.org/my-canvas-id partof=https://presentationserver.org/my-manifest />

<canvas-loader /> is a wrapper around <canvas /> and you might use <canvas-loader /> more often in a very simple example, but <canvas /> in a viewer where you're already doing vault-operations and will always have a clean normalised canvas by the time your code wants to render it.

Or, <canvas /> just does both kinds of thing.... I don't know.

[tomcrane]

Or, just does both kinds of thing.... I don't know.

Running with this for the time being, and trying to summarise the above discussion. Keeping <img-service /> a separate tag, because <canvas-panel /> lives in the world of the Presentation API and <img-service /> does not. Using a different tag that can only render an image helps understanding of the wider Presentation API capabilities of canvas-panel.

However, the tags share a number of attributes. For most canvases in the world, that have one image for the whole canvas, the default rendered output is the same.

A ..content_state.. can be in any of the forms listed in the spec - e.g., a URL of a de-referenceable anno, an encoded inline annotation.

// template developer knows they have an image service
// this tag behaves like an <img /> tag. It can only be an image! 
<img-service src="http://..." render="static" />

// template developer has a canvas id within a manifest
<canvas-panel
   render="static"
   iiif-content="https://..canvas_id.."
   partof="https://..manifest_id.."
</canvas-panel>

// template developer has a canvas within a manifest expressed as a content state (partof is provided by the content state) 
<canvas-panel
   render="static"
   iiif-content="..content_state.."
</canvas-panel>

// programmatically

<img-service id="im1" />
<script>
  document.getElementById("im1").src = "https://..image-service..";
  im.setAttribute("render", "static"); // what does it mean to do this after setting `src`?
</script>

<canvas-panel id="cp"></canvas-panel>
<script>
   const vault = new Vault();
   const cp = document.getElementById("cp");
   cp.setAttribute("render", "static");
   // cp.render = "static"; // ??? can you do this too? 
   await vault.loadManifest("..manifest_id..");
   cp.setCanvas("..canvas_id..");
</script>   

What events, attributes and properties are shared by img-service and canvas-panel ?
What events are exclusive to canvas-panel ?

If the image service is version 3, and if it supplies a preferredFormats property, both tags will use the preferred format(s).

The user can also set a preferred format manually:

<img-service src=".." preferred-formats="png" />
<img-service src=".." preferred-formats="webp,jpg" />

If this format is not available the tag will fall back to the default jpg.