search

ruven / iipsrv

iipsrv is an advanced high-performance feature-rich image server for web-based streamed viewing and zooming of ultra high-resolution images.
https://iipimage.sourceforge.io
GNU General Public License v3.0
292 stars 115 forks source link

ROT bug on tile #182

Open sbarex opened 4 years ago

sbarex commented 4 years ago

When I request a tile with the ROT parameter to set the rotation the output is of a wrong tile only for the 180 degree rotation.

On JTL.cc, inside the send function (line 47) there is a code to remap the tile index to rotated coordinates. This code do nothing for 90 and 270 degree, but only for the 180 degree.

So, it is therefore necessary to clarify whether the tile index must always be remapped (and then complete the implementation for 90° and 270°) or nothing should be done (and therefore the code present for 180° should be removed).

See #184

ruven commented 4 years ago

I guess the question is is it useful to rotate the tile index when rotation is requested in this way? The advantage of doing this is that the client then doesn't have to handle rotation calculations or even know that a rotation has occurred. Any thoughts? How are you using the ROT command practically?

If we keep this remapping, the best solution would be to implement the tile index remapping for both 90° and 270° rather than disable it.

sbarex commented 4 years ago

I'm not sure it's the right choice. In my opinion, the index of a tile should always be the same regardless of the orientation of the image. However, I don't really know the protocol standard to decide which is the most coherent choice. And for the flipping? Do we have to remap the index on the basis of the flipped image or, as now, is it right to flip the tile without remaping his index before selecting it?

ruven commented 4 years ago

This kind of thing isn't really defined in the protocol standard. But, I'm inclined to favour remapping the index for both rotation and flipping. Otherwise, there isn't really any point in doing this server-side for tile requests.

Because if we have a client that is already rotation-capable and, therefore, is able to remap the tiles indices itself, it will presumably also be able to rotate the image tiles using basic CSS transforms, so the ROT parameter is arguably redundant in these cases. Server-side tile rotation and remapping allows less advanced clients that cannot handle rotation to be able to work correctly on rotated or flipped images transparently.