Export to Qupath with images imported directly

[GuillaumeLeGoc]

• ABBA version: 0.5.5
• ABBA Python version: 0.2
• Python version: 3.7
• Operating System: Windows 10

This is not really an issue since I'm completely responsible for what happened since it is recommended throughout the documentation to use a Qupath project, but still might be a source of improvement of quality of life.

Description (short version)

I imported images directly into ABBA, without Qupath project. Now I regret it and wanted a way to link a Qupath project afterwards.

Description (long version, use-case)

I used a Python notebook to initiate a registration process with ABBA :

• I imported images with :

images_list = [os.path.normpath(os.path.join(images_dir, file)) for file in os.listdir(images_dir) if file.endswith(images_ext)]
aligner.import_from_files(filepaths=images_list, z_location=6, z_increment=60/1000)

• I launched ABBA in graphical mode from the notebook, performed some reordering and color balance in ImageJ GUI
• From the notebook, I performed some registration (DeepSlice, affine, spline)
• I performed some more manual tweaks from the ImageJ GUI
• Once I was satisfied, I saved the ABBA state file.

Then, from a different notebook, I'm able to load the state file in headless mode, to have access to the mp object that contains what I need to transform coordinates of cells segmented elsewhere into the AllenBrain with mp.getSlices().get(Z).getSlicePixToCCFRealTransform().inverse().apply(coord_in_image, coord_in_atlas), and I can count cells in different regions and so on, and this is great !

Actual description of the problem

But (of course there's a but), I wanted to quickly assess the quality of the registration, and Qupath was a good tool to do that (the navigation is far better than within ABBA), and wanted to export the registration to Qupath, before remembering I did not import a Qupath project but images directly, so I basically can't export that for easy regions viewing in Qupath.

From what I understood, the qproj file is a json file containing all relevant metadata of the actual data (location, size, pyramid structure, channels, etc.), and that ABBA mainly uses the location of the files and of the Qupath project to perform a smart export, putting exported registration files in the right place within the Qupath project. All the groovy scripts provided by you and others to import regions, convert coordinates of detections in ABBA etc. relies on it afterwards, so I'm kind of stuck if I want to use Qupath at all.

Proposed workaround/fix/enhancement

Redo the registration from a Qupath project

Obviously I'd like to avoid that, but I'll definitely remember that in the future.

Manual editing of xml/json ABBA files

I thought of, from this post that dissects xml, json and qproj files used by ABBA, to manually edit those files to add a Qupath project in the header, to lure ABBA into thinking the data came from a Qupath project, but I did not feel confident it would be easy nor if it would work at all since I don't really know what's happening behind the curtains.

Be able to link an ABBA state to a Qupath project afterwards

This could be done by adding an option to load an ABBA state on top, after importing an un-processed Qupath project, but I don't know if it is doable.

Prompt the user for qupath project directory when exporting to ABBA if none exists

This seems the most realistic solution. From the ABBA GUI, when performing "Export > Export registration to Qupath project", if none was set up, prompt the user for the path to the qproj file, and just use it to read in which directories the registration files should be exported to (without updating the ABBA state file in itself). This would also suggest to add an argument to this python function to specify the qproj file.

In any case, this should be flagged as minor, not important and low-priority.
Thank you for your work !

Cheers

[NicoKiaru]

Thanks for the clear and complete post!

Redo the registration from a Qupath project

On this side, I could add a warning message ' you may regret your decision later' ;-)

Manual editing of xml/json ABBA files
Be able to link an ABBA state to a Qupath project afterwards

The post you mention on the forum should be obsolete by now. Some work has been done that should diminish this sort of issues (point 4 of https://forum.image.sc/t/abba-aligning-big-brains-and-atlases-v0-5-3-released/80732). The way ABBA currently works is the following: the source of an abba slice is identified (uniquely) by a qupath project uri and the unique entry id set by QuPath.

However it does not mean that what you suggest is easy.

• What should happen if an abba state contains an image which is not on the QuPath project ?
• What should happen if a QuPath project contains a duplicated entry ?

The synchronization between a QuPath project and an ABBA will be problematic at some point.

Prompt the user for qupath project directory when exporting to ABBA if none exists

I think it's doable. But it's some work. This means that ABBA should have a basic QuPath project serializer (currently it only has a deserializer). But it could become a liability on the long term, so I'll probably not go for it.

Briefly: currently ABBA translate various ImageServer from QuPath, it's the structure that is used by QuPath to define a dataset. It can be an ImageServer that reads a Bio-Formats image, an OpenSlide image, and ImageJ image. And there are derived ImageServer: an ImageServer that rotates another ImageServer, an ImageServer that builds pyramidal images over another one, an ImageServer that picks a subset of channels from another one, etc.

How are these ImageServer translated ? They are translation to SetupLoader, which is the BigDataViewer class that has the same role as ImageServer.

So currently there's:

• a Bio-Formats ImageServer deserializer
• a Rotated ImageServer deserializer (unwrap)
• a Pyramidize ImageServer deserializer (unwrap)

If I want to do as in this option, this means that I need ideally to write:

• a Bio-Formats ImageServer serializer
• a Rotated ImageServer serializer (optional)
• a Pyramidize ImageServer serializer (optional)

I also need to support some options which are ignored currently or that QuPath handles for me (is the image RGB ? is the pixel size needs to be overriden?)

Also, if I decide to support OpenSlide images, this means that I'll need to write both a deserializer and a serializer instead of simply a deserializer...

While this is possible, I think that I do not think that it will be easily maintainable in the future.

So let's keep this issue opened in case there a change of mind or some other way to achieve this in a good way. But this won't be done for now.

Just as a final note: it may be that QuPath switches to ImgLib2 in the future. If, on top of that, QuPath and Fiji can run on the same jvm, all the synchronization issues could become obsolete, ABBA simply being fully integrated as a QuPath extension. (ping @petebankhead)

Let's keep this issue open.

[GuillaumeLeGoc]

Hi, thanks a lot for your detailed and patient answer :)

I totally understand, I underestimated a lot the work it would require. I'm sure there's a lot of more interesting things to work on !

Cheers

[GuillaumeLeGoc]

Hey,
Working with several people on the same registration project on different computers led me to a workaround for this issue, that I put here, just in case it could be of use to anyone.

Let A.abba be the state file for the project with images imported directly and the registration performed.

1. Create a QuPath project with the exact same images as in ABBA
2. Open ABBA, import the QuPath project and save it as B.abba
3. Open both state files with an archive manager (such as 7-zip)
4. Drag&drop the state.json file from A.abba into B.abba. Confirm the copy and exit the archive manager
5. Load the modified B.abba in ABBA. The sources (images) should be read correctly from B, and the transformations from A applied

You can then export registrations to the QuPath project.