Mirador shows no image after using of the mirador-image-tools

[ChrisBethgster]

For reproducing - use the mirador-image-tools.netlify.app instance.

• open for example the following manifest: https://iiif.europeana.eu/presentation/9200396/BibliographicResource_3000118436165/manifest
• use the image tools
  • click "Show image tools"
  • use "Invert colors" for example --> the image is correct inverted
• enable "Thumbnails" on bottom
• click on a thumbnail (WITHOUT scrolling)
• use the image tools -> it works also
• use the scrollbar for selecting a new thumbnail
• try to use image tools
  • use "Invert colors" for example -> no image is visible in mirador
    
• select an other thumbnail -> also no image is shown

[sete-arch]

Hi,

I encountered the same problem.

• use the image tools
  click "Show image tools"
  use "Invert colors" for example --> the image is correct inverted
• click on the button "next"
• use the image tools -> it works also
• click on the button "next" twice (or more)
• try to use image tools -> doesn't work, no visible image

Is there any progress on this issue ?

Thank you

[camillevilla]

Thank you for posting this issue! We were able to recreate this issue and started investigating at community call on 10/28.

Notes:

• this affects any manifest with multiple canvases

[Aylambo]

Hey there,
Is there any fix for that issue?
I'm encountering similar situations to the ones described above.
Thanks :)

[Marcel-Tronco]

Hi, the problem is still there.
For any developers interested in this, my browser console indicated that this is because of a rotation value turning NaN.

Unsupported rotation: NaN [index.html:13441:25]<...> index.html)
    overrideMethod <...>/index.html:13441
    onUpdateViewport <...>/main.js:85
    getHandler <...>/2.main.js:6
    raiseEvent <...>/2.main.js:6
    (Async: FrameRequestCallback)
/*...*/

Best

[Marcel-Tronco]

I fiddled around with this a while longer and tried to reproduce the bug in mirador dev setup to look at it a little closer, i.e. having setup of the mirador repo developing it with webpack serve (using the start scripts) and using the plugin as a preconfigured one there. In this setup the problem does not arise.

I don't know what this means exactly, but made me think of some build/dependency issues as the source of the bug.

Best

[Marcel-Tronco]

I had some time again to look into it. Concerning the last comment testing a little bit longer showed, problems in the other setup are the same.

Yet with the help of react dev tools in the browser I saw that the viewerConfig seems to be (part) of the problem.

Leafing through a manifest in the viewer there are several points, when after changing the page the viewerConfig Prop of the OSD-viewer element and the image tools element becomes null. Now if we continue leafing without changing settings in the image tools for the next page this might reset to the old config we saw a page before eventually and never is known, as it doesn't have effects.

If in such a situation we change a setting in the image tools the viewerConfig gets set with only the image tool config part and breaks the viewer, now leafing forward or backward, doesn't change the config leaving it broken.

[Marcel-Tronco]

Tracked the problem a little further. It seems to be related to the way the viewer handles state in the reducers. Normally the default values for the viewerConfig come from a updateViewport-Function. During a page change (e.g. clicking previous/next page buttons) a setCanvas action first resets the config, without the "defaults", only in another state change action triggered by the updateViewport-Func. the defaults are set. In some circumstances the order is changed and there is not no viewport update after the setCanvas action and the viewerConfig stays null, leading to the problem described above.

It's only reproducible if a plugin is installed. I tried it on the 3.x release branch of the mirador viewer.

Cheers...

[DiegoPino]

We are having the same problem. Not sure if the open pull for 4.0 fixes these issues, but probably we want to tackle a fix as a community? If not sadly this plugin is not very useful and leads to user frustration

[lutzhelm]

I just tested the mirador4-compat-clean branch; the problem still exists there, but after that I tried installing Mirador locally with the latest commit ProjectMirador/mirador@c2943e6 from the master branch, et voilà, the changes that are necessary to get it to run made the problem disappear. (Which isn't that surprising because the react-sizeme-dependency was replaced with the ResizeObserver browser API via ProjectMirador/mirador#3959)

If anyone wants to reproduce this:

• checkout mirador, run
  • npm install
  • npm run prepublishOnly
  • npm pack
• checkout the mirador4-compat-clean branch of mirador-image-tools, run npm install ../mirador/mirador-4.0.0-alpha.2.tgz (adjusted for the actual path)
• replace this line with import { withSize } from 'mirador/dist/es/src/extend/withSize';
• run npm run start and try to reproduce the issue

[DiegoPino]

@lutzhelm great. Can confirm, the resizeObserver actually does the trick.At least for me, changing the line in this plugin was not needed, just adding react-sizeme as a dependency. Thanks

[fstoe]

I tried both approaches and found that they fix the unshown image bug. However they introduce a new one as the original sizing is no longer working (size.width always remains undefined)

In a pr on the mirador4-compat-clean branch, I refactored the component to handle the withSize HOC from Mirador.

[DiegoPino]

@fstoe thanks. this is great!