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

error: Insufficient number of outputs from right hand side of equal sign to satisfy assignment. (dominant_patch) #59

Open
ChrisK-M opened this issue May 19, 2021 · 2 comments

Comments

@ChrisK-M
Copy link

For one of my msCam directories, line 16 in the dominant_patch code gives me the error:
"Insufficient number of outputs from right hand side of equal sign to satisfy assignment." (similar error to one of the closed issues, but different source.)

Insights from my troubleshooting efforts:

  • Ran with no thresh specified, so using default value of 0.1
  • Y is 240x376 (csv with Y attached) (y.csv)
  • imagesc(Y) seems to indicate a normal image
  • msktt is a zero matrix with four entries, that are all value 0.5 (which I don't think regionprops can handle)
  • since msktt is not completely zero, it overwrites mskt and thus leads to 0x1 structure for regionprops(mskt)

Should these 0.5-valued msktt matrices be able to ever occur?

When regionprops does return an empty structure, how best to adjust code to catch that? I'm tempted to just have mask refer to the entire image in those cases, but not really understanding how all the parts do their full magic together, I don't know if that is a correct workaround or that it has negative side7-effects

Thanks for any insights,
Chris

@JinghaoLu
Copy link
Owner

Hi Chris, sorry it takes so long to reply. I have been preparing for my dissertation recently intensely. For the issue you mentioned, it is actually caused by a dead pixel in your video (139,223) that is super bright, so that when rescaling the image pixel range, it underestimate all the other pixels. This results in the processed image for calculating the dominant patch to include none info.

The simple workaround might be to insert a line of code between line 9 and 10 to remove/soften the bad pixel, either using imgaussfilt or medfilt2. This should not and does not usually happen, but if that is more and more common, I might need to add some code to ensure this issue is handled well in the future.

For the purpose of this part, it is actually another layer of filter to remove the spatially unrealistic false positives that are outside of the focal area within the FOV (for example, the dirt or edge of the grin lens reflecting light but is outside of the illuminated center area).

Hope this answer is still in time for you. Thanks!

@ChrisK-M
Copy link
Author

ChrisK-M commented Jul 30, 2021 via email

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

2 participants