search

juglab / N2V_fiji

BSD 2-Clause "Simplified" License
21 stars 3 forks source link

IndexOutOfBoundsException on Mac/OSX #15

Open maweigert opened 4 years ago

maweigert commented 4 years ago

Hi,

Thanks for the great plugin!

I was trying to train a simple model on OSX (with CPU only, just as a test) , but an error is raised right after the start:

1) Start Fiji and open blobs.gif sample 2) Plugins->CSNDeep->N2V->train with the default values

Screenshot 2020-03-20 at 13 20 10

OSX: 10.14.6 Freshly downloaded Fiji tensorflow 1.13.1

Strangely, normal CSBDeep (e.g. microtubule deconvolution) works just fine (it runs on the CPU).

Any ideas?

frauzufall commented 4 years ago

Jepp, that image is too small for training. For training the data needs to be big enough to create at least one batch from it (batchDimLength x batchDimLength x batchSize).. I thought I added a check for that and a message telling the user to pick a bigger image, guess I didn't :sweat_smile:

maweigert commented 4 years ago

Ah, ok!

Btw, what is the difference between "Dimension length of batch" and "Dimension length of patch"? Intuitively I thought that one need to specifiy batchsize x patch_height x patch_width or?

frauzufall commented 4 years ago

Currently, it creates batches of size batchDimLength x batchDimLength x batchSize and during each training step it only uses a random subpatch of size patchDimLength x patchDimLength x batchSize to feed into the network. We also realized the naming is not consistent with the python code.. I have to get the Java parameter naming in line with the python code and add documentation for it.. It might become something like patch dimension length and subpatch dimension length... Do you think allowing different values for width/height/(depth) is useful? Sounds reasonable. There would be no 3D mode parameter any more since subpatch_z = 1 would mean 2D mode and subpatch_z > 1 would be 3D mode.

maweigert commented 4 years ago

Thanks!

training step it only uses a random subpatch of size

Ah, I was not aware of that. Could the "inner" patch size be computed automatically from the "outer" size? Anyhow, maybe simply renaming the parameter would get rid of that confusion.

Do you think allowing different values for width/height/(depth) is useful?

I guess so - at least optionally (which could be useful if e.g. the image has a very small aspect ratio).