Choice of viewer after finish

[7rebor]

I don't normally use big data viewer to look at finished stacks (maybe I should), but this is the default and has no option to prevent opening. This takes time to open and I have to wait until it has opened the big data viewer to then open the transformed file as an imagej stack.

Maybe a tickbox choice for the user to open either big data viewer, imagej stack or the other option after transformation is complete

[tischi]

Makes sense! I will add this checkbox.

[7rebor]

I noticed that the ImageJ stacks are loaded as a virtual stack. My images are ~1GB and I'm struggling to save them afterwards, it's currently taking >5 minutes.

EDIT: they are also slightly corrupted when saving (some of the slices in the stack are chopped up)

EDIT2: I also struggle to see how well they have been aligned because it is laggy when navigating through the stacks

EDIT3: I don't actually know what disk will be used for caching the virtual stack - probably a slow one as it's very slow to do any operations on the virtual stack

[tischi]

These are good observations! It is in fact not cached at all but the registered images are constantly recomputed from the original data (this is the imglib2 style of doing things). I also noticed that saving the images is very slow! I will see what I can do in terms of performance....

[tischi]

Hello,

I uploaded a new version. Could you please test the following:

1. There is now a button: [Show result using BigDataViewer] I know it is some learning curve to handle the BDV, but I happen to know it will be used more and more in ImageJ in the future, so it should be worth it :-) What I would like to know if browsing the registered data set is more fluent for you in the BDV than in the standard ImageJ1 viewer (i.e. less lagging).

2. There also is a button [Save results as ICS using SCIFIO]. ICS is a very nice 5D format that you can open in Fiji but also, e.g. in Imaris. Saving like this will not be faster, but I hope that there should be no more corruption in the saved data. Could you try this?

[7rebor]

There is now a button: [Show result using BigDataViewer] I know it is some learning curve to handle the BDV, but I happen to know it will be used more and more in ImageJ in the future, so it should be worth it :-) What I would like to know if browsing the registered data set is more fluent for you in the BDV than in the standard ImageJ1 viewer (i.e. less lagging).

BigDataViewer button works fine, loads very quickly (nice) and now I've learnt the shortcuts it is easier to use! I can search through my data quickly (albeit at a lower resolution while navigating through the stack).

There also is a button [Save results as ICS using SCIFIO]. ICS is a very nice 5D format that you can open in Fiji but also, e.g. in Imaris. Saving like this will not be faster, but I hope that there should be no more corruption in the saved data. Could you try this?

I get an error (below), do I need a plugin installed for SCIFIO to work properly in the scenario?

io.scif.img.ImgIOException: io.scif.FormatException: F:\PhD\Analysis\In vivo\Test\Hello: No supported format found.
	at io.scif.img.ImgSaver.writeImg(ImgSaver.java:494)
	at io.scif.img.ImgSaver.writeImg(ImgSaver.java:459)
	at io.scif.img.ImgSaver.saveImg(ImgSaver.java:174)
	at io.scif.img.ImgSaver.saveImg(ImgSaver.java:158)
	at io.scif.img.ImgSaver.saveImg(ImgSaver.java:128)
	at de.embl.cba.registration.Writers.saveMetaImageUsingScifio(Writers.java:31)
	at de.embl.cba.registration.ui.RegistrationPlugin.saveResultAsICSusingSCIFIO(RegistrationPlugin.java:324)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.scijava.module.MethodRef.execute(MethodRef.java:70)
	at org.scijava.module.AbstractModuleItem.callback(AbstractModuleItem.java:230)
	at org.scijava.widget.DefaultWidgetModel.callback(DefaultWidgetModel.java:188)
	at org.scijava.ui.swing.widget.SwingButtonWidget$1.actionPerformed(SwingButtonWidget.java:83)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
	at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
	at java.awt.Component.processMouseEvent(Component.java:6535)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
	at java.awt.Component.processEvent(Component.java:6300)
	at java.awt.Container.processEvent(Container.java:2236)
	at java.awt.Component.dispatchEventImpl(Component.java:4891)
	at java.awt.Container.dispatchEventImpl(Container.java:2294)
	at java.awt.Component.dispatchEvent(Component.java:4713)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4888)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4525)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4466)
	at java.awt.Container.dispatchEventImpl(Container.java:2280)
	at java.awt.Window.dispatchEventImpl(Window.java:2750)
	at java.awt.Component.dispatchEvent(Component.java:4713)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
	at java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.awt.EventQueue$3.run(EventQueue.java:709)
	at java.awt.EventQueue$3.run(EventQueue.java:703)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.awt.EventQueue$4.run(EventQueue.java:731)
	at java.awt.EventQueue$4.run(EventQueue.java:729)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Caused by: io.scif.FormatException: F:\PhD\Analysis\In vivo\Test\Hello: No supported format found.
	at io.scif.services.DefaultFormatService.getFormatList(DefaultFormatService.java:351)
	at io.scif.services.DefaultFormatService.getFormatList(DefaultFormatService.java:328)
	at io.scif.img.ImgSaver.writeImg(ImgSaver.java:478)
	... 50 more

[tischi]

My bad!
You have to actively specify the file type when saving!

You'd have to say "Hello.ics"
You can also try "Hello.tif"
I'd be interested to hear what works better for you!

As said it is still slooooow, when saving.

[7rebor]

.ics saves fine, .tif does not though - didn't wait to see how long it takes to save (is it the same amount of time as saving a virtual stack?)

[tischi]

For me the time was very similar to saving directly from ImageJ.

The point is the following: My code works on imglib2 data structures. SCIFIO can directly save imglib2 (at least this is my understanding). If you save the displayed virtual stack, this is in fact a ImageJ1 wrapped version of the underlying imglib2 data. My hope is that directly using SCIFIO should avoid the partly corrupted data.

ICS is a very good format. If that works for you then I recommend using it.

[imagejan]

@7rebor @tischi there are known issues with SCIFIO performance when writing tif files, while saving to ics/ids is much faster. See also scifio/scifio#310.

[tischi]

@imagejan Thanks for the information!