You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently evaluation occurs only on structured, non-overlapping patches. The "right" way to perform evaluation is by consensus of overlapping patches.
Based on the paper here: https://arxiv.org/abs/1504.07947 the maximum benefit/cost ratio is simple voting or max pooling over a range of patches that include a given pixel.
So the plan would be to pad the image, then evaluate the model on every possible patch centered on a pixel in the original image. We would probably not want to evaluate on every single pixel, that would mean for each N-pixel image we would need N evaluations on the GPU, which could be very expensive. We can mitigate this issue by adding a small-pixel stride so we only have N/K^2 patches to evaluate, where K is the stride length in pixels.
Storing the intermediate results is tricky, and there are a few options. The fastest may be a dict of dicts or ragged array of nested lists for each pixel subscript. Then in each we store the intermediate classifications/probabilities for the appropriate pixel.
Then to collapse the results we loop over a blank image copy. For each subscript, access the associated intermediate class/prob list and deal with it appropriately to produce a single class, and store that in the blank image copy.
The text was updated successfully, but these errors were encountered:
Currently evaluation occurs only on structured, non-overlapping patches. The "right" way to perform evaluation is by consensus of overlapping patches.
Based on the paper here: https://arxiv.org/abs/1504.07947 the maximum benefit/cost ratio is simple voting or max pooling over a range of patches that include a given pixel.
So the plan would be to pad the image, then evaluate the model on every possible patch centered on a pixel in the original image. We would probably not want to evaluate on every single pixel, that would mean for each N-pixel image we would need N evaluations on the GPU, which could be very expensive. We can mitigate this issue by adding a small-pixel stride so we only have N/K^2 patches to evaluate, where K is the stride length in pixels.
Storing the intermediate results is tricky, and there are a few options. The fastest may be a dict of dicts or ragged array of nested lists for each pixel subscript. Then in each we store the intermediate classifications/probabilities for the appropriate pixel.
Then to collapse the results we loop over a blank image copy. For each subscript, access the associated intermediate class/prob list and deal with it appropriately to produce a single class, and store that in the blank image copy.
The text was updated successfully, but these errors were encountered: