I think we can call it a IIIF image as thats what we are talking about here.

Could you explain what these are? Maybe a translation or something to say its First Edition / Second Edition etc...

Maybe also good to mention ranges can have metadata elements if the label is too restrictive. This can be useful if parts of the manuscript have different authors as well as titles.

Extra text not needed

I think these need to be () to get the link to work.

Should this be a , ?

This should be a formatted link.

that for a full canvas annotation only the URI of the Canvas...

I think it would be useful to give an example format either here or in the example. The two I can think of are text/plain and text/html

Syntax of this option is similar to Option 2 above but the viewing experience is completely different due to the support for VTT in modern viewers.

Capitalise

Capitalise

Note link to updated recipe:

https://preview.iiif.io/cookbook/0219-using-caption-file/recipe/0219-using-caption-file/

Does this not following option 2 above with a single file being annotated on to the canvas?

Is this specified in the spec?

Maybe remove this sentence? I'm not sure it adds anything

Should this be a comma?

such as newspapers, audio or video recordings

Label needs updating now as we are using LOC data.

Editors: extensible maybe rather than elastic.

I wonder if we can expand the sizes explanation as this is a key feature of the recipe. I can't find a useful summary from here: https://iiif.io/api/image/3.0/#53-sizes or in Tom's document but I wonder if we can say something like:

The IIIF Image info.json contains a property called sizes. This is used to advertise scaled versions of the full image that are made available by an image server.

The provider of the image server can ensure that these sizes are in a part of the image server which is quick and efficient to respond to requests. This might be by storing them outside of the image server as static images or using a CDN or other high speed caching option.

If clients use the images advertised in the sizes from the info.json then they can be assured of a faster response than requesting a specific custom size from the Image service.

This is a good point! As per comments below it does kind of suggest the image service is redundant in the thumbnail as you can get it in the image service.... As below maybe this is the reason to use level0 in the thumbnail as the recommendation?

I think this answers your question above where you say on a canvas the image service would be duplicated. I'm half wondering whether this makes the level 0 the one to recommend for the thumbnail and if you need a custom size go to the image service rather than the thumbnail.. What do you think?

Maybe put 100 pixels by 100 pixels in brackets just to be clear which one we are talking about.

full flexibility?

Should we remove this sentence? the parts around it seem to cover the issue and its not really a performance issue for the client as such.

I think this is resource intensive for the Image server rather than the viewing client. The viewing client will make the same amount of requests if its using a thumbnail or image service but using static images is requires less resources on the server side.

And is this the level 0 service?

I'm not sure what this one is? Is this a image service without sizes?

Can we steal some of the text from this and introduce sizes here?

https://gist.github.com/tomcrane/8b5ba6049dc86a722632

Allow the client more flexibility on choosing a thumbnail which fits into their interface.

I think if the client has to upscale the image its not an issue with processing it just doesn't look very good. I can't find a good example but if its upscaled too much it can introduce artefacts and looks pixelated.

I think it might be useful to keep repeating that "if they client requires a bigger thumbnail" as the reason rather than just a different size so that we can mention its more efficient to downsize an image than request the perfect size.