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