Re: Endless gamma in eXIf 2017-0119

Pavel Zlatovratskii <[email protected]>
Newsgroups gmane.comp.graphics.png.general
Organization TB.Budget
Message-ID <[email protected]>
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] 
> <mailto:[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 scondo-JGs/[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
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.