Re: CFD: zXIF 2017-0207
Pavel Zlatovratskii <[email protected]> Fri, 10 Feb 2017 17:29:23 +0300
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Organization | TB.Budget |
| Message-ID | <[email protected]> |
10.02.2017 10:07, Cosmin Truta пишет: > As I have already stated in my "yes" vote for eXIf, I would not > support an unsafe-to-copy form in any incarnation. My opinion is about inverse: I rather support unsafe-to-copy than safe-to-copy chunk(I could support some ways of safe-to-copy, but prefer not to do this). So I feel myself obliged to explain my position. At first I don't like idea that 'raw exif' chunk will be final and main way to keep camera metadata. EXIF is not 'container with camera metadata', it is full-featured image header with it's own logic of keeping properties. Sometimes EXIF duplicate PNG chunks and of course specification of 'full-featured Exif' may slow down proposal of keeping separate properties kept in EXIF. Like: *Why do we need chunk with geographic position? We have eXIf. *Why do we need chunk with lens specification? We have eXIf. Or even further: *Why write pHYs? We have eXIf. *Why write copyright tEXt? We have eXIf. Ok. I over-dramatise. I don't believe such problems will occur. But if there is way when even such problems couldn't be possible, I prefer it. And unsafe-to-copy eXIF(zXIF) is look like such way for me. Of course if there will be future proposals about keeping data from EXIF (I will make at least one simple soon, I promise!) > The EXIF structure has hundreds of safe-to-copy fields, many of which > are highly significant; and two unsafe-to-copy fields (thumbnail and > preview image), both of which are redundant and therefore > informationally insignificant. There are more than two: thumbnail, gamma, orientation, subject location, custom processing... I'm not sure why white point and chromaticities described as safe-to-copy (may be because they're marked as 'legacy' and don't supposed to rely on). > Any application that recognizes thumbnails and previews may (and > probably should) regenerate them at any time, as instructed by the > specification; or may even drop them, just as it may drop any other > EXIF fields not applicable to PNG (such as, for example, JPEG-only > fields). Modification of EXIF is not always as safe as it seems. E.g. modification may break 'Maker Note' as it may(or may not) depend on it's position in EXIF. > I believe that adoption for PNG in the area of digital photography > cannot happen if the important photographic information is preserved. > What exactly should make photographers switch from TIFF to PNG? > Deflate-compressed TIFF has been working just fine. Even uncompressed > TIFF (where compression is not important) is equally fine. That's why PNG should have better metadata. And it's impossible if we use same EXIF. With EXIF we may save no more than TIFF, so if compression doesn't matter there is no reason to use PNG when you are familiar with TIFF. -- Pavel Zlatovratskii [email protected]; [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