Serve IIIF images with Elixir plug instead of relying on Cantaloupe as an extra service #305
Conversation
This was a hack to handle the artificially downscaled images used for testopolis in development.
The IIIF Image Plug works on the raw files for the time being.
If the user's preference from localStorage is read, the server needs to be informed about that state in order to correctly display the layer selection.
This reverts commit db0053b.
The IIIF endpoint is now part of the Elixir project itself via `:iiif_image_plug`.
These are not set by Phoenix while running tests, so the image plug returns the default values.
.github/workflows/publication.yml
Outdated
| - name: Sleep to await CouchDB startup | ||
| run: sleep 15s | ||
| - name: Restore dependencies cache | ||
| uses: actions/cache@v3 |
There was a problem hiding this comment.
actions/cache@v4 is the most current one, if there's no reason not to, might as well use that?
.github/workflows/server.yml
Outdated
| - name: Sleep to await CouchDB startup | ||
| run: sleep 15s | ||
| - name: Restore dependencies cache | ||
| uses: actions/cache@v3 |
| ]; | ||
|
|
||
| const pathTemplate = `/api/image/tile/${projectName}/${info.uuid}/{z}/{x}/{y}`; | ||
| const pathTemplate = `/api/image/tile/${projectName}/${info.uuid}/{z}/{y}/{x}`; |
There was a problem hiding this comment.
okay, just a question: I am used to x,y,z as the order in GIS contexts - but maybe I am thinking of something else here?
There was a problem hiding this comment.
I used a map tiling preprocesser that is provided by libvips out of the box. Because it is following the same pattern as google maps, the resulting directory structure is basically z/y/x now, instead of z/x/y.
| base_path = FileService.get_map_tiles_path(name) | ||
|
|
||
| Plug.Conn.send_file(conn, 200, "#{base_path}/#{uuid}/#{z}/#{x}/#{y}.png") | ||
| Plug.Conn.send_file(conn, 200, "#{base_path}/#{uuid}/#{z}/#{x}/#{y}.webp") |
There was a problem hiding this comment.
why is the order zxy different here?
There was a problem hiding this comment.
You are right, these request parameter variables should be renamed to z,y,x.
There was a problem hiding this comment.
I reverted to the old API with edf41ef and instead switch the parameters when constructing the file path.
The images in the seed project were initially scaled down in order to not increase the repository size too much. Because of the change to the libvips preprocessing pipeline, the scaled down images now introduce errors because the geometry and other metadata in the database does not match the actual file width/height.
Instead of changing the API, we just switch the file path construction.
One minor fix for the document view map snuck into the branch. 🙄