Fully support for IIIF info.json

[joesong168]

First of all, thank you for this wonder tool. It supports IIIF 3.0/2.0 quite well till now. However, now I found it necessary to use info.json in certain case where customization is needed, for instance, to support IIIF auth. Is it possible to give me flexibility in customizing info.json instead of generating it automatically. Also more diversified image support is needed, such as png and webp, as the image format in IIIF url.

[ruven]

For IIIF Auth, you need to add a "service" section to the info.json output. Perhaps we could add a startup parameter like IIIF_AUTH or something more generic like IIIF_EXTRA_INFO to allow you to inject arbitrary extra json into the info.json? Would that be enough?

For WebP and PNG, this is already available in the current Github source code and will be available in version 1.2, which will be released this autumn.

[joesong168]

Thanks for clarification. I pulled the latest version to try webp. However the result is unstable. That is some tiles display ok while others display in blank. I opened one of the blank image and found some information that might help to resolve.

RIFF�� WEBPVP8X

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.1-112"> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:tiff="http://ns.adobe.com/tiff/1.0/"> tiff:MakeCruse Scanner</tiff:Make> tiff:XResolution3500120/10000</tiff:XResolution> tiff:YResolution3500120/10000</tiff:YResolution> tiff:ResolutionUnit2</tiff:ResolutionUnit> tiff:ImageWidth5264</tiff:ImageWidth> tiff:ImageLength8944</tiff:ImageLength> tiff:BitsPerSample rdf:Seq rdf:li8</rdf:li> rdf:li8</rdf:li> rdf:li8</rdf:li> </rdf:Seq> </tiff:BitsPerSample> tiff:Compression1</tiff:Compression> tiff:PhotometricInterpretation2</tiff:PhotometricInterpretation> tiff:SamplesPerPixel3</tiff:SamplesPerPixel> tiff:PlanarConfiguration1</tiff:PlanarConfiguration> tiff:Orientation1</tiff:Orientation> tiff:NativeDigest256,257,258,259,262,274,277,284,530,531,282,283,296,301,318,319,529,532,306,270,271,272,305,315,33432;8EA33BA85FFF02A40B16AC67923A5569</tiff:NativeDigest> </rdf:Description> <rdf:Description rdf:about="" xmlns:xap="http://ns.adobe.com/xap/1.0/"> xap:CreateDate2007-12-26T19:09:17+08:00</xap:CreateDate> xap:ModifyDate2007-12-26T19:09:17+08:00</xap:ModifyDate> xap:MetadataDate2007-12-26T19:09:17+08:00</xap:MetadataDate> xap:CreatorToolAdobe Photoshop CS2 Macintosh</xap:CreatorTool> </rdf:Description> <rdf:Description rdf:about="" xmlns:xapMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:stRef="http://ns.adobe.com/xap/1.0/sType/ResourceRef#"> xapMM:DocumentIDuuid:6254BEA6B57811DCA56180161667F4FB</xapMM:DocumentID> xapMM:InstanceIDuuid:6254BEA7B57811DCA56180161667F4FB</xapMM:InstanceID> <xapMM:DerivedFrom rdf:parseType="Resource"> stRef:instanceIDuuid:684DBEDAB57511DCA56180161667F4FB</stRef:instanceID> stRef:documentIDuuid:684DBED9B57511DCA56180161667F4FB</stRef:documentID> </xapMM:DerivedFrom> </rdf:Description> <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> dc:formatimage/tiff</dc:format> dc:rights rdf:Alt <rdf:li xml:lang="x-default">Copyright (C) reserved</rdf:li> </rdf:Alt> </dc:rights> </rdf:Description> <rdf:Description rdf:about="" xmlns:exif="http://ns.adobe.com/exif/1.0/"> exif:ColorSpace-1</exif:ColorSpace> exif:PixelXDimension4798</exif:PixelXDimension> exif:PixelYDimension8481</exif:PixelYDimension> exif:NativeDigest36864,40960,40961,37121,37122,40962,40963,37510,40964,36867,36868,33434,33437,34850,34852,34855,34856,37377,37378,37379,37380,37381,37382,37383,37384,37385,37386,37396,41483,41484,41486,41487,41488,41492,41493,41495,41728,41729,41730,41985,41986,41987,41988,41989,41990,41991,41992,41993,41994,41995,41996,42016,0,2,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,20,22,23,24,25,26,27,28,30;705872E3A5F7B5D0B4B16C55498E7449</exif:NativeDigest> </rdf:Description> <rdf:Description rdf:about="" xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"> photoshop:ColorMode4</photoshop:ColorMode> photoshop:ICCProfileARTRON_ART_070405_300_FZ</photoshop:ICCProfile> photoshop:History/ </rdf:Description> </rdf:RDF> </x:xmpmeta>

[joesong168]

default.webp.zip This is the image itself.

[joesong168]

https://user-images.githubusercontent.com/10493864/185753948-9d90fb96-b458-48b4-8a5f-47b42da794ca.mp4

[ruven]

Can you send me the TIFF image that you are using with iipsrv? And also give me an example of a tile request URL being sent to iipsrv that returns a buggy webp image.

[joesong168]

https://localhost/i/3/9a0710ad4dc651a3a02e5d20f9e1f9c5/5120,1024,712,1024/356,512/0/default.webp 9a0710ad4dc651a3a02e5d20f9e1f9c5.zip It's a pyramid tiff in webp.

[ruven]

This works fine on my machine with the request: 9a0710ad4dc651a3a02e5d20f9e1f9c5/5120,1024,712,1024/356,512/0/default.webp

What does it say in your iipsrv log when you open this URL?

By the way, you don't need to compress your TIFF files with WebP to be able to output in webp format. iipsrv transcodes from any TIFF compression to any of the supported output formats.

[joesong168]

TileManager getRegion :: Total tiles in image: 6x5 tiles TileManager getRegion :: Tile start: 5,1 with offset: 0,0 TileManager getRegion :: Tile end: 5,1 TileManager :: Cache miss for resolution: 3, tile: 11, compression: UNCOMPRESSED, quality: 85 TileManager :: Cache size: 19 tiles, 9.89623 MB TileManager :: Tile decoding time: 13054 microseconds TileManager :: Cropping tile TileManager :: Edge tile: Base size: 512x512: This tile: 356x512 TileManager :: Tile cache insertion time: 792 microseconds TileManager :: Total tile access time: 14346 microseconds TileManager getRegion :: Tile access time 14590 microseconds for tile 11 at resolution 3 TileManager getRegion :: destination tile width: 356, tile height: 512 CVT :: Region decoding time: 15114 microseconds CVT :: Setting physical resolution of this view to 150 x 150 pixels/inch CVT :: ICC profile with size 961644 bytes is too large: Not embedding CVT :: Embedding XMP metadata with size 15860 bytes CVT :: About to compress strip with height 128 CVT :: Compressed data strip length is 13117 CVT :: About to compress strip with height 128 CVT :: Compressed data strip length is 13117 CVT :: About to compress strip with height 128 CVT :: Compressed data strip length is 13117 CVT :: About to compress strip with height 128 CVT :: Compressed data strip length is 13117 CVT :: Total command time 24642 microseconds IIIF :: Total command time 178974 microseconds Total Request Time: 180722 microseconds image closed and deleted Server count is 109

[joesong168]

Thanks for your advice. Just wondering is there some performance penalty if the tif is encoded in format other than webp, but output as webp?

[ruven]

The log output looks like it's correctly outputting the WebP file. If you open your URL https://localhost/i/3/9a0710ad4dc651a3a02e5d20f9e1f9c5/5120,1024,712,1024/356,512/0/default.webp directly in a browser, does it work? If not, perhaps you have an old version of libwebp? What OS and version is the server running on?

Just wondering is there some performance penalty if the tif is encoded in format other than webp, but output as webp?

iipsrv will decode from whatever compression you have used, then re-encode into the requested format, so there is no performance advantage in your scenario. You do, on the other hand, get a smaller TIFF file when using WebP compression. If you want maximum speed, use uncompressed tiled pyramid TIFF, though this will result in much larger files.

[joesong168]

Thanks for detailed explanation. You are correct that the problem lies in libwebp or chrome side. I will investigate further.

[joesong168]

Can you open this IIP. generated webp from your computer? I failed to display it in both my PC and mac. Uploading 709294bbc45a494dfdec23c031fa5488.webp.zip…

[ruven]

You didn't properly upload your webp file ...

[joesong168]

Sorry, I couldn't the image any more. Thanks a lot for all the following up till now.

[joesong168]

Is it possible to add a parameter to control whether it is http or https in 'id' field of IIIF info.json. I saw the BASE_URL param, but it is only enough when mapping happened in rewrite rule, such as rewrite "^/i/2/(?.{1})(?.{3})(?.*)(?jpg|webp|json)$" /fcgi-bin/iipsrv_2.fcgi?IIIF=$c1%2f$c1$c3%2f$c1$c3$cn$ext;"

[ruven]

BASE_URL allows you to define a static Host URL for the IIIF info.json id field. This works irrespective of whether you do URL rewriting or not. It is, however, fixed for all requests, so won't work if you want to set this on a per-request basis.

[ahankinson]

X-IIIF-ID will, though.

https://github.com/ruven/iipsrv/blob/ef1ce8ad7d9beaec93cbb67026890d6e593c489f/src/IIIF.cc#L197

If you set this on your frontend (where your request is coming from) and then set it as a header to your IIP server, it will pick up on it and pass it through.

So if you request:

https://example.com/images/12345/

And then proxy this to IIP as:

http://images.internal/iiprv.fcgi?IIIF=/images/12345/ but set X-IIIF-ID: https://example.com/images/12345/ as a request header in the proxy request, then it should pass this through to the info.json manifest and the id value should be https://example.com/images/12345/

[joesong168]

Thanks for the reply. I used fastcgi paramter https on/off to fix it.

[ruven]

Thanks for the reply. I used fastcgi paramter https on/off to fix it.

Yes, if you're using Nginx, that would indeed be an elegant and simple way to do it!