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