checkpoint_nobinary(imgstack)

[camcondylis]

checkpoint_nobinary(imgstack)

[MatthewBM]

Hi @camcondylis,

You're image stack is 8-bit grayscale, correct? There should be much more than 4 unique elements in the slices of the image stack.

And your label stack should be slices with values 0 or 255, no in-between. Is there any slices in your training data where there is no labels? This might be where the error is.

Best,
Matthew

[camcondylis]

Hi @MatthewBM, thanks for the quick response. My image stack is 16-bit grayscale. it is actually a compilation of multiple stacks appended end to end, each of which have been taken through a tissue, so at points in the stack there are slices where there is almost no signal. I removed slices that actually have no signal because I thought this is what was causing checkpoint_nobinary to throw the error. It seems that as long as there are more than 3 unique elements in each slice of the stack, things should be ok. I have run the program before on training sets that have blank frames in the label stack. You think this is the issue?

[MatthewBM]

@camcondylis Your image stack should be 8-bit values but the checkpoint_nobinary is likely finding more than 2 unique values in your label stack. There should only be values 0 and 255 in your label stack.

[camcondylis]

@MatthewBM makes sense. Thanks for your help!

[camcondylis]

can the program not handle 16-bit?

[MatthewBM]

No, it's formatted for 8-bit data. The conversion should be simple, if you're in imagej/fiji it's just type>8-bit

[haberlmatt]

@MatthewBM, last time i checked it for 16bit it was still working, though i mainly used 8bit lately. But I don't believe that's the problem here, since at this point it's just checking if more than 3 unique grey values are in the images
@camcondylis Are you sure you didn't mistakenly invert the command and feed it with the path to the binaries first?

[camcondylis]

@haberlmatt for PreprocessTrainingData.m, I supplied image directory, label directory, augmented_training directory, respectively. I have run into issues before where I got a similar error when the image stack had a few blank frames at the beginning. deleting them fixed the issue. However, I can't find the source of the error now since all frames have at least 4 unique elements. I just removed all frames that contain very low signal to see if this helps.

[haberlmatt]

@camcondylis thats strange, the program is not evaluating individual images, but the entire stack and counting the number of grey values across the entire stack, so it shouldn't matter
The check function that's issuing an error is actually just there to check for making sure you didn't mistakenly use a binary stack.
are you importing the images as individual .png files?

[camcondylis]

@haberlmatt I am keeping them as individual .tifs rather than .pngs.

[haberlmatt]

@camcondylis Since you mentioned they are from several datasets. Are the .tif files stacked by any chance? If you provide a foldername (and not the full path to a stack) the program wouldn't realize that the individual files in the folder are stacks and probably read just the first image of each stack

[camcondylis]

@haberlmatt they are not stacked. they are stored as individual .tifs in the folder destination. One difference from previous times that it worked is that the image names are not numbered from 1 to end, they are of the form stack1.000 : stack1.###, stack2.000 : stack2.###. Where ### represents the last slice of each stack. Essentially, the "images" folder contains slices from multiple stacks, which are named based on the stack they came from. Do you think this is an issue?

[haberlmatt]

Hi @camcondylis , sorry I missed your answer earlier.
I don't think that would cause any issue. It is reading in alphabetical order, so far I never encountered anything different there. Also the point where you get the error the reading is completed.
If you don't mind you can send us a link to some of the data that is causing the issue to [email protected] and I'll see if I can figure it out from there

[camcondylis]

@haberlmatt just sent an email with a .zip file of the data. Thanks for your help.