Overriding the default manifest

Hi,
When uploading images to InvenioRDM record, it automatically create a manifiest IIIF on this link /api/iiif/record:/manifest

The manifest should include hocr file for each page. The pyramid images are served from cantaloupe server. So user upload pdf, and hocr → invenioRDM generate the custom manifest . When user visit the record with the pdf and hocr, mirador viewer read the manifest and server the content.

What is the recommend way to override this default manifest to show custom manifest ?

This is a preliminary diagram show how the viewer interact with other servers:

Explanation of the Flow:

  1. User Accesses Mirador: The user navigates their browser to the URL where the Mirador viewer is hosted.
  2. Web Server Serves Mirador: A standard web server (like Nginx, Apache, or even a simple Python server for local development) serves the HTML, JavaScript, and CSS files that make up the Mirador application. This typically happens over HTTPS (port 443) or HTTP (port 80), or a development port (like 8000, 8080, etc.).
  3. Mirador Loads & Requests Manifest: The Mirador JavaScript application loads in the user’s browser. Based on its configuration, it requests a IIIF Manifest file (a JSON document). This manifest describes the digital object, its structure, and importantly, the location (Image Service Base URI) of the images. This request usually goes back to the web server (or potentially another server) over HTTPS/HTTP.
  4. Web Server Serves Manifest: The web server provides the requested IIIF Manifest JSON file.
  5. Mirador Parses Manifest: Mirador reads the manifest to understand the object and finds the base URL for the IIIF Image Service, which points to the Cantaloupe server.
  6. Mirador Requests Image Tile: As the user interacts with the viewer (e.g., zooming, panning), Mirador constructs IIIF Image API requests for specific regions, sizes, and rotations of the image. These requests are sent directly from the user’s browser to the Cantaloupe server’s IIIF endpoint, likely using HTTPS (based on your recent fixes) on Cantaloupe’s configured port (often 8182 by default).
  7. Cantaloupe Reads Source Image: Cantaloupe receives the IIIF request, determines which source image is needed and the specific region/parameters requested. It then accesses the original high-resolution image file from its configured source (Image Store - typically the filesystem).
  8. Image Store Provides Data: The filesystem (or other storage backend) provides the raw image data to Cantaloupe.
  9. Cantaloupe Processes & Serves Tile: Cantaloupe processes the raw image data according to the IIIF parameters (cropping, resizing, rotating, changing quality/format) and sends the resulting image tile back to the Mirador application in the user’s browser.
  10. Mirador Displays Tile: Mirador receives the image tile and displays it in the correct position within the viewer interface.

This cycle (steps 6-10) repeats rapidly as the user interacts with the viewer, allowing for smooth panning and zooming of high-resolution images. Your recent work focused on ensuring the communication between the browser (Mirador) and Cantaloupe (step 6 & 9) uses HTTPS correctly, likely resolving browser security warnings.