Repeatability of scale factor/width in tiles

[azaroth42]

If a single scale is in multiple scale_factors lists, what does that mean and what should the client do with it? Or should it be disallowed? Same with width/height.

To me:

• Width [& Height] MUST be unique in the tiles list. The intent is to allow different width/height combinations at different scale factors.
• The scale factors SHOULD be unique across all of the lists. If the same scale factor appears with two different width/heights, then the client can just pick one. Likely that will be random, but maybe there's some intelligence that could be implemented.

[jpstroop]

So the case you're talking about is, e.g.

"tiles" : [
    {"width" : 512, "scale_factors" : [1,2,4]}
    {"width" : 256, "scale_factors" : [4,8,16]}
  ]

Where scale factor 4 is potentially problematic, correct?

• Width [& Height] MUST be unique in the tiles list. The intent is to allow different width/height combinations at different scale factors.

:+1:, absolutely. The combination of width and height must be unique, just to nitpick.

• The scale factors SHOULD be unique across all of the lists. If the same scale factor appears with two different width/heights, then the client can just pick one. Likely that will be random, but maybe there's some intelligence that could be implemented.

Sure. In Jp2-land this doesn't even seem possible. You either have tiles (and thus one consistent size/scale) or precincts. When compressing with precincts with Kakadu:

   Cprecincts[:<TC>]={<int>,<int>},...
       Precinct dimensions (must be powers of 2). Multiple records may be
       supplied, in which case the first record refers to the highest
       resolution level and subsequent records to lower resolution levels. The
       last specified record is used for any remaining lower resolution
       levels.Inside each record, vertical coordinates appear first.

and with OpenJPEG:

Precinct size : -c [128,128],[128,128],...
This option offers the possibility to define the size of the precincts for at each resolution (the values specified must be power of 2). Multiple recorde may be supplied, in which case the first record refers to the highest resolution level and subsequent records to lower resolution levels. The last specified record is right-shifted for each remaining lower resolution levels. The default dimension is 215 x 215 at each resolution.

(Eerily similar...)

I know JP2 isn't our only use case, but allowing the listing of multiple tile sizes was inspired by the precinct problem. I'm not sure we need to say anything at all about this.

[azaroth42]

Yes, re 4 being the problem child, and the combination being unique.

Agreed in JP2 it's not possible, but perhaps we get some pathological types (ahem, @azaroth42) who don't use JP2 and like pushing the boundaries. I'd prefer to be explicit here to make it easier for client developers to know what they can expect from servers.

[jpstroop]

Just checked the JP2 spec:

Where the "[en]coding style" for precinct size is defined it says:

If Scod or Scoc = xxxx xxx0, this parameter is not present; otherwise this indicates precinct width and height. The first parameter (8 bits) corresponds to the N L LL sub-band. Each successive parameter corresponds to each successive resolution level in order.

So there would be no way to encode a JP2 with multiple precinct sizes at the same scale.

[jpstroop]

Good point, better to not leave a developer wondering (you're evidence of what happens :smile: ).

I can add this and kill viewing_hint in the same PR if that feels OK to you.

[azaroth42]

Yup, sounds good! Just got multiple tile sizes working in Open Seadragon, requesting 512 tiles at SF 1, and 256 tiles at SF 2 and 4.

Next up is to fix the request syntax to always use explicit h,w

On Thu, Jul 24, 2014 at 9:57 AM, Jon Stroop notifications@github.com wrote:

Good point, better to not leave a developer wondering (you're evidence of what happens [image: :smile:] ).

I can add this and kill viewing_hint in the same PR if that feels OK to you.

— Reply to this email directly or view it on GitHub https://github.com/IIIF/iiif.io/issues/300#issuecomment-50046409.

Rob Sanderson Technology Collaboration Facilitator Digital Library Systems and Services Stanford, CA 94305

[jpstroop]

Awesome! Are we doing explicit w,h? It was that way before, but we changed to w, so that level1 compliance was enough.

maybe w, if level1, w,h if level2?

[azaroth42]

I was looking at the canonical URI ... filing it as a new issue :S

[zimeon]

Just recording this thought in the ticket: Why should there be just one instance of a particular scale_factor value when a server (not based on JP2) might support more? to me the answer is that this is a SHOULD because even in a system where arbitrary tiles can be generated, we are trying to give a clear set of hints to the client as to which one to use. Without adding more information how would it pick between multiple tile sizes for a given scale factor?

(Actually, I think that optimal tile size is related to client window size so a client could perhaps do this but we haven't really seen the need yet.)