Re: Endless gamma in eXIf 2017-0119

John Bowler <[email protected]>
Newsgroups gmane.comp.graphics.png.general
Message-ID <CAP7U39-y9+S+bfE-AcM4iYrnW63xP4HN-FqHv8No1KniScc5Ng@mail.gmail.com>
It is sufficient to go back to the "default" PNG behavior; if the
chunk is ancillary and marked unsafe-to-copy then a *conformant*
work-flow will not accidentally preserve now-invalid information.

An eXIF aware editor is obliged to either throw the chunk away,
modifiy it, or (most likely) reconstruct it from scratch.  Digikam
seems to do the latter.

Since even the important, safe-to-copy, metadata, like
copyright/author, is actually *not* safe to copy across all edits I
don't see a compelling argument for preserving it.  *Magick actually
has a partial solution; it extracts the text information into
corresponding PNG text chunks.

John Bowler

On Tue, Feb 7, 2017 at 5:14 AM, Pavel Zlatovratskii <[email protected]> wrote:
> You are looking from the point of practice while I'm looking from the point
> of theory.
>
> You  may experience problems with 'density vs pHYs', but current proposal
> declare solution for them: as eXIf 'may no longer apply to PNG image'
> software should not use EXIF density as long as pHYs present. Ok. (not very
> ok if image without pHYs rescaled, but at least you could write algorithm)
>
> Gamma are used much rare, so it's hard to meet problems. But if you meet
> current proposal does not allow you to write algorithm to solve them.
>
>
>
> And about text: most of EXIF data are 'just informative'. Shutter speed,
> subject location and of course copyright and date(and
> temperature/humidity)are just description, not very useful in image
> processing.
> Using non-registered keywords are prevent software to write such information
> into EXIF. But if there will be registered keywords (or specific chunks not
> with EXIF as-is, but with specific part of it's data) it will be possible to
> do so.
>
> Approving proposal is not only for embed data from JPEG, but also for
> writing this data when some software(or hardware) want to save it writing
> PNG. What I'm talking about 'more native' it's about not to use eXIf chunk
> when all data could be saved with others PNG chunks. So if we register more
> keywords(e.g. for lens, audio file, digitized date) eXIf chunk will be less
> frequently required.
> 06.02.2017 17:45, Glenn Randers-Pehrson пишет:
>
>
>
> On Mon, Feb 6, 2017 at 8:34 AM, Pavel Zlatovratskii <[email protected]>
> wrote:
>>
>> I think yes, but this will cause remove of still valid camera
>> metadata(like lens model, etc).
>>
>> Such dilemma caused by eXIf's 'image header within image header' nature...
>>
>> That's why using EXIF is good only as fast solution, more PNG-native way
>> to save data from EXIF still required.
>
>
> Besides the hex-encoded-Exif-in-zTXt, ImageMagick writes much of the
> Exif information in separate tEXt or zTXt chunks, each containing the
> information from one Exif tag.  But I don't think there is any attempt to
> read those back in to  a new image; they are just informative.  It's a
> bit of a mess, with redundant storage of various pieces of information,
> that can become invalid. I haven't actually seen the problem with gamma,
> but I have seen problems with Exif "density" conflicting with PNG "pHYs"
> and with the ImageMagick convert "-resolution" option.
>
> Glenn
>
>
> ------------------------------------------------------------------------------
> 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
>
>
> --
> 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
>



-- 
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
_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.