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. > 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. > 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. > On Tue, Mar 5, 2013 at 10:56 AM, Caleb Hanger <cdhan...@gmail.com> 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 > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > > > -- > Best regards, > Chaitanya kumar CH. > > +91-9494447584 > 17.2416N 80.1426E _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
