I’ve put this in ‘uncategorized’ - but perhaps there should be a category for file specs?
I originally emailed Leia back in September 2018 about “H4V and Quad4v file format specifications?”.
I was sent some docs, which were very helpful, but were incomplete.
So I have two questions:
do you intend to publish these on developer.leialoft.com for all developers?
do you intend to complete the file specifications?
In particularly I’m interested in TIFF/EXIF meta tags. But I’ve also discussed this with others who are interested in all manner of things for both the JPEG’s and the MP4’s. Channels, keyframes, etc.
Let me give a couple of examples.
Using RED Camera, take a 4V and 2D photo. The 4V and 2D have different EXIF/TIFF data, eg:
2d has but 4v doesn’t have: exif:GPS* (exif:GPSLatitude, exif:GPSImgDirection, exif:GPSTimeStamp etc.)
4v has but 2d doesn’t have: tiff:Orientation
2d has but 4v doesn’t have: exif:ExifVersion
4v has but 2d doesn’t have: xmp:CreatorTool
And there are others…
And the tiff:Orientation = “0” regardless of the camera orientation. AFAICT 0 is an illegal value, either the tag shouldn’t exist, or it should be between 1-8.
But without a spec I can’t tell if these are bugs, or intended to identify H4V pictures or what.
Is having GPS info in H4V images a bad thing? Why would RED Player add GPS for 2D photos but not 4V? I tested it - adding GPS to 4V doesn’t seem to break anything… But I’m left wondering what is the meaning of these deliberate meta data differences existing in the ‘reference application’?
If tiff:Orientation isn’t used for determining image orientation, what is? And if I put the ‘correct’ value in that tag, will it break the workflow?
I also can’t identify if I add tags like exif:CustomRendered if it will ‘break’ workflow (eg: cause errors with loading into HoloPix). A standard disclaimer that any tag not explicitly defined in the spec should not affect workflow would solve that…
AFAICT when 4V photos are edited on device in RED Player al the EXIF is removed. I would have thought the logical thing to do what be to retain the EXIF and add exif:CustomRendered to indicate that Bokeh has been added? But that is not really about the file spec, but the implementation of RED Player. But I guess without the spec it’s difficult for me to know if this is intended behaviour or a bug (ie: if Quad4v 2x2 files need meta data or if no meta data is preferred?).
I’ve already seen one case where tiff:ImageWidth / tiff:ImageLength were used and stripping them out of the image caused problems with render on device unless the file was renamed to “fullwidth”. And of course there is the Base64 encoded image in LImage:RightAlbedo etc. which is ‘needed’ for the ‘standard’ H4V files to work…
So I’m left assumng that some EXIF has some meaning, and is critical to the workflow - but no way to determine which EXIF and which parts of the workflow… Except by trial and error… And the GPS stuff is just inexplicable. And that reminds me I need to test the impact of changing tiff:Orientation on RED Player and HoloPix…