[gdal-dev] Histograms without null pixels

[Chaitanya kumar CH]

The main usage of gdalinfo is manual inspection of the image. It was not
intended for use within other scripts. The output is formatted for human
reading.


On Tue, Mar 5, 2013 at 9:00 PM, Caleb Hanger <cdhanger at gmail.com> wrote:

> On Tue, Mar 05, 2013 at 01:31:01PM +0530, Chaitanya kumar CH wrote:
> > On Tue, Mar 5, 2013 at 11:53 AM, Caleb Hanger <cdhanger at gmail.com>
> wrote:
> > > 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.
>
> Understood, thanks for pointing that out.  In that case, however, the
> responsibility to decide whether to include out-of-range values lies in the
> raster format, correct?
>
> > 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
>
> Right, of course I can construct my own utility to include the GDAL
> libraries and call GetHistogram in the manner I'd like, and I will probably
> end up doing so, but in C.  My main goal at the moment is a bash shell
> script that accomplishes a bigger task, so with a Python script I'd still
> have to call out to the Python script externally.  Either language would be
> suited well for the smaller purpose of getting and analyzing the histogram.
>  I merely found it odd that gdalinfo does not allow the user to disable an
> option that just doesn't seem to make sense for most applications.
>
> > > 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.
>
> Thanks; I will post a patch when I have a chance.  When requesting a
> histogram in gdalinfo, the min/max values are already mentioned, and this
> will just be an addition to, and modification of, that functionality.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20130305/5fd3cbb7/attachment.html>