Questions on IIF Image API Validator

Mark Patton

unread,

Dec 10, 2014, 10:56:12 AM12/10/14

to iiif-d...@googlegroups.com

All,

I am refactoring my previous work at supporting the IIIF Image API to support version 2 and have some nicer abstractions. The only implementation uses the FSI image server but other image servers could be supported. The source is available at https://github.com/jhu-digital-manuscripts/rosa2/tree/master/rosa-iiif for those interested.

The Image API validator is well done and a great help to those working on implementations, but I have a few questions.

The test 'Forward slash gives 404' hits http://rosetest.library.jhu.edu/iiif-image/a/b/full/full/0/default.jpg and expects to get a 404. But reading the spec, 400 seems more appropriate. Given the number of slashes in the path, the request is not an image operation, not an image info request, and not an image uri. Therefore the request itself is malformed. A 404 seems like it should be reserved for a request that specifies a non-existent image.

The mirroring test looks at http://rosetest.library.jhu.edu/iiif-image/67352ccc-d1b0-11e1-89ae-279075081939/full/full/!0/default.jpg which by visual inspection at least looks correct to me. The test fails expecting a 1000,1000 image.

The id_squares test fails saying only 'Message: error'. I took a look at the underlying python code for the test, it tests squares of color. But for some reason there is an internal error.

The gray test fails saying expected: 0, got: 1. Glancing at the python test code, I can't quite tell what it is testing. The actual returned image http://rosetest.library.jhu.edu/iiif-image/67352ccc-d1b0-11e1-89ae-279075081939/full/full/0/gray.jpg looks ok to me.

Here is the full url I am using to run tests: http://iiif.io/api/image/validator/results.html?server=http%3A%2F%2Frosetest.library.jhu.edu%2F&prefix=%2Fiiif-image&identifier=67352ccc-d1b0-11e1-89ae-279075081939&version=2.0&level=-1&id_basic=on&id_squares=on&info_json=on&id_error_unescaped=on&id_error_escapedslash=on&id_error_random=on&id_escaped=on&region_error_random=on&region_pixels=on&size_ch=on&size_region=on&size_error_random=on&size_wc=on&size_percent=on&size_bwh=on&size_wh=on&rot_error_random=on&rot_mirror=on&quality_error_random=on&quality_grey=on&quality_color=on&format_jpg=on&format_error_random=on&jsonld=on&cors=on&baseurl_redirect=on

Any insight would be appreciated.

Thanks,

Mark

Robert Sanderson

unread,

Dec 10, 2014, 6:55:54 PM12/10/14

to iiif-d...@googlegroups.com

Hi Mark,

--
-- 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.

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

Robert Sanderson

unread,

Dec 10, 2014, 11:39:45 PM12/10/14

to iiif-d...@googlegroups.com

Hi Mark,

(and apologies for previous empty message)

On Wed, Dec 10, 2014 at 7:56 AM, Mark Patton <mark....@gmail.com> wrote:
The test 'Forward slash gives 404' hits http://rosetest.library.jhu.edu/iiif-image/a/b/full/full/0/default.jpg and expects to get a 404. But reading the spec, 400 seems more appropriate. Given the number of slashes in the path, the request is not an image operation, not an image info request, and not an image uri. Therefore the request itself is malformed. A 404 seems like it should be reserved for a request that specifies a non-existent image.

It's impossible to determine where the prefix ends and the image identifier starts. The URL being tested could have the prefix /iiif-image/a/ and identifier of b, rather than a prefix of /iiif-image/ and an identifier of a/b.

So the request might not be malformed ... or rather it's impossible to know if it is or not. Hence we opted for 404, as that's what a server is likely to produce by default when it gets a path it doesn't know how to process. I agree that 400 would not be bad either (at least it's an error!).

However, all that said ... the validator *should* be requesting a%2Fb not a/b. In other words, the / should be escaped in the request. The test code is here: https://github.com/IIIF/image-api/blob/master/implementations/validator/tests/id_error_escapedslash.py

It could be a bug in the validator if it really is sending it unescaped.

The mirroring test looks at http://rosetest.library.jhu.edu/iiif-image/67352ccc-d1b0-11e1-89ae-279075081939/full/full/!0/default.jpg which by visual inspection at least looks correct to me. The test fails expecting a 1000,1000 image.

Yes, the source image is 1000,1000 so full should be that. I'm more surprised that all the other tests don't fail!

The info.json is correct though -- height and width of 1000 -- so it is an error to not return 1000,1000 when asked for full. Currently I get 400 x 300 image.

The id_squares test fails saying only 'Message: error'. I took a look at the underlying python code for the test, it tests squares of color. But for some reason there is an internal error.

Investigating but probably it assumes that there's 1000,1000 worth of pixels to test and is reading off the end.

The gray test fails saying expected: 0, got: 1. Glancing at the python test code, I can't quite tell what it is testing. The actual returned image http://rosetest.library.jhu.edu/iiif-image/67352ccc-d1b0-11e1-89ae-279075081939/full/full/0/gray.jpg looks ok to me.

It checks for every different color if the R , G , B are within 5 of each other. So 0,0,0 is fine, and some fudge factor to make 0,5,0 okay too ... but not 0,0,10.

Then it assumes 1000,1000 ... and hence the number of pixels it needs to have as gray is probably higher than the total number of pixels received.

Hope that helps!

Rob

Mark Patton

unread,

Dec 12, 2014, 11:15:07 AM12/12/14

to iiif-d...@googlegroups.com

Rob,

Thanks for the response! Most of the errors were caused by a typo preventing a full image request from getting the right size. (It would be good to add some size sanity checks to all the tests to catch this.)

The other issue with the slash actually seems to be a bug in the test. It's requesting http://rosetest.library.jhu.edu/iiif-image/a/b/full/full/0/default.jpg instead of http://rosetest.library.jhu.edu/iiif-image/a%2fb/full/full/0/default.jpg

As for the 400 verses 404, in the case of a wrong number of / like http://rosetest.library.jhu.edu/iiif-image/a/b/full/full/0/default.jpg, both the client and iiif implementation know the iiif prefix so they should be able to handle the case and return a 400. But it's a small detail.