Hi @atiro,

I wasn't sure if full/ was absolutely necessary. It would be quite a large change to support it efficiently, so I was hoping it was optional!

A quick and drity hack to add this would be to simply build the 1/2, 1/4, 1/8 size images in memory, then write them all at the end. This would push up memory use a lot, but it would be easy, and fairly quick. Perhaps that would be enough for now.

That sounds good @jcupitt , I have to admit it's a struggle to get my head round the sizes/tiles calculations in the info.json. (oh, and hello from over the road)

/full/max/ is necessary, but the sizes property demonstrated in my example ^^ is not.

And .../full/max/0/default.jpg could just be the source image at its actual size (or maximum supported size) converted to JPEG.

Thanks @tomcrane, that sounds very simple to add as a post-processing step.

This is too late now for 8.9 (we're in feature freeze), let's revisit this for 8.10.

(oh, and hello from over the road)

I am intrigued @atiro ! Which road is this?

Only the road with the best art museum in the city on (and some other museums that are apparently also popular). Come over for a coffee and a chat when/if you have a free moment.

You're at the V&A? I used to know the head of photographic, James something, I expect he's moved on.

The NG is obviously the best art museum in the city! Tsh.

Hi @jcupitt,
I've been helping with adding IIIF support to sharp, but we've run into an issue (seemingly with libvips): lovell/sharp#2098 (comment)
I think it's possibly related to your comment above?

Hi @edsilv, would you mind making a test case to show the problem?

@jcupitt sorry for the delay on this! I'll aim to get it done asap :-)

@jcupitt sorry for the delay on this! I'll aim to get it done asap :-)

I have a test image for this if it helps;
1328400.jpg
https://app.box.com/s/r8p1xv0ffc7l1zlph3761be81raslvv2
( It is an export of the Eyes East towards Europe https://www.davidrumsey.com/luna/servlet/s/2ti74w )

vipsheader 13284000.jpg
13284000.jpg: 11653x7737 uchar, 3 bands, srgb, jpegload

vips --version
vips-8.10.0-Sat Jun 6 13:46:15 UTC 2020

vips dzsave 13284000.jpg test --layout iiif

tail test/info.json

        4,
        8,
        16
      ],
      "width": 512
    }
  ],
  "width": 11654,
  "height": 7738
}

generating the vips-properties.xml it has

<?xml version="1.0"?>
<image xmlns="http://www.vips.ecs.soton.ac.uk//dzsave" date="2020-06-09T09:36:44.799753Z" version="8.10.0">
  <properties>
    <property>
      <name>width</name>
      <value type="gint">11653</value>
    </property>
    <property>
      <name>height</name>
      <value type="gint">7737</value>
    </property>

Any news on this issue?
I would like to use this feature, currently I'm planning to get around it by just adding the file myself in a way suggested by @tomcrane here

But it's my understanding that the actual URL depends on the version of the IIIF Image API, for version 2 it seems to be 'full/full/0/default.jpg' and for version 3 'full/max/0/default.jpg'. Since dzsave creates version 2 manifests by default, the suggestion from the linked comment seems to be wrong.

Since I'm currently building libvips by myself to get the fix for #1818, I would be able to test the suggested quick fix if it can be supplied as a patch or PR.

Hi @cmahnke, I'm horribly busy at the moment. I might get some time to work on this in December.

Hi @cmahnke, I'm horribly busy at the moment. I might get some time to work on this in December.

Thanks, it's not urgent at all on my side, I've just added the the needed mkdir -p $TARGET/full/full/0/ and cp $IMAGE $TARGET/full/full/0/default.jpg to my wrapper script.

Anyways, maybe it's a starting point to add a parameter for the requested IIIF manifest version. That would probably a change big enough to wait for the next release cycle, as you pointed out here.