Does it make sense to round-trip ImageSpec metadata when saving? #3693
Replies: 6 comments 3 replies
-
Hi all,
I can't think of a situation where round tripping wouldn't be desirable.
If a file was saved with data, one assumes it is for a reason, and it's
likely that within a VFX pipeline, for instance, that round tripping of
data is essential to ensure efficient automation for tools across the
pipeline.
Saving a file and getting different metadata could cause issues for
pipelines that use such metadata to make decisions up and down a pipeline.
At the very least, if the weight of public opinion is against metadata, an
option should definitely be provided to allow the user to keep it.
…On Tue, 29 Nov 2022 at 15:17, Jesse Y ***@***.***> wrote:
Imagine an app that first loads a particular image using OIIO. As part of
loading it dutifully copies the loaded spec's extra attributes for
display/informational purposes. It'll copy over things like "DateTime",
"planarconfig", "tiff:Compression" and "compression" etc.
Now the user of this app decides to save this file back out. Maybe in the
same format, maybe in a completely different format.
It seems like an app should not carry these prior saved attributes during
the save regardless of destination format. Are there any situations where
round-tripping should be done?
—
Reply to this email directly, view it on GitHub
<#3693>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKWGRMA7OGOITBAQCDD7RTWKV7V3ANCNFSM6AAAAAASOBBJCE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
Luke Emrose
aka *evolutionary theory*
www.evolutionarytheory.com
www.soundcloud.com/evolutionarytheory
www.reverbnation.com/evolutionarytheory
http://www.facebook.com/pages/evolutionary-theory/110717958952413
|
Beta Was this translation helpful? Give feedback.
-
In general, we've always tried to propagate the metadata from input to output. Though in practice, few file formats allow arbitrarily named metadata, so in general this won't really propagate anything other than the handful of "canonical" metadata that it tries really hard to understand, for example it knows that the "ImageDescription" field of TIFF should carry through to the "comments" block of a JPEG. OpenEXR is one of the few formats (maybe the only one?) that supports truly arbitrary name/value metadata that isn't defined by the spec or some extension like Exif, so it's the only one that is in any real danger of "accidentally" passing on something that really shouldn't be propagated between files of differing formats. And for that case, we do (as I said in the earlier comment) at least suppress the propagation of metadata that is prefixed by the name of any other known image file format, which are assumed to be items that it would only make sense to propagate to output files of the same file format as the input (for example, the numerical code of the compression type, or something like "tiff:RowsPerStrip" which is extremely specific to the way TIFF files are organized). As another exception to propagation, some ImageSpec metadata items that are prefixed with "oiio:..." are understood to be hints to the writer, not real metadata to be saved in the file, and a few that start with "openexr:..." are also hints, or have some special meaning only to the exr writer. |
Beta Was this translation helpful? Give feedback.
-
It seems that while OpenEXR filters the values, some other formats do not? I have a .png here with .tiff metadata :) ... and I see that there's a PR with some explanation for the "DateTime" field. Ultimately though, the confusion really started when "compression" and "oiio:UnassociatedAlpha" values flowed between formats while I was debugging. The code was going to re-set those fields to something appropriate later on but those still worry me. |
Beta Was this translation helpful? Give feedback.
-
I'm not even sure what you mean by "png with tiff metadata". Can you give an example? "compression" does propagate, by design. The assumption is that if an input file used compression method that is supported by the output file format, then all other things being equal, the same compression should be used for output. All of the formats, if given a compression for output that they don't directly support, will ignore it and use their "default." "oiio:UnassociatedAlpha" also is probably something you don't want to drop on the floor. Coming from the input, it indicates that the data is NOT premultiplied, and you definitely want to know that when you output, no? Maybe I just need concrete examples. Like an example input file, a specific |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Here's the relevant code which can result in the above .png issue. Strangely using oiiotool directly doesn't do this. I'm not sure what is stripping out those "tiff:" attributes in that case, but using the code itself doesn't seem to do it.
|
Beta Was this translation helpful? Give feedback.
-
Imagine an app that first loads a particular image using OIIO. As part of loading it dutifully copies the loaded spec's extra attributes for display/informational purposes. It'll copy over things like "DateTime", "planarconfig", "tiff:Compression" and "compression" etc.
Now the user of this app decides to save this file back out. Maybe in the same format, maybe in a completely different format.
It seems like an app should not carry these prior saved attributes during the save regardless of destination format. Are there any situations where round-tripping should be done?
Beta Was this translation helpful? Give feedback.
All reactions