Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fully support for IIIF info.json #234

Open
joesong168 opened this issue Aug 18, 2022 · 19 comments
Open

Fully support for IIIF info.json #234

joesong168 opened this issue Aug 18, 2022 · 19 comments

Comments

@joesong168
Copy link

joesong168 commented Aug 18, 2022

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
Copy link
Owner

ruven commented Aug 19, 2022

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
Copy link
Author

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
Copy link
Author

default.webp.zip
This is the image itself.

@joesong168
Copy link
Author

2022-08-20_23-11-12.mp4

@ruven
Copy link
Owner

ruven commented Aug 20, 2022

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
Copy link
Author

@ruven
Copy link
Owner

ruven commented Aug 21, 2022

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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

ruven commented Aug 21, 2022

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
Copy link
Author

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

@joesong168
Copy link
Author

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
Copy link
Owner

ruven commented Sep 2, 2022

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

@joesong168
Copy link
Author

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

@joesong168
Copy link
Author

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
Copy link
Owner

ruven commented Jan 31, 2023

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
Copy link
Contributor

ahankinson commented Jan 31, 2023

X-IIIF-ID will, though.

string iiif_id = session->headers["HTTP_X_IIIF_ID"].empty() ? escapedFilename : session->headers["HTTP_X_IIIF_ID"];

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
Copy link
Author

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

@ruven
Copy link
Owner

ruven commented Feb 3, 2023

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants