Re: DRAFT: eXIf 2017-03-02

Cosmin Truta <[email protected]> Mon, 6 Mar 2017 19:29:39 -0500
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAAoVtZxdinK-RpE8iDg2gnfS4tC5DmYgBboZ503=a6tL5uFchg@mail.gmail.com>
On 6 March 2017 at 16:05, Pavel Zlatovratskii wrote:
> Well, I agree about compatibility, but compatibility does not mean
> "repeat JPEG header as-is is only solution".

Nobody said it's the only solution, but this is, nonetheless, the
solution that makes the most sense.

Consider an EXIF-enabled software or hardware imaging application
that handles multiple image formats: TIFF, JPEG, JPEG-XR, WebP, PNG,
possibly others. Rather than have different code paths for each
format, the application can offload the EXIF structure processing
to the same EXIF (software or hardware) module. The EXIF processing
already works within TIFF, JPEG, WebP, etc. in the exact same way,
and PNG should not be any different. Yes, it can be different; but
no, it shouldn't be. Neither in software, and not even less so in
embedded hardware.

Among other things, an important goal of ours is to maximize our
chances that a digital camera manufacturer will ever pick up this
specification and release a digital camera with PNG output.
We have to consider a hardware engineer's constraints of
minimalistic circuitry when doing so. Reinventing the design, just
for the sake of reinventing the design, is not going to help.

Sincerely,
Cosmin

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford