Open complex file types (with BioFormats)

[tischi]

@NicoKiaru

If people open for example a .lif or .czi file the content can be very complex, with many different images of different dimensions.

We need to come up with a GUI (or maybe even a chain of GUIs as a wizard) that enables (and forces) our users to conveniently only select a subset of these images which can be combined into a single raiXYZCT.

In other words, the users should only be allowed to select a group of images that have the same dimensions in XYZ and T. Then this group of images can be stacked along the channel dimension.

[NicoKiaru]

Restricting to a series should do the trick. That's what I started on the other branch. For the UI, we could keep it simple for the moment and just ask for a number. Potentially we could probably reuse what's done in bioformats in FIJI, where you have a list of thumbnail for each series.

[NicoKiaru]

@tischi done, please have a look at the last commit

[tischi]

Thanks! Looks very good. However, as usual with Bio-Formats, it is slow ;-) I tried to test it reading from 3.2GB czi file over VPN and this essentially never returned (I waited few minutes):

                readerIdx.setId(file.getAbsolutePath());
                this.numberOfSeries = readerIdx.getSeriesCount();

Is there anything we could do to tell the user to wait or something like this? Otherwise it feels as if it crashed.

I put the whole callback into a new Thread, then at least the UI stays responsive, but I did not manage to have a "Please wait message" appear.

Could you please:

1. pull
2. check at the TODO in your Command whether you have an idea?

[NicoKiaru]

Honestly, doing this in a separate thread is really difficult. Is it thread safe ? Is it updating correctly ? Do you block the previous job if the user chooses another file while the first one is being read ?

I would go for a checkbox which activates or deactivate the 'message' - with a warning mentioning that this can take a long time for big files - but asynchronous job really adds a lot of complexity.

[tischi]

I would go for a checkbox which activates or deactivate the 'message' - with a warning mentioning that this can take a long time for big files

ok! can you do it?

[NicoKiaru]

I've put a timeout. It's a parameter of the command, but if you prefer, you can just set it to 5 seconds (it's probably better)

[tischi]

Wow! Cool stuff!

Inspired by this I am thinking another interesting solution could be if a window showed up

Parsing file to pre-fetch image series information...
If this takes too long you may press cancel and just enter a series index to be opened.
If the file only consist of one image data set, series index 0 does the job.

[ Cancel ]  

And then the cancel button could do the future.cancel( true );

What do you think?

I think the advantage could be that we would not need the timeout parameter, which may be a bit confusing for users.

[NicoKiaru]

Sound great, but you need to make the window modal because you don't want to have two windows showing up.

I completely agree that the timeout parameter should be removed. A simple alternative option is just to put a timeout to 5s.

[NicoKiaru]

Ah, you need a ref to the parent JFrame to make it modal (https://stackoverflow.com/questions/1481405/how-to-make-a-jframe-modal-in-swing-java), so it will be kind of hacky...

[tischi]

you need a ref to the parent JFrame to make it modal

Did you try just like this without the parent frame?

JDialog dialog = new JDialog();
dialog.setModalityType(Dialog.ModalityType.APPLICATION_MODAL);

[tischi]

@NicoKiaru

I made a branch saving our current attempts: https://github.com/bigdataprocessor/bigdataprocessor2/tree/bioFormatsSeriesParser And in the master rolled back to the version where we simply open series index 0. The issues were

I realised, even if we cancel the future, the reader would still go on trying to parse the file, isn't it? This would eat put resources I guess and slow down the actual opening of the file.

I put this finally block which should close the reader anyway. I thought it was called when the cancellation happens, but I didn't checked...

I thus think we need more time to fix this properly. Time which we both currently don't have, I think.

Agree

OK for you?

OK

[NicoKiaru]

Oups, I edited instead of replying ...

[tischi]

I put this finally block which should close the reader anyway. I thought it was called when the cancellation happens, but I didn't checked...

Yes, I saw it, maybe that does the job in fact! Anyway, the other issues still remain.