Re: CFD: zXIF 2017-0207

12.02.2017 23:10, Cosmin Truta пишет:
> 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"
Ok, but for now I care not about conflict, but if EXIF is safe to copy 
after certain modifications.
At least it's not safe to copy EXIF after cropping as origin for 
coordinates defining subject area may change.

> 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 how do you know that you shouldn't do this again? That correction 
wasn't applied before?
> Also, could you clarify in what context are you talking about gamma?
I'm not talking about exactly gamma, but about any colour transformation 
processing.
Typical ICC Profile usage looks like: source => source ICCP => PCS (XYZ) 
=> dest. ICCP = destination
Destination (and it's ICCP) is out of our scope and ICCP could be any 
transformation to reference.
We may process source data before recording, resulting in: source => 
process => pixels => pixels ICCP => PCS...
Any colour-space information related to "process" or "pixels ICCP" 
should be modified if we modify pixels.
"Source ICCP" information may be kept intact, but only if we have 
separate pixels ICCP.
> 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.
I slightly lost again. Is it "source ICCP" or "pixels ICCP"?
If it is "pixels ICCP" then it should be kept in iCCP and be 
unsafe-to-copy. And same for gamma which duplicate profile.
> 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.
But what if try to do it one small step at time.
Let's try to add at least some simple keywords like:
*Image unique ID
*Related sound file
*Digitized time - or keep 'Creation time' for this and add 'Original time'
*Camera model - this should differ from 'Source' for digitized film 
camera shot
*Camera maker - when it's not possible to parse from 'Camera model'
*Camera serial
*Camera owner

That's why I support eXIF chunk to keep all required information right 
now and prefer it to be unsafe-to-copy to keep motivation to go further.
> 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.
I don't believe MakerNote could be saved other way than "as is", because 
there is no specification on MakerNote and any camera maker could 
specify another format for this tomorrow.
But I believe specified data from CIPA EXIF could be saved more "PNG 
native" way.
Also I think it's not a good idea to rely on unspecified tag in EXIF 
outside of MakerNote, and so doubt such tags should be kept. As well as 
appended archive(rarjpeg) with flash game.

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