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
It might be very useful if we could pass more than three bands to the segmentation routine. @dbuscombe@usgs.gov has indicated that, in principle, there is no reason the segmentation can't work on >3 bands...maybe as many as 12.
The version in my crs_dev branch can read multi-band tiff files. Currently, if more than three bands are encountered, it puts the first three in img, which is passed to both the UI and the seg code. I envision changing the code to send three bands in img to the UI, but all bands in seg_array to the seg. code. I am a little unsure how to make this happen (i.e., I have not pinpointed the place where the image array is passed to the seg code, and I don't know if that code is flexible in the number of bands it can accept). I will try to suss this out in the next few days, but any pointers are welcome!
I also suggest we add flexibility by allowing options for which bands to display in the UI, and which bands to process in the seg code. This could be implemented by adding to the config.ini file a set of indices, like band_to_view with a default of [1,2,3] and bands_to_seg, with a default of all bands. This would allow us to conveniently explore the seg. behaviour of multi-band files.
Ideas? Concerns?
The text was updated successfully, but these errors were encountered:
I like the idea of being able to select which bands to use for display, and which to use for inference. It is a great advantage of this task-specific segmentation that overfitting is not a concern
Concerns: memory consumption. From each image, features are extracted that are H x W x D x 5 x number of scales (2 upwards), so its very easy to generate large raster stacks
Ideas: use Dask arrays to handle all CPU-bound processes that dont fit in memory
It might be very useful if we could pass more than three bands to the segmentation routine. @dbuscombe@usgs.gov has indicated that, in principle, there is no reason the segmentation can't work on >3 bands...maybe as many as 12.
The version in my
crs_dev
branch can read multi-band tiff files. Currently, if more than three bands are encountered, it puts the first three inimg
, which is passed to both the UI and the seg code. I envision changing the code to send three bands inimg
to the UI, but all bands inseg_array
to the seg. code. I am a little unsure how to make this happen (i.e., I have not pinpointed the place where the image array is passed to the seg code, and I don't know if that code is flexible in the number of bands it can accept). I will try to suss this out in the next few days, but any pointers are welcome!I also suggest we add flexibility by allowing options for which bands to display in the UI, and which bands to process in the seg code. This could be implemented by adding to the
config.ini
file a set of indices, likeband_to_view
with a default of [1,2,3] andbands_to_seg
, with a default of all bands. This would allow us to conveniently explore the seg. behaviour of multi-band files.Ideas? Concerns?
The text was updated successfully, but these errors were encountered: