[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20000807: Navigation standards for PNG compressed imagery (cont.)

>From: address@hidden
>Organization: Planetary Data, Incorporated
>Keywords: 200007311815.e6VIF8T09707 PNG image compression navigation

Stonie,

>It's good to hear from you; I'd be glad to share with you what we've
>played with so far . . .

OK, thanks.

>The libpng allows for a couple of extraneous fields - namely text and
>compressed text.  Maybe other ways of doing all this (as you certainly
>pointed out with the Unidata solution), but that's where we went . . .

I like the idea of incorporating "extraneous stuff" like navigation
in blocks that will be ignored by standard PNG display applications.
This eliminates the need to strip off the header before being able
to display images.

>The tEXt chunk is limited in that you can only use "text" - and a null
>in the string will kill most apps that use libpng.  So, I guess you
>could convert all the fields of a header to ascii and chunk as text,
>but you've defeated one of the purposes of using png (compression) by
>doing that.  We didn't go down that road . . .

Right.  I wouldn't pursue this route at all.

>The zTXt, however, can be fooled to work.  Currently, setting the
>compression method byte in a zTXt chunk to something other than 0 will
>cause most apps to skip over the chunk entirely, so that a "standard"
>viewing software will get to the data and display it without any
>problems.  That isn't to say we "broke" png for later implementations
>by using - say 5 - as a code for us to know that we are using GINI
>compressed header.

OK.  I would be wary of the possibility of having to modify something
down the road if/when the standard starts to define what non-zero
compression bytes mean.

>In the case of GINI, we just take the 533 header, compress it with
>zlib,  and chunk it as zTXt.  But _do_not_ set the compression byte to
>0 (meaning zlib) so that apps won't try to uncompress binary data.

OK.  So you are leaving the format of the GINI header alone.  From your
original note to Tom W., I had assumed that you might try to come
up with a formalism for storing general navigation information.  Another
group is doing this for TIFF.  You might be interested in the GeoTIFF
effort, one site for which is:

http://www.remotesensing.org/geotiff/geotiff.html

A good reference page for file formats for storing imagery can be found
under: http://www.remotesensing.org/formats/.  Forgive me if you are
already aware of this sort of work in the open source community.

>As simplistic as that is, I tagged Tom W. because GINI is not
>necessarily the best header - and just wanted to see if the community
>was coming up with a "standard".

So, you are interested in formalisms for storing georeferenced data.
Good.  I think that this is an area of active interest in the greater
community.  Some of the mailing lists accessible under
http://www.remotesensing.org/formats should be of interest.

>Also, as png supports multiple png chunks, it could be broken up so
>that a common navigation header is followed by specific navigation
>chunks depending on the projection.  All sorts of fun stuff.

OK.

>What do you think?

You have chosen an interesting approach.  I will have to play around
with implementations before I have anything really serious to say, but
I would appreciate being kept in the loop when you get brainstorms.

Talk to you later...

Tom