Skip to content

Try to import and add omero_figure app and static files - #323

Draft
will-moore wants to merge 1 commit into
JaneliaSciComp:mainfrom
will-moore:omero_figure_app
Draft

Try to import and add omero_figure app and static files#323
will-moore wants to merge 1 commit into
JaneliaSciComp:mainfrom
will-moore:omero_figure_app

Conversation

@will-moore

Copy link
Copy Markdown

Hi - I'm not really proposing to merge these changes in, but I just wanted to start a discussion...

I've been experimenting with using Fileglancer as a back-end to OMERO.figure, which currently involves a bunch of changes in a branch of OMERO.figure at will-moore/omero-figure#6 and the smaller changes in this PR.

This comes off the back of work in progress that adds OME-Zarr support to OMERO.figure. This frees up the app from using OMERO.web as the backend. It's possible to use OMERO.figure as a pure static app, but it's much nicer to have a server for:

  • Serving local OME-Zarr images
  • Running the Figure_To_Pdf.py script that converts from the figure (saved as JSON) to the PDF (or TIFF) figure
  • Opening and Saving figure.json files

I haven't implemented the Opening and saving of local figure.json files yet, but the other stuff is kinda working (see PR above for my current dev set-up).

The main issues I want to ask about...

  • In OMERO.web (based on Django) we can pip install omero-figure (which is not included with omero-web) then we set some config to omero_figure module to the list of Django apps. However, I'm not familiar with FastAPI and I couldn't work out if there's a way to do something equivalent? In the code below, I simply hard-code the import of omero_figure, but maybe there's a nicer way of doing this?
  • To run the Figure_To_Pdf.py, the figure app POSTs to http://127.0.0.1:7878/omero-figure/export (with the figure.json and a path/to/save/figure.pdf and a background task runs the script and saves the pdf. The frontend app keeps pinging the file path location (using Fileglancer endpoint http://127.0.0.1:7878/api/files/home?subpath=path/to/save/ until it sees the file appear. However, if something goes wrong with the export script and it throws an error, I don't have anyway for the frontend to know about it, or get the error message. Do you know if FastAPI might provide some way to handle this?

I'm really excited to allow non-OMERO users to use OMERO.figure for the first time (we may actually rename it to drop "OMERO") and I think that Fileglancer is going to be the best way for most of these users to adopt it. Would be great to hear what you think? Thanks.

@krokicki

krokicki commented Mar 6, 2026

Copy link
Copy Markdown
Member

I think this would be a great addition to Fileglancer!

We'll take a look to see it could be best integrated and get back to your questions soon.

By the way, I had just posted a question in the ome-zarr.js issues before seeing this. Nice timing!

@allison-truhlar

Copy link
Copy Markdown
Collaborator

Hi Will - Konrad and I chatted this morning about this, and are wondering if a more loosely coupled architecture based on the data links, along the lines of how we've integrated Neuroglancer and other viewers, would work for integrating Fileglancer and OMERO.figure. This would require deploying an OMERO.figure frontend and a minimal FastAPI backend separate from Fileglancer - potentially we could help with making the backend.
OMERO figure-fileglancer-integration_Page 1- 1773672498666
What are your thoughts on this? Would this work with OMERO.figure?

@will-moore

Copy link
Copy Markdown
Author

Hi, thanks for looking into this...

OK, I just asked copilot to create me a starter FastAPI app and it seems pretty minimal, so I'll have a play and see how I get along - I'll let you know if I need any pointers, and have a think about how to link to Fileglancer. My only possible concern with the separate deployments is that a user has to run 2 local servers instead of one, and CORS issues could prevent the Figure app from accessing the Fileglancer backend, but hopefully those won't be blockers,

Cheers,

@krokicki

Copy link
Copy Markdown
Member

Hi @will-moore, how are things going? Is there anything we can help with?

By the way, I wanted to let you know that we now have a programmatic API for Fileglancer, which can be used to link other websites and give them read/write file access through Fileglancer:
#409

@will-moore

Copy link
Copy Markdown
Author

Hi @krokicki - thanks for the ping...

I've not had time to look more into any FastAPI backend for figure yet. The next steps are to get a release out (the OME-Zarr support is currently only an rc release), then work on separating the figure JavaScript app from the omero-figure OMERO.web app, to create a new stand-alone figure repo. This may also contain the Figure_To_Pdf.py script.
Initially the workflow will be to download the figure.json file and run the conversion to Pdf locally.

Then I'll get back to looking at how to use some backend to make this process runnable from the browser.

The Fileglancer API needs for apps to be served from the same host; what would figure need to do to become a Fileglancer app?

Cheers!

@krokicki

Copy link
Copy Markdown
Member

If you are thinking of building a standalone webapp then a Fileglancer App is probably the easiest route for integration. It's very easy to set up, by adding a single metadata file to your repo: https://fileglancer-docs.janelia.org/authoring/overview/

Please let me know once you have the figure repo. I'd be happy to help with integrating it into Fileglancer.

@will-moore

Copy link
Copy Markdown
Author

Thanks, but those Fileglancer Apps look like backend python jobs with an automatically generated UI (form) for the job parameters? That's a bit different from a JavaScript webapp that needs to be hosted/served from somewhere?

@krokicki

Copy link
Copy Markdown
Member

Yes, we are deploying many webapps as Fileglancer Apps (Services). It starts a private copy of the webapp for the user, so you don't need to worry about implementing multiuser support, and state is easier to manage. I think it's a good way to deploy something like Figure, which has a Python backend (Figure_To_Pdf.py).

If Figure were a frontend-only app, we could deploy it more easily, with Fileglancer or any other HTTP server. That might also be worth considering. It's possible these days to rapidly port functionality from one language to another, so moving the PDF generation to the browser might be feasible using something like jsPDF. Another way to achieve this would be using WebAssembly to run the existing Python in the browser.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants