Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

checkpoint_nobinary(imgstack) #64

Closed
camcondylis opened this issue Mar 19, 2019 · 14 comments
Closed

checkpoint_nobinary(imgstack) #64

camcondylis opened this issue Mar 19, 2019 · 14 comments

Comments

@camcondylis
Copy link

camcondylis commented Mar 19, 2019

"octave: X11 DISPLAY environment variable not set
octave: disabling GUI features
error: input: reading user-input failed!
error: called from
checkpoint_nobinary at line 7 column 15
/share/pkg/cdeep3m/1.6.2/install/bin/PreprocessTrainingData.m at line 47 column 1"

I have verified that each slice of my image stack has more than 3 unique elements (lowest is 4), but the program keeps flagging it here. Any suggestions?

@MatthewBM
Copy link
Collaborator

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
Copy link
Author

camcondylis commented Mar 19, 2019

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
Copy link
Collaborator

@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
Copy link
Author

@MatthewBM makes sense. Thanks for your help!

@camcondylis
Copy link
Author

can the program not handle 16-bit?

@MatthewBM
Copy link
Collaborator

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
Copy link
Collaborator

haberlmatt commented Mar 19, 2019

@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
Copy link
Author

@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
Copy link
Collaborator

@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
Copy link
Author

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

@haberlmatt
Copy link
Collaborator

@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
Copy link
Author

@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
Copy link
Collaborator

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 cdeep3m@gmail.com and I'll see if I can figure it out from there

@camcondylis
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants