Re: Endless gamma in eXIf 2017-0119
John Bowler <[email protected]>
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CAP7U399g+CMXSrPyGgEEQZZvvw0ety-VJMO_HcDj3=ot27=ZiA@mail.gmail.com> |
I think people need to consider this issue carefully when voting, it would also be helpful to know when a voter felt that the issue was decisive one way or the other, just like Pavel did. Certainly there are two possible approaches. The one used in both the eXIf and zXIf proposals allows an EXIF chunk aware PNG editor to store the *original* information even though it may no longer apply. This happens because the "security considerations" section permits it; if that section was not there, regardless of the safe-to-copy bit, an editor would have to ensure the consistency of the information either by updating it or discarding it. This is mandated by the section of the ISO-PNG spec that I quoted. So, by default, the chunk would have to be eXIF (not safe to copy) and editors which supported it would have to either modify the chunk or completely remove it when the image was changed. If you want that vote NO on both proposals. If you want the behavior with Soni L. described and are satisfied that the specification (compressed or not) has adequate description for decoders then you might choose to vote YES on on or the other, or both, proposals. Notice that the current proposals are not intended to prevent the use of the image-related metadata from the chunk; rather it is the case that it may be outdated and, as in Glenn's edited examples, there may be no indication of this. As Soni L. observed: >Shouldn't eXIf be considered "sensor/camera data" and thus only useful for ppl who >know what they're doing, and not automatically mangled into the image? Yes; that's how I see it. It's used to allow a digital camera image to be expressed in PNG and the workflows which use it will be similar to the ones which use EXIF in JPEG or TIFF. Exactly the same problem of maintaining it without updating it exists in JPEG and TIFF too, and of course it already exists in the current zTXt encoding. -- John Bowler <[email protected]> +1 (541) 450-9885 PO BOX 3151 KERBY OR 97531-3151 USA ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot