It seems to be same issue than T118405/"ZoomViewer FCGI broken".
The webservice was restarted and that fixed the issue.
Maybe is it possible to restart the webservice again.
Best regards

Thank you to look into this.
Maybe a more stustenable solution would be preferable but if we have the possibility to purge on demand occasionally the cache for corrupted files in cache, it could help a lot. The main issue for now is that when there are corrupted files, there is no solution for users to fix it, except to report the problem, that, as you point, comes up regularly.

Hello,
It seems that there are many corrupted files in the cache :
http://zone47.com/crotos/lab/cropper/get.php?q=14619165
http://zone47.com/crotos/lab/cropper/get.php?q=Q1231009
http://zone47.com/crotos/lab/cropper/get.php?q=Q19939091
Actually almost all images I tested (the one that works http://zone47.com/crotos/lab/cropper/get.php?q=21013224 )
By the way, I made a public presention in March about IIIF on Wikimedia projects at IIIF Biblissima meeting in Paris: http://www.biblissima-condorcet.fr/en/indexation-iconographique-sur-projets-wikimedia-iiif . Luckily the service worked well at that time. Many would be very happy to do more, but the instabaility of the service is today unfortunately a major obstacle to the development of IIIF in Wikimedia.
I'm sorry to say that this recurrent issue is very annoying, especially that there is no solution for users to fix it. Although my technical skills are limited, I would be happy to help if I can do something.
Best regards

My bad, 600, stored in Wikidata, should be considered from 6th century by making centuries begin in x01.
But the issue is why is the last year of the century stored? When a date is specified only with a year, it's January the first which is stored, not December 31st. Furthemore the choice of this year could create issues on reuse as it happens on infoboxes in Wikipedia -FR,
For "6. century" having year 501 stored, instead of 600, should resolve the issue, whatever the choice of reuser to make centuries begin in 500 or 501.

An example reported today of consequence of this issue.
In Wikidata https://www.wikidata.org/wiki/Q336070 "6. century" is displayed but in French Wikipedia https://fr.wikipedia.org/wiki/M%C3%A9nandre_le_Protecteur on the infobox linked to Wikidata , "7. century" was displayed.

Hello @dschwen. That's reallly great.
Usually the service works fine. As you know better, sometimes it doesn't and the display is puzzled/grey images. This happened sometimes in cases where before it worked. And in those cases, the service displayed the same thing until the cache has been deleted.
If I understand well, the new script will detect those cases and purge. What a confort! I must admit that when I was using the property 2677 on Wikidata, I had always the fear that it will not work well (maybe there is a process to avoid that?) and could stay like that for a moment. Now, it's completely different and very reassuring to know that this can be repaired.
Thanks you so much
Best regards

Oh thank you !
I made some tests and had succes. Just for one, it was broken and the problem is the same with Zoomviewer : https://tools.wmflabs.org/zoomviewer/index.php?f=Jacques-Louis%20David%2C%20The%20Coronation%20of%20Napoleon%20edit.jpg&flash=no
Thanks to this IIIF image API we can do very easily great things with values on Property P2677 in Wikidata. For example a SparQL query to search the representation of Jesus-Christ in different artworks with image fragment : http://tinyurl.com/yb8cjula . So yes this service is very useful and almost magic for those involved in iconographic indexation and art history.
Best regards

Yes JHeald the issue is on IIP backend ; saddly, it doesn't work anymore too for some files in Zoomviewer in Commons (example: https://tools.wmflabs.org/zoomviewer/index.php?f=Frederick%2C%20Prince%20of%20Wales%2C%20and%20his%20sisters%20by%20Philip%20Mercier.jpg&flash=no ). Yes, such features are already really great and have a major potiental for Wikimedia projects. For example, it will be really simpler and more practical to have for details in Wikipedia IIIF image fragments instead of separated image files, which curently could be very tedious to make. The issue is very mysterious for me and I hope that it could be fixed. Best regards

Something seems broken since today.
With the property P2627/relative position within image in Wikidata we can generate URL connecting to this tool. It's very usefull to get details of depicted elements in a image. Here is an example of use (and a cropper-tool to produce the data). All images of details are linked to this IIIF server. It's really great to have such opportuny for image annotation based on Wikidata. Thank you so much for it. Since today, for unknown reason, images don't always display or have puzzled display. Maybe it could be fixed. Best regards