[gdal-dev] Re: storing height information in a .tif rather
the grayscale in the tif relying on another file
ivar
ivar at avenza.com
Tue Feb 23 18:02:16 EST 2010
Ytrapaet,
There is no such thing as an 'associated color table' in strict
TIFF meaning. In the specific case of DEM TIFF you have either one of
two cases: 1) a grayscale TIFF that is generated using some sort of
mapping between raw elevation values and grayscale colors. If the
mapping is 1-to-1 which is, of course, normally only possible for 16 or
32 bit grayscale color mode, it can be called "raw" data, since it
allows conversion back to the original values, well, at least with
integer precision. This grayscale TIFFs can be rendered by various
software packages using whatever colorization method they default to or
whatever the user choice is; obviously in case of Photoshop there is no
default and its up to the user to apply whatever gradient they choose
manually 2) a pre-colorized TIFF, basically 2D or 3D rendering of the
DEM data where the raw values are irreversibly replaced by the image
rendition using selected colorization schema. The choice is determined,
say, in ArcGIS by 'Use rendered' checkbox on export. There are, of
course, some other formats (ESRI HDR, for example) that indeed do store
a color table separately, however in any case this is not a kind of
information that Photoshop would render out-of-the-box. Moreover, even
rendering a simple 16-bit graysclae image in Photoshop is not performed
on a 1-1 mapping basis - Adobe has their own way of re-interpreting
values for display purpose and I remember having to dig through Adobe
forums unraveling these mysteries when working on our Geographic Imager
product. In any case, I think Frank is right and indeed it is more of a
Photoshop discussion at this point. If you want, you can contact me
offline or/and send your sample data if you still have any specific
questions.
ivar
Avenza Systems Inc
On 23/02/2010 2:46 PM, gdal-dev-request at lists.osgeo.org wrote:
> Message: 4 Date: Tue, 23 Feb 2010 14:12:56 -0500 From: Frank Warmerdam
> <warmerdam at pobox.com> Subject: Re: [gdal-dev] Re: storing height
> information in a .tif rather the grayscale in the tif relying on
> another file To: anotherObject <ytrapaet at hotmail.com> Cc:
> gdal-dev at lists.osgeo.org Message-ID: <4B8428B8.60604 at pobox.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> anotherObject wrote:
>> > Sorry for not being clearer: I started off with a a 32bit tif - however, im
>> > not sure how I can tell if it has an associated color table.
>>
> Ytrapaet,
>
> Try running gdalinfo against the file and seeing what it reports. Including
> a gdalinfo report with your email would make it much easier for us to
> give a meaningful reply.
>
>
>> > Are there both types of tifs? if so how can I convert from one to the other?
>>
> There are many types of TIFF files. TIFF supports a wide variety of color
> models, pixel data types and numbers of bands.
>
>
>
>> > What I do know is that when the 32bit elevation model is viewed through
>> > ArcGIS, its default setting was on "standard deviation stretch". If I change
>> > it to "none", it gives the correct elevation values. However, this seems to
>> > only be a display setting;
>>
> You are correct - this is a display setting in ArcGIS and does not
> reflect some fundamental nature of the file.
>
> > when I converted the 32 to 8bit using
>
>> > gdal_translate (which is the same as your example), the resulting 8bit image
>> > did not have any stretching when I viewed it in ArcGIS. However,the
>> > conversion did produce my8bit.tif along with my8bit.aux.xml.
>> >
>> > Normally, when i open images in photoshop, i only plan to loose the
>> > georeferencing information, however, it seems that when i open my8bit.tif, i
>> > also loose the proper colors. I think this is because the color information
>> > is stored in the .aux.xml file, but I dont know how to produce a .tif that
>> > is any different (that does not have a .aux.xml file)
>>
> What colors do you see? Just a range of greys? Once again, you speak
> of "proper colors", but I will claim there is no inherent colors involved.
> Perhaps you just mean it is using a stretch or display mode that does not
> meet your expectations or wishes.
>
>
>>> >> Note that raw DEM data has no inherent coloring so it doesn't really mean
>>> >> anything to say "so that the actual .tif grayscale colors are not
>>> >> stretched
>>> >> at all" in this context.
>>>
>> >
>> > I tryed converting my 8bit.tif to 8bit.raw,
>>
> Two issues. First, when I said raw I wasn't so much speaking of a file
> format, but rather of "dem data as typically provided by data providers
> before being processed into special visualization form, like a shaded
> relief". Second, gdal_translate does*not* decide on file format based
> on file extensions, so you just produced a TIFF that happened to have
> the extension .raw.
>
> > then back to an 8 bit.tif, but i
>
>> > still always end up with a .aux.xml file even with the .raw route. In other
>> > words, any method I try, I always end up with an image that is correctly
>> > seen my GIS programs, but incorrectly seen by photoshop. I need the correct
>> > grayscale in photoshop so that I can interactively make new RGB color
>> > gradients that use the elevation informaiton. I am definitely missing a
>> > concept somewhere along the way... The way I see it, its the .aux.xml file
>> > about color that I want embedded into the .tif instead. Is this what is
>> > meant by "applying a color table"?
>>
> I don't know what photoshop does, and you haven't given any details on the
> nature of the file (such as a gdalinfo or tiffinfo report). I am really
> not sure I can help you since the issues seem mostly to be "how do I get
> photoshop to display things the way I hope it will", and this isn't a
> photoshop mailing list.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up | Frank Warmerdam,
> warmerdam at pobox.com light and sound - activate the windows |
> http://pobox.com/~warmerdam and watch the world go round - Rush |
> Geospatial Programmer for Rent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100223/2227d80a/attachment-0001.html
More information about the gdal-dev
mailing list