<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'><br><br><div>> From: even.rouault@mines-paris.org<br>> To: lucena_ivan@hotmail.com<br>> Subject: Re: [gdal-dev] Fwd: Color Columns in Raster Attribute Tables<br>> Date: Sat, 18 Jan 2014 16:23:10 +0100<br>> CC: gillingham.sam@gmail.com; gdal-dev@lists.osgeo.org<br>> <br>> Le samedi 18 janvier 2014 15:40:15, Ivan Lucena a écrit :<br>> > > From: even.rouault@mines-paris.org<br>> > > To: lucena_ivan@hotmail.com<br>> > > Subject: Re: [gdal-dev] Fwd: Color Columns in Raster Attribute Tables<br>> > > Date: Sat, 18 Jan 2014 15:22:43 +0100<br>> > > CC: gillingham.sam@gmail.com; gdal-dev@lists.osgeo.org<br>> > > <br>> > > Le samedi 18 janvier 2014 15:18:20, Ivan Lucena a écrit :<br>> > > > Hi Even,<br>> > > > <br>> > > > In a parallel and almost not related topic, I am getting users<br>> > > > complains that gdal_translate crashes<br>> > > <br>> > > Well, that should be debugged and fixed... You don't have more details ?<br>> > <br>> > I waiting to get a sample file to debug it, but even when it doesn't crash<br>> > they need to manage what to do with the useless VAT table on the database.<br>> > <br>> > > > or waste their time and storage space with<br>> > > > some ridiculous RAT that doesn't make any sense for their use case.<br>> > > > Maybe we should have a -noRAT option on gdal_translate. I could also<br>> > > > add an "RAT2VAT=NO" create-option on GeoRaster driver.<br>> > > <br>> > > Yes, -norat option in gdal_translate makes sense.<br>> > <br>> > IMHO, I don't think we should go to big deal of RPC discussion and voting<br>> > to add that option to gdal_translate.<br>> <br>> I've just added the option. Yes that's not worth a RFC !<br><br>Wow, that was fast. Look at the code, it seems that you are taking advantage of the lack of support for RAT in VRT. Is that right? But I think there was a discussion about adding that support for some other reasons. Perhaps when someone wants to translate the RAT but also wants to enter one of those gdal_translate parameters that triggers the VRT. So I think that in the future we would need to add support for RAT to the VRT driver and also add a create-option on that same driver to tell it not do create the RAT. Does it makes sense?<br><br>> <br>> > <br>> > One work around that they are using is to run gdal_translate -of VRT, since<br>> > VRT drivers does not support RAT, they can use it as input instead of the<br>> > HFA .img files. They could just add -outsize 100% 100%, I guess. That<br>> > would also do the trick without create VRT files.<br>> > <br>> > But gdal_translate is not the only way to run the CreateCopy of a driver,<br>> > so I think I am going to add my create-option anyway.<br>> > <br>> > Regards,<br>> > <br>> > Ivan<br>> > <br>> > > > Any better idea?<br>> > > > <br>> > > > Regards,<br>> > > > <br>> > > > Ivan<br>> > > > <br>> > > > > 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<br>> > > > > 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<br>> > > > > > behaviour by 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<br>> > > > > > sensible solution. I just want to make sure I'm not missing<br>> > > > > > anything...<br>> > > > > <br>> > > > > RAT is not my cup of tea, so I'm not sure to have a particularly<br>> > > > > enlightened opinion on this. It is a bit annoying that the HFA<br>> > > > > behaviour goes against the documentation. AFAIK nobody has ever<br>> > > > > complained about this, so this might be just a sign that RAT is not<br>> > > > > widely used. Provided that it is documented in MIGRATION_GUIDE.TXT,<br>> > > > > I think it would be OK to make the driver behaviour consistant with<br>> > > > > the doc.<br>> > > > > Actually, I'm just thinking to the following point : if the color<br>> > > > > table in IMG is represented as a float, could values that are not of<br>> > > > > the form N / 255 be possible (when generated by Imagine) ? If so,<br>> > > > > we would loose information by casting to int. It is a bit strange<br>> > > > > they have selected a floating point serialization.<br>> > > > > Another possibility would be to indicate the validity range of the<br>> > > > > attribute, e.g 0-255 or 0-1, so that applications can normalize to<br>> > > > > [0,255] if they need to.<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<br>> > > > > > functionality that was added to the RAT API in RFC40. As a result,<br>> > > > > > dealing with large color tables can be problematic.<br>> > > > > > <br>> > > > > > Yes the HFA driver does report colors correctly as 0-255 with the<br>> > > > > > color table API and one solution could be to add RFC40<br>> > > > > > functionality to the color table API. However, it does seem that<br>> > > > > > it does make sense to be able to manipulate colors from the RAT<br>> > > > > > API for e.g. setting colors based on the value(s) found in other<br>> > > > > > attribute columns easily.<br>> > > > > > <br>> > > > > > I accept that no consistency can be expected for user defined<br>> > > > > > columns (usage == GFU_Generic) but I would have though<br>> > > > > > applications could depend on the color columns since they are<br>> > > > > > marked as such by their usage. In fact the documentation for the<br>> > > > > > usage values (<br>> > > > > > http://www.gdal.org/gdal_8h.html#a27bf786b965d5227da1acc2a4cab69a1)<br>> > > > > > does specify them to be 0-255 so this seems to have been the<br>> > > > > > intention and is 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> <br>> wrote:<br>> > > > > > > Hi Sam,<br>> > > > > > > <br>> > > > > > > In GDAL color table is supported by the GDALColorTable<br>> > > > > > > http://gdal.org/classGDALColorTable.html not by<br>> > > > > > > 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,<br>> > > > > > > when you say that HFA reports RGBA with values from 0..1 as RAT<br>> > > > > > > it probably reports the correct 0..255 as GDALGetColorTable or<br>> > > > > > > it doesn't report it at all, because of the GDALColorTable<br>> > > > > > > limitation, like data type or number of colors.<br>> > > > > > > <br>> > > > > > > But IMHO, there is no reason to expect consistency on the<br>> > > > > > > representation of color table from a driver RAT. An RAT could be<br>> > > > > > > user defined or generated by some driver or application.<br>> > > > > > > <br>> > > > > > > What you are seem is that some drivers are using, or maybe<br>> > > > > > > abusing, the freedom format of RAT to report information than<br>> > > > > > > can be understood by some particular application or software<br>> > > > > > > (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<br>> > > > > > > handled within Raster Attribute Tables (RATs) by different<br>> > > > > > > drivers. Color columns are currently identified by their 'usage'<br>> > > > > > > setting - GFU_Red, GFU_Green, GFU_Blue and GFU_Alpha. The HFA<br>> > > > > > > driver presents color columns as doubles between 0 and 1 as this<br>> > > > > > > is how they are stored in the file. The IDRISI driver presents<br>> > > > > > > them as integers between 0 and 255 like the Color Table API.<br>> > > > > > > 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<br>> > > > > > > GDAL.<br>> > > > > > > <br>> > > > > > > I propose that the RAT API be defined so that color columns<br>> > > > > > > always appear as Integer 0-255 no matter what type and range<br>> > > > > > > they are stored as. This would make the RAT API consistent with<br>> > > > > > > the Color Table API and would mean a change to the HFA driver<br>> > > > > > > <br>> > > > > > > Another option is that flags are added to the RAT SetValue,<br>> > > > > > > GetValueAs* and ValuesIO calls to specify the conversion to/from<br>> > > > > > > the native type. This seems a bigger change.<br>> > > > > > > <br>> > > > > > > Any thoughts?<br>> > > > > > > <br>> > > > > > > Sam.<br>> > > > > > > <br>> > > > > > > _______________________________________________ gdal-dev mailing<br>> > > > > > > list gdal-dev@lists.osgeo.org<br>> > > > > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev<br>> <br>> -- <br>> Geospatial professional services<br>> http://even.rouault.free.fr/services.html<br></div> </div></body>
</html>