Passing more bands to the segmentation routine.

[csherwood-usgs]

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?

[dbuscombe-usgs]

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