[gdal-dev] Fwd: Color Columns in Raster Attribute Tables

Sat Jan 18 06:22:43 PST 2014

Le samedi 18 janvier 2014 15:18:20, Ivan Lucena a écrit :
> Hi Even,
> 
> In a parallel and almost not related topic, I am getting users complains
> that gdal_translate crashes

Well, that should be debugged and fixed... You don't have more details ?

> or waste their time and storage space with
> some ridiculous RAT that doesn't make any sense for their use case. Maybe
> we should have a -noRAT option on gdal_translate. I could also add an
> "RAT2VAT=NO" create-option on GeoRaster driver.

Yes, -norat option in gdal_translate makes sense.

> 
> Any better idea?
> 
> Regards,
> 
> Ivan
> 
> > From: even.rouault at mines-paris.org
> > To: gillingham.sam at gmail.com
> > Date: Fri, 17 Jan 2014 20:33:21 +0100
> > CC: gdal-dev at lists.osgeo.org
> > Subject: Re: [gdal-dev] Fwd:  Color Columns in Raster Attribute Tables
> > 
> > Le vendredi 17 janvier 2014 01:21:14, Sam Gillingham a écrit :
> > > Hi Even, Frank,
> > > 
> > > I'm interested to hear if you have an opinion on this. Is this
> > > behaviour by design or a bug in the HFA driver?
> > > 
> > > I'm happy to supply a patch to the HFA driver if you think this is
> > > sensible solution. I just want to make sure I'm not missing
> > > anything...
> > 
> > RAT is not my cup of tea, so I'm not sure to have a particularly
> > enlightened opinion on this. It is a bit annoying that the HFA behaviour
> > goes against the documentation. AFAIK nobody has ever complained about
> > this, so this might be just a sign that RAT is not widely used. Provided
> > that it is documented in MIGRATION_GUIDE.TXT, I think it would be OK to
> > make the driver behaviour consistant with the doc.
> > Actually, I'm just thinking to the following point : if the color table
> > in IMG is represented as a float, could values that are not of the form
> > N / 255 be possible (when generated by Imagine) ?  If so, we would loose
> > information by casting to int. It is a bit strange they have selected a
> > floating point serialization.
> > Another possibility would be to indicate the validity range of the
> > attribute, e.g 0-255 or 0-1, so that applications can normalize to
> > [0,255] if they need to.
> > 
> > > Thanks for your time,
> > > 
> > > Sam.
> > > 
> > > ---------- Forwarded message ----------
> > > From: Sam Gillingham <gillingham.sam at gmail.com>
> > > Date: 14 January 2014 08:51
> > > Subject: Re: [gdal-dev] Color Columns in Raster Attribute Tables
> > > To: Ivan Lucena <lucena_ivan at hotmail.com>
> > > Cc: gdal dev <gdal-dev at lists.osgeo.org>
> > > 
> > > 
> > > Hi Ivan,
> > > 
> > > Unfortunately the color table API does not support the functionality
> > > that was added to the RAT API in RFC40. As a result, dealing with
> > > large color tables can be problematic.
> > > 
> > > Yes the HFA driver does report colors correctly as 0-255 with the color
> > > table API and one solution could be to add RFC40 functionality to the
> > > color table API. However, it does seem that it does make sense to be
> > > able to manipulate colors from the RAT API for e.g. setting colors
> > > based on the value(s) found in other attribute columns easily.
> > > 
> > > I accept that no consistency can be expected for user defined columns
> > > (usage == GFU_Generic) but I would have though applications could
> > > depend on the color columns since they are marked as such by their
> > > usage. In fact the documentation for the usage values (
> > > http://www.gdal.org/gdal_8h.html#a27bf786b965d5227da1acc2a4cab69a1)
> > > does specify them to be 0-255 so this seems to have been the intention
> > > and is maybe just a bug in the HFA driver.
> > > 
> > > Sam.
> > > 
> > > On 13 January 2014 15:18, Ivan Lucena <lucena_ivan at hotmail.com> wrote:
> > > > Hi Sam,
> > > > 
> > > > In GDAL color table is supported by the GDALColorTable
> > > > http://gdal.org/classGDALColorTable.html not by
> > > > GDALRasterAttributeTable
> > > > http://gdal.org/classGDALRasterAttributeTable.html.
> > > > 
> > > > The GDALColorTable is a little bit limited but it is pretty much
> > > > consistent across all the drivers that support it. For example, when
> > > > you say that HFA reports RGBA with values from 0..1 as RAT it
> > > > probably reports the correct 0..255 as GDALGetColorTable or it
> > > > doesn't report it at all, because of the GDALColorTable limitation,
> > > > like data type or number of colors.
> > > > 
> > > > But IMHO, there is no reason to expect consistency on the
> > > > representation of color table from a driver RAT. An RAT could be
> > > > user defined or generated by some driver or application.
> > > > 
> > > > What you are seem is that some drivers are using, or maybe abusing,
> > > > the freedom format of RAT to report information than can be
> > > > understood by some particular application or software (mea culpa on
> > > > one of those).
> > > > 
> > > > Best regards,
> > > > 
> > > > Ivan
> > > > 
> > > > ------------------------------
> > > > Date: Mon, 13 Jan 2014 13:06:01 +1300
> > > > From: gillingham.sam at gmail.com
> > > > To: gdal-dev at lists.osgeo.org
> > > > Subject: [gdal-dev] Color Columns in Raster Attribute Tables
> > > > 
> > > > 
> > > > Hi List,
> > > > 
> > > > There appears to be an inconsistency in the way color columns are
> > > > handled within Raster Attribute Tables (RATs) by different drivers.
> > > > Color columns are currently identified by their 'usage' setting -
> > > > GFU_Red, GFU_Green, GFU_Blue and GFU_Alpha. The HFA driver presents
> > > > color columns as doubles between 0 and 1 as this is how they are
> > > > stored in the file. The IDRISI driver presents them as integers
> > > > between 0 and 255 like the Color Table API. Code that uses color
> > > > columns from the RAT API currently needs to know which driver it is
> > > > using, defeating one of the aims of GDAL.
> > > > 
> > > > I propose that the RAT API be defined so that color columns always
> > > > appear as Integer 0-255 no matter what type and range they are
> > > > stored as. This would make the RAT API consistent with the Color
> > > > Table API and would mean a change to the HFA driver
> > > > 
> > > > Another option is that flags are added to the RAT SetValue,
> > > > GetValueAs* and ValuesIO calls to specify the conversion to/from the
> > > > native type. This seems a bigger change.
> > > > 
> > > > Any thoughts?
> > > > 
> > > > Sam.
> > > > 
> > > > _______________________________________________ gdal-dev mailing list
> > > > gdal-dev at lists.osgeo.org
> > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Geospatial professional services
http://even.rouault.free.fr/services.html