Re: CFD: zXIF 2017-0207
Cosmin Truta <[email protected]> Sun, 12 Feb 2017 15:10:51 -0500
| Newsgroups | gmane.comp.graphics.png.general |
|---|---|
| Message-ID | <CAAoVtZxXGgUr=7jH80bO24+CbBmEFv380d5ebEO30HoCDu5gdA@mail.gmail.com> |
On 12 February 2017 at 12:53, Pavel Zlatovratskii <[email protected]> wrote: > Well, I see I had some misunderstanding about EXIF gamma, but I still > think it should be unsafe-to-copy(like mentioned in CIPA 2016). See the following statement in the draft document: "It is beyond the scope of this specification to resolve potential conflicts between data in the eXIf chunk and in other PNG chunks" Also, could you clarify in what context are you talking about gamma? Because sRGB does not have a gamma, only AdobeRGB has one. In sRGB, the transfer function is not a gamma function, but only an approximation of it (with an approximate value 2.2). For this reason, in all of my photos, I only see a gamma value when I save the image in the AdobeRGB profile, and I see no such thing when I save the image in the sRGB profile. Also for this reason, the PNG specification says the following, explicitly: "When the sRGB chunk is present, it is recommended that decoders that recognize it and are capable of colour management [ICC] ignore the gAMA and cHRM chunks and use the sRGB chunk instead." and: "When the iCCP chunk is present, PNG decoders that recognize it and are capable of colour management [ICC] shall ignore the gAMAand cHRM chunks and use the iCCP chunk instead and interpret it according to [ICC-1] and [ICC-1A]." So: There is no gamma field in sRGB EXIF images, because it strictly doesn't apply. (There is gAMA in sRGB PNG, because PNG allows it to loosely apply, but we're talking about EXIF here.) There is a gamma field in AdobeRGB EXIF images, but that is a redundant piece of information, because the ICC profile that comes with AdobeRGB images already have that. You may add a gamma field of value 2.2 to an sRGB image, but it will change nothing, because it is a redundant. You may add a gamma field of value other than 2.2 to an sRGB image, but that would be incorrect. You may add a gamma field of any value to any image that is not an sRGB image (and has a custom ICC profile, AdobeRGB or anything else). But again, that would be redundant. A gamma value only has effect when you have no other color profile information. I would like to see a sample image with that sort of EXIF data (i.e. with gamma but with no color profile, and not even a reference to a color profile). Being opposed to an EXIF chunk on the grounds of the importance of gamma, an utterly redundant field for all practical purposes that I'm aware of, is just not the best thing to do. (Although you are entitled to your opinion, of course.) >> As a further example, take a look at Google WebP container >> specification. Like the current PNG eXIf design that comes in addition >> to our current colorimetry info, they have designed provisions for >> both EXIF and ICC. >> https://developers.google.com/speed/webp/docs/riff_container > Google prefer does not develop their own way to keep metadata and rely > on EXIF(XMP). Yes. That's why WebP is technically more desirable for digital photography applications than PNG and JPEG combined. It does lossy compression that's better than JPEG, and lossless true-color compression that's better than PNG. And it does ICC, EXIF and XMP. It really does everything that's needed. With PNG/EXIF, we try to compete with TIFF/EXIF, and to a lesser extent (due to lack of popularity but definitely not due to lack of merit), with WebP. > PNG prefer to use own way to keep metadata. That's very important > difference for me. And that's why I prefer PNG(and don't want it to > morph into PNG image + EXIF). In theory, that would be nice :-) In reality, there have been a few attempts in the past, all of which failed. We have no expertise to define them, Pavel, and no spare time to do it for the hundreds. We need people to do *work* to define each one of them. We need people to have *knowledge* of what should go into each one of them. Or else, we will end up remaining where we currently are, with no way to store EXIF data for reliable retrieval. So if you come and tell us that's not what we should do, we should do it in this other harder way, it would be nice to bring some knowledge of your own to the table. Reading the CIPA document is far from sufficient. >> You are right in principle, but it's impossible in practice. [...] > It's about 80 if we're talking about EXIF IFD. The bulk are in the MakerNotes. The semantics are in the various technical and scientific documents. It's not just many fields; it's a huge amount of information behind them, also. > And these 80 attributes is lack some properties which are saved by > camera makers within 'MakerNote': manual or auto focus(and so we need > difference between measured subject distance and set focal plane > distance); type of auto focus; flash energy compensation; age of camera > (in days or in shots)... Right. A lot more. And some of them are fundamentally important, such as lens distortion information. > By the way, I've not found in EXIF specification marker that lens > distortion was removed (like "de-fish" in your example). Is there any? Of course! There is the lens make and model, then there is the aperture and focal length used at the time of capture, and from this, query the database of lenses and apply the correction based on the information found. This is how DxO tools do it, for example. (And no, I didn't say that it was easy.) And then, there are also lens-specific (therefore manufacturer-specific) parameters in the MakerNotes. For informative purposes, have a look at this article: http://www.kenrockwell.com/tech/dxo/optics-pro.htm But even more importantly, please do some in-depth studying on this matter and understand how difficult it is. We can barely go forward with this compressed-vs-uncompressed disagreement, or safe-to-copy-vs-unsafe-to-copy disagreement; do you think we will have any better chances with these very very many EXIF fields, some of which are very very hard to understand? I challenge you to understand the lens distortion parameters in MakerNotes, at the very least, and explain to us how would you propose to standardize that thing alone in a PNG chunk. And after that, extrapolate your effort to the plethora of other fields found in EXIF (and I emphasize on "found", which is way beyond what's written in CIPA-2016). Sincerely, Cosmin ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot