bookmarks NormView

[martinschorb]

Hi,

I have another funny dataset to put into MoBIE.

• 1500 serial tomograms (2.5 TB) in 8 datasets (different experimental conditions)
• I like each dataset to be displayed as a gallery
• for each "image" (serial tomo volume) I want to create a bookmark that focuses on the target object
• the target object is defined by 3 distinct points in voxel coordinates. This basically already decides the viewing slice I need for the bookmark.

My questions:

• I like to use the "NormView" mechanism for that. IS this a good choice or would there be something more appropriate?
• How exactly is "NormView" defined? I assume the BDV window size is the target coordinate frame. What exactly, the shortest axis?

[constantinpape]

* 1500 serial tomograms (2.5 TB) in 8 datasets (different experimental conditions)

So each dataset consists of ~ 190 tomograms and these should be arranged in a grid view?

• for each "image" (serial tomo volume) I want to create a bookmark that focuses on the target object

This would mean ~ 190 bookmarks per dataset? I am not sure if this is very usable, because scrolling through so many bookmarks would be quite tedious for a user.

Another option I can see is implementing this via the 'grid table':
we require a table for grid views already, see https://mobie.github.io/specs/mobie_spec.html#grid-views.
Right now, this table only has a single mandatory column grid_id (which just contains a flattened index for the 2d grid position).
When you open a grid view, it opens and can be used to navigate to grid positions, similar to the segmentation table.
(This is not fully working yet, see #246).
Currently, for each of the grid positions, the anchor point is automatically generated, so that the table can navigate to the correct position upon selection.

Similar to the segmentation table, we could add optional anchor columns, that would be used when navigating to the grid positions instead of the automatically generated ones. These should probably be given w.r.t. the origin of the individual volumes coordinate system, so that they can added to the grid offsets by MoBIE. But @tischi would know more about the internals in the viewer here and maybe has a different opinion on how to do this.

The advantage over bookmarks:
Users could browse the tomograms via a table that looks like this:

grid_id  name  ....
0           my-tomo
1           special-tomo
2           intersting-tomo

where you can also generate the name column, similar to a bookmark name.
And you could add any other image level information to the table.

[martinschorb]

This would mean ~ 190 bookmarks per dataset?

correct, some have more, some less.

Another option I can see is implementing this via the 'grid table':
we require a table for grid views already, see https://mobie.github.io/specs/mobie_spec.html#grid-views.
Right now, this table only has a single mandatory column grid_id (which just contains a flattened index for the 2d grid position).
When you open a grid view, it opens and can be used to navigate to grid positions, similar to the segmentation table.
(This is not fully working yet, see #246).
Currently, for each of the grid positions, the anchor point is automatically generated, so that the table can navigate to the correct position upon selection.

This only offers positions (ie. shift) , correct? I would need the full view functionality, since each volume in this mode will be oriented differently. Hence the idea of using bookmarks.
Alternatively, we could go the proposed spec2 way of defining multiple sets of transformations for each source and show them in different "scenes".

Similar to the segmentation table, we could add optional anchor columns, that would be used when navigating to the grid positions instead of the automatically generated ones. These should probably be given w.r.t. the origin of the individual volumes coordinate system, so that they can added to the grid offsets by MoBIE. But @tischi would know more about the internals in the viewer here and maybe has a different opinion on how to do this.

The advantage over bookmarks:
Users could browse the tomograms via a table that looks like this:

grid_id  name  ....
0           my-tomo
1           special-tomo
2           intersting-tomo

where you can also generate the name column, similar to a bookmark name.
And you could add any other image level information to the table.

[constantinpape]

This only offers positions (ie. shift) , correct? I would need the full view functionality, since each volume in this mode will be oriented differently. Hence the idea of using bookmarks.

I see. Yes, for starters this would only include the position. It could potentially be extended to also change the complete view upon selection by adding more dedicated columns, but that may be a bit too much work for now.

For the bookmark approach you would need to do the following:

• add a grid view for all tomograms as discussed above, but without adding anchor columns
• add the individual bookmarks using viewerTransform: normalizedAffine in an non-exclusive view.

The challenge here is to find the correct normalizedAffine from the parameters you have. @tischi would know more
It probably makes most sense to add the project with the grid view before working on the bookmarks though.

Alternatively, we could go the proposed spec2 way of defining multiple sets of transformations for each source and show them in different "scenes".

Yes, I think this could also make a lot of sense, and could maybe improve usability because users don't have to select from over 100 bookmarks.
But I guess we need to flesh out mobie/mobie.github.io#32 a bit more first.

[martinschorb]

Trying to get a bit more insights into NormView and the bookmarks, I found that modifying position does not change the way a bookmark is displayed. What is its purpose?

[martinschorb]

I am now getting my head into NormView.

One comment towards spec v2:

• why is that transformation stored as string list? Others are number lists.

[constantinpape]

Like I said earlier, normView is deprecated. In the new spec this is viewerTransform: normalizedAffine, see https://mobie.github.io/specs/mobie_spec.html#view-metadata. The strings were also just a hack in the earlier spec, the parameters are proper double values now.

I found that modifying position does not change the way a bookmark is displayed. What is its purpose?

This is just a bug in mobie V1, it's fixed with the new spec. Also note that it's not possible anymore to specify both a affine or normalizedAffine and position in viewerTransform because the position information is redundant in that case.

[martinschorb]

the position information is redundant in that case.

Yes, that's what I was thinking as well.