Caleb,
On Tue, Mar 5, 2013 at 11:53 AM, Caleb Hanger <[email protected]> wrote: > On Tue, Mar 05, 2013 at 11:19:27AM +0530, Chaitanya kumar CH wrote: > > > Caleb, > > > > gdalinfo uses the GetDefaultHistogram() method which can do this faster > by > > fetching a precomputed histogram. > > What do you mean? The histogram is only precomputed if gdalinfo has been > run previously and stored a cache of data (the XML file) for later > reference; please correct me if I'm wrong. Otherwise, it seems to me that > the data *must* be analyzed and the data computed; there is no way around > that. Additionally, I don't think it makes sense to say that it is faster > to assemble a histogram that includes out-of-range values than to assemble > a histogram that does not, because the latter is a subset contained within > the former. > Some raster formats can store the histogram data as metadata. Also, there are is a shortcut; overviews can be used to get approximate values faster. > > gdalinfo is a command line program. Even a default histogram of 256 > buckets > > is hard to visualize in text mode. A much better way is to use a desktop > > GIS like qgis to view the histogram. > > A desktop GIS is not practical for providing a shell script meant to > automate a repetitive (and much larger) task, with a small chunk of data > that it needs for a single step in the process. That is, I don't need to > "visualize" the data -- I just need to get the information. The more > primitive the format, the better, as I like things that are lean and mean, > and I know how to instruct the script to do the required mathematics upon > the text-only histogram. > You can write a simple python script to get the histogram. You can get a good idea at http://trac.osgeo.org/gdal/browser/trunk/autotest/gcore/histogram.py#L103 > > > Can you justify adding this extra functionality in gdalinfo? > > Yes: quite simply, a histogram that does not include illegitimate values > makes more sense than a histogram that does include them. At least, this > is the case in my experience; perhaps there are situations I'm unfamiliar > with in which the histogram is desired to include values outside of the > histogram's range, for some reason. I'd even go so far as to say that > gdalinfo currently *lies* about the histogram, telling the user that the > histogram shows "256 buckets from X to Y" even though the histogram > includes values which are *outside of that range*. > > Arguably an even better justification is that the machinery to exclude the > illegitimate values is already present in GetHistogram, so *very* few lines > of code would need to be added to gdalinfo, simply to provide a flag for > the user and if that flag is specified, pass "false" for the right > parameter to GetHistogram (bIncludeOutOfRange), instead of just calling > GetDefaultHistogram. > That sounds reasonable. If you can, you should submit a patch or a request at http://trac.osgeo.org/gdal/newticket Note that the functionality should include the facility to include options to mention the min/max values. > > On Tue, Mar 5, 2013 at 10:56 AM, Caleb Hanger <[email protected]> > wrote: > > > > > All, > > > > > > I am writing a script which is calling gdalinfo to get a histogram of > > > pixel values in an image file. Apparently the mechanism for obtaining > a > > > "default" histogram enables the "bIncludeOutOfRange" flag to dump > > > not-in-range pixels (including null pixels, in formats that support it) > > > into whichever bin of the histogram is closest. I see that in the > > > GetHistogram() function, the functionality is already coded to respond > > > appropriately to either a true *or* false value in this flag. > However, I > > > can't seem to find any way to turn that flag off through any of the > > > user-level programs (in particular, gdalinfo), rendering the parameter > to > > > the function useless, unless I'm just not looking hard enough. Hence, > my > > > questions: > > > > > > 1) Is there any standard user-level operation (preferably in gdalinfo) > > > which disables, or at least *allows* for disabling of, the > > > bIncludeOutOfRange flag? If so, I can't find it. > > > 2) If not, how come? Has there been no apparent need for histograms > that > > > omit null values or other "out of range" situations? > > > > > > Thanks in advance for any insight, > > > Caleb Hanger > > > _______________________________________________ > > > gdal-dev mailing list > > > [email protected] > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > > > > > > -- > > Best regards, > > Chaitanya kumar CH. > > > > +91-9494447584 > > 17.2416N 80.1426E > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- Best regards, Chaitanya kumar CH. +91-9494447584 17.2416N 80.1426E
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
