20000731: Navigation standards for PNG compressed imagery

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

Stonie,

Tom Whittaker forwarded you note regarding storage of navigation
parameters in PNG compressed imagery.  Since I am the person in Unidata
who modified the compression scheme for images in the Unidata-Wisconsin
datastream from a delta encoding scheme (an old McIDAS "standard") to
PNG, Tom figured that I might have some input on this subject.

When Chiz (Steve Chiswell) developed a PNG compression/uncompression
scheme for NOAAPORT GINI imagery, and when I did the same for imagery
in AREA file format, we decided to keep the original file headers in an
uncompressed format.  Our thinking was that the largest part of the
file was the image data itself.  The header information for GINI
imagery amounts to only 533 bytes; the amount of header information for
imagery stored in AREA file format is more, but not by an awful lot.
Speaking from the McIDAS perspective, leaving the headers in the clear
allows one continue to use McIDAS listing applications on PNG
compressed files, so it is a nice fit.  The only drawback to not
compressing the file headers is that one has to strip these before they
can be displayed by things like ImageMagic and other display routines.

Nonetheless, I am interested in keeping abrest of your (Planetary Data)
thinking about how various blocks supported in the PNG standard may be
used to encode navigation information.  Is your intention to be able to
support a wide variety of navigation models?  Do you have a strawman
for this yet?  I would be interested in conversing with you on these
issues when time permits.

Cheers,

Tom Yoksas

>-------- Original Message --------
>Subject: PNG compression of imagery.
>Date: Mon, 31 Jul 2000 10:51 +0100
>To: address@hidden
>CC: address@hidden, address@hidden
>
>Tom,
>
>I don't know if you remember me from TWC; I worked with Dave
>Houtz and the McIdas implementation that PRC was supposed to
>provide a few years back.  Obviously, I've moved on . . .
>
>Anyway, I see that IDD is converting over to PNG delivery of
>imagery from SSEC.  We have implemented a PNG format for imagery
>ourselves (PDI) - mostly for storing GINI formatted data - and
>wanted to know if you would like to collaborate on a standard for
>navigated imagery in PNG.
>
>Currently, we are using the tEXt or zTXt chunks within PNG for
>storing the navigation information:
>
>http://www.libpng.org/pub/png/spec/PNG-Chunks.html
>
>I guess the "standardization" effort would be arriving at some
>symbology within those text or compressed text chunks - unless
>you think that another chunk within PNG would be better suited
>for storing the navigation information.  If interested, please
>let me know.  I think it's better for the community to have a
>standard that is open, rather than all these data type silos -
>AREA, netCDF, GINI, etc.
>
>I look forward to hearing from you . . .
>
>Stonie Cooper,
>Science Officer
>Planetary Data, Incorporated
>1820 N Chestnut Grove Drive
>Marietta, GA  30066


>From address@hidden Mon Aug  7 13:35:26 2000
>To: "Stonie R. Cooper" <address@hidden>
>cc: address@hidden, tomw <address@hidden>,
>   Declan Cannon <address@hidden>,
>   Timothy Wells <address@hidden>
>Subject: 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

>From address@hidden Mon Aug  7 13:13:11 2000
>Subject: Re: Navigation data in png.
>Date: Mon, 7 Aug 2000 19:01:03 +0000

Glenn,

Thanks for the rapid replay; let me play around with your binary->ascii->zTXt
idea first.  There is a little resistance to this, mostly because nobody wants
to add yet another layer of "decoding" for apps that actually take advantage of
the navigation info.

The navigation info that we store is in a format that the National Weather
Service has created; it's straight binary data with 1, 2, 3, and 4 byte fields
(along with some arrays).  Your method (as I diagrammed above) has a very
attractive bonus - we can rid ourselves of big endian/little endian compile time
exceptions.

Currently the navigation headers are sent big endian; anyone with a little
endian box - i.e. DEC, PC's, etc. has to have code to swap bytes.  It's not a
big deal, but it adds portability complexity to software.

If we do things as you point out, though, using the ascii will avoid the
big/little endian issues, and we can compress with zlib to boot, to get the
compression we need.

Great idea!  Thanks.

Stonie

On Mon, 07 Aug 2000, Glenn Randers-Pehrson wrote:
> At 06:35 PM 8/7/00 +0000, you wrote:
> >Glenn,
> >
> >I work for a meteorology company that spends a lot of time working databasing
> >issues.  One of the tacts we have taken to compress satellite data is to use
> >the png format.
> >
> >There is a parallel effort by the academic community; it seems png is a
> natural
> >for the purpose of compressing satellite data.  At issue is somehow
> placing the
> >navigation information in the png.
> >
> >Currently, we are using zTXt chunks, and setting the compression byte to 5
> >(something other than 0, so apps don't attempt to un-libzip the data), and
> thus
> >storing the data that way.  
> >
> >The parallel academic effort does not attempt to store the navigation data in
> >the png, but actually concatenates the navigation header and the png
> compressed
> >data.  This is problematic in that the navigation header has to be
> stripped off
> >before common graphics viewing software will open the png data.
> >
> >I guess, what I am looking for is some insight to standards for how the
> >compression method byte for the zTXt chunk will be used; we don't want to set
> >ourselves up to "break" future implementations.  Or is it possible to
> appeal to
> >the powers at be to set a value in the compress method byte that will always
> >mean "other binary data"?
> 
> Well, I'm sure the response from the PNG group will be something along the
> lines of "Oh no oh my god oh no..."
> 
> It's better to define a private chunk along the lines of "saTd"
> (satellite data) which would have a keyword field, then a compression
> type and finally the data itself, compressed according to the flag.
> 
> Even better is if the data could be converted to a human-readable form
> and then compress that into a regular zTXt chunk.
> 
> For an example of that approach, have a look at the proposal I am currently
> developing for storing digital camera data in PNG text chunks:
> http://pmt.sourceforge.net/exif
> 
> >I appreciate any information - and very much appreciate the work that the
> >libpng folks have put to the community as a whole.
> 
> Do you have an example of the type of data you are trying to store?
> Is it similar to the "world coordinate system" for storing geographic
> information?
> 
> Still another (PNG-compliant) method of storing binary data is to use
> uuencode or binhex to represent the binary data in printable form, then
> include that in a zTXt chunk.  The compression won't be quite as efficient,
> but depending on the amount of data involved, that might not matter.
> 
> I'll be happy to work with you to develop a good method of storing you
> data.
--
Stonie R. Cooper,
Science Officer
Planetary Data, Incorporated
1820 N. Chestnut Grove Drive
Marietta, Georgia  30066
770.977.8189

>From address@hidden Mon Aug  7 13:23:01 2000
>To: "Stonie R. Cooper" <address@hidden>
>From: Glenn Randers-Pehrson <address@hidden>
>Subject: Re: Navigation data in png.
>Cc: Unidata Support <address@hidden>,
>   address@hidden, tomw <address@hidden>,
>   Declan Cannon <address@hidden>,
>   Timothy Wells <address@hidden>

At 07:01 PM 8/7/00 +0000, you wrote:
>Glenn,
>
>Thanks for the rapid replay; let me play around with your binary->ascii->zTXt
>idea first.  There is a little resistance to this, mostly because nobody
wants
>to add yet another layer of "decoding" for apps that actually take
advantage of
>the navigation info.
>
>The navigation info that we store is in a format that the National Weather
>Service has created; it's straight binary data with 1, 2, 3, and 4 byte
fields
>(along with some arrays).  Your method (as I diagrammed above) has a very
>attractive bonus - we can rid ourselves of big endian/little endian
compile time
>exceptions.

If you are referring to the method I'm proposing for Exif, yes.  If you
are referring to the binary -> hex -> zTXt, no; that would preserve
the endian condition of your binary data.

The Exif method (converting to human-readable) is
indeed a lot of work but I think it's much better in the long run if
human readers might have use for the information.  That's certainly true
of camera data; you are of course a better judge than I if that applies
to your data.

>Currently the navigation headers are sent big endian; anyone with a little
>endian box - i.e. DEC, PC's, etc. has to have code to swap bytes.  It's not a
>big deal, but it adds portability complexity to software.
>
>If we do things as you point out, though, using the ascii will avoid the
>big/little endian issues, and we can compress with zlib to boot, to get the
>compression we need.
>
>Great idea!  Thanks.
>
>Stonie
>
>On Mon, 07 Aug 2000, Glenn Randers-Pehrson wrote:
>> At 06:35 PM 8/7/00 +0000, you wrote:
>> >Glenn,
>> >
>> >I work for a meteorology company that spends a lot of time working
databasing
>> >issues.  One of the tacts we have taken to compress satellite data is
to use
>> >the png format.
>> >
>> >There is a parallel effort by the academic community; it seems png is a
>> natural
>> >for the purpose of compressing satellite data.  At issue is somehow
>> placing the
>> >navigation information in the png.
>> >
>> >Currently, we are using zTXt chunks, and setting the compression byte to 5
>> >(something other than 0, so apps don't attempt to un-libzip the data), and
>> thus
>> >storing the data that way.  
>> >
>> >The parallel academic effort does not attempt to store the navigation
data in
>> >the png, but actually concatenates the navigation header and the png
>> compressed
>> >data.  This is problematic in that the navigation header has to be
>> stripped off
>> >before common graphics viewing software will open the png data.
>> >
>> >I guess, what I am looking for is some insight to standards for how the
>> >compression method byte for the zTXt chunk will be used; we don't want
to set
>> >ourselves up to "break" future implementations.  Or is it possible to
>> appeal to
>> >the powers at be to set a value in the compress method byte that will
always
>> >mean "other binary data"?
>> 
>> Well, I'm sure the response from the PNG group will be something along the
>> lines of "Oh no oh my god oh no..."
>> 
>> It's better to define a private chunk along the lines of "saTd"
>> (satellite data) which would have a keyword field, then a compression
>> type and finally the data itself, compressed according to the flag.
>> 
>> Even better is if the data could be converted to a human-readable form
>> and then compress that into a regular zTXt chunk.
>> 
>> For an example of that approach, have a look at the proposal I am currently
>> developing for storing digital camera data in PNG text chunks:
>> http://pmt.sourceforge.net/exif
>> 
>> >I appreciate any information - and very much appreciate the work that the
>> >libpng folks have put to the community as a whole.
>> 
>> Do you have an example of the type of data you are trying to store?
>> Is it similar to the "world coordinate system" for storing geographic
>> information?
>> 
>> Still another (PNG-compliant) method of storing binary data is to use
>> uuencode or binhex to represent the binary data in printable form, then
>> include that in a zTXt chunk.  The compression won't be quite as efficient,
>> but depending on the amount of data involved, that might not matter.
>> 
>> I'll be happy to work with you to develop a good method of storing you
>> data.
>--
>Stonie R. Cooper,
>Science Officer
>Planetary Data, Incorporated
>1820 N. Chestnut Grove Drive
>Marietta, Georgia  30066
>770.977.8189
>