Re: EXIF support in PNG

I've combined the two proposals into one document.  For voting and
discussion purposes, call the proposed chunk "uxIf" (uncompressed)
and "zxIf" (zlib-encoded).

The document, along with some additional boilerplate, is available
at ftp://ftp.simplesystems.org/pub/png-group/documents/

This document describes two variants of a special-purpose chunk type
that has been proposed for use in various PNG (Portable Network Graphics)
and related multi-image applications.

It has not yet been approved for registration by the PNG developers,
and therefore is experimental and its format is subject to change.
The proposed chunk is (with an unregistered name or names that can be
used in test implementations shown in parentheses):
eXIf (exIf, uxIf, zxIf).

Note that as specified here, the "uxIf" proposal is a subset of
the "zxIf" proposal; a zxIf-decoder will be able to decode both
variants.

PNG uxIf (raw EXIF) proposal
============================

   It is proposed to add the following section to the document "Extensions
   to the PNG 1.2 Specification, Version 1.2.0"

  3.6. eXIf EXIF profile

   The four-byte chunk type field contains the decimal values
    101 88 73 102 (ASCII "e X I f")

   When present, the eXIf chunk contains contains EXIF metadata that is
   compatible with specifications issued by CIPA, "Exchangeable image file
   format for digital still cameras" [CIPA DC-008-2016] or its successors.
   See https://www.media.mit.edu/pia/Research/deepview/exif.html

   The eXIf chunk contains an EXIF profile in a raw format:
         Data: length bytes where "length" is determined
               by the chunk "length" field, containing a
               raw EXIF profile.

   At most one eXIF chunk shall occur in a PNG datastream.
   There are no ordering constraints upon the position of the eXIf beyond
   those imposed by the PNG specification, i.e., if present, the eXIf
   chunk may appear anywhere between the IHDR and IEND chunks except
   between IDAT chunks.

PNG zxIf proposal
============================

   It is proposed to add the following section to the document "Extensions
   to the PNG 1.2 Specification, Version 1.2.0"

  3.6. eXIf EXIF profile

   The four-byte chunk type field contains the decimal values
    101 88 73 102 (ASCII "e X I f")

   When present, the eXIf chunk contains contains EXIF metadata that is
   compatible with specifications issued by CIPA, "Exchangeable image file
   format for digital still cameras" [CIPA DC-008-2016] or its successors.
   See https://www.media.mit.edu/pia/Research/deepview/exif.html

   The eXIf chunk contains an optional "mode" byte followed by an EXIF
   profile in a raw format or in a zlib-encoded compressed format:
         Mode: 1 byte
               0: the remaining length-1 bytes of data make up a
                  zlib-encoded EXIF profile written in accordance
                  with chapter 5, "Deflate/Inflate Compression"
                  of the PNG specification version 1.2 (which
                  is Clause 10.1, "Compression method 0" of the
                  ISO PNG specification).
              69: (ASCII "E") the remaining length-1 bytes of
                  data, combined with the byte "E", make up a raw
                  uncompressed EXIF profile
              Other values of Mode are reserved for other
                  compression methods which might be defined
                  in a future version of this specification.

         Data: the remaining length-1 bytes where "length" is
               determined by the chunk "length" field

   At most one eXIF chunk shall occur in a PNG datastream.
   There are no ordering constraints upon the position of the eXIf beyond
   those imposed by the PNG specification, i.e., if present, the eXIf
   chunk may appear anywhere between the IHDR and IEND chunks except
   between IDAT chunks.



On Wed, Jan 4, 2017 at 7:50 PM, Willem van Schaik <[email protected]> wrote:

>
> Glenn wrote:
>
>  > I don't think so.
>
>
> wow Glenn, you're stubborn ... :-)
>
> the one byte header I don't really like but I can easily live with
>
> I thought we were still talking about a header with some form of
> readable description, I didn't like that idea but just an extra byte is
> no issue
>
> regarding compression or not (you know my preference :) here will be my
> voting strategy:
>
> 1) when we're voting including compression my vote on the proposal will
> be NO
>
> but
>
> 2a) the proposal gets accepted
>
> 2b) the proposal gets rejected because too many others don't like
> compression
>
> 2c) the proposal gets rejected but the majority agrees on compression,
> in which case I will switch camps and not object against compression
> anymore
>
> Alternatively, maybe easier, we vote on two proposals that are nearly
> identical, one with and the other without compression. And we simply
> agree with each other that only one can survive, depending on the number
> of votes.
>
> my $0.02 ...
> Willem
>
>
>
>
> --
> Willem van Schaik
> [email protected]
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> png-mng-misc mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/png-mng-misc
>

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc