Nikos Alexandris wrote: > > >> I've tested this with at least three different similar cases. All work > > >> fine without the seed map! All fail with a seed map supplied. I guess, > > >> the only real difference is time for the processes to complete, right?
> > > OK, I've just discovered that I mixed 8-bit (the Pan images) for the > > > seed map and 16-bit (the Multi-Spectral images). So, seed -> 8-bit, > > > group to be segmented -> 16-bit. Does this play a role? Markus Metz: > > No, the seed map must be integer (not more than 32 bit int), that's > > the only limitation. The data to be segmented can be anything, integer > > and/or floating point. > Good to know. I guess this is because the segments are only "counted" then. > > But it does not make sense to use a pan band as seeds when segmenting > > the other bands. Seeds are typically the result of a previous run of > > i.segment or the result of a previous classification of the same data. > Then I have inserted a small mistake in my tests/workflow. Wanted to drive > "finer objects" (from Pan) in bigger ones (based on MS). Will adjust. So, no problem here. All fixed. And, in most of the segmentations so far, indeed, I used pan only (frist segmentation, then seeding a second) and fed the derived objects with descriptive stats. i.segment is a real working tool. It's awesome. N _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
