09-25-2016 05:25 PM
I ran into a situation where a Clump operation either yielded the linework on my image or everything but the linework. That behavior was controlled by the PhotometricInterpretation in TIF image, which dictates which pixel value/color on the image represents the background. Some of my images were black ink on a white background (PhotometricInterpretation = 0), while some were negatives (white ink on a black background. PhotometricInterpretation = 1).
There isn't a direct way to simply read tag info off of a TIF, but you could "estimate" the PhotometricInterpretation using the Statistics operator's Median port. If the Median is 0, the background color is black (PhotometricInterpretation = 1). If 1, the background color is white (PhotometricInterpretation = 0).
09-26-2016 11:13 AM - edited 09-26-2016 11:21 AM
Part of the development plans for ERDAS IMAGINE 2017 include improvements to Spatial Modeler's Metadata handling capabilities, which should make this a lot easier.
In the meantime (or should that be "mediantime"?) using this approach is an excellent solution for 1-bit scanned data. I wonder if using Mode would work if you have a larger bit-depth (and working on the same assumption that the "background" colour constitutes the largest single "class" of the scanned map)?
09-28-2016 10:08 PM
That's a great idea, but I was suspicious of Mode. Although it's possible for mode to equal to min, I just didn't expect that in my dataset.
I used QGIS to export my layer attributes to an "Excel" file (actually, Calc) and computed Min and Mode on M_AREA there. I then copied M_AREA into MiniTab and computed mode.
-- MODE --
ERDAS: 0.00000556 // 2-orders of magnitude! EXCEL: 0.00055000 MINITAB:0.00057222 // good grief, no consensus
09-28-2016 05:45 AM
I guess the fact that ERDAS IMAGINE is getting the same value for Min and Mode does indicate that Mode successfully finds the background value. But I have no idea why that value would be so markedly different from the other packages.
Mode will work well in the case of raster inputs (lots of pixels with the same value), but you're doing it on a table of Area values - I wouldn't know what the "most commonly occurring area value" would be in that instance (especially given that these are Float values - so there are unlikely to be several occurrences of exactly the same float value). Did you visually scan through your table list to see if things like Min, Max, etc appeared valid ( I see that Min varies wildly as well, but should be easy to spot in the list)?
09-28-2016 09:25 AM