H4V and Quad4v file format specifications?

1

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:

  1. do you intend to publish these on developer.leialoft.com for all developers?

  2. 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…

1 Like
2

Hey Arthur, I don’t have the answer to your questions, but do find the documents on specs interesting. Is this something you could share with me?

Also, nice name :wink:

1 Like
3

Hi Arthur, EXIF is separate from H4V metadata tags used for 4V. It is not used specially for H4V rendering. You can find the EXIF specification online (ie https://www.exif.org/Exif2-2.PDF).

“I also can’t identify if I add tags like exif:CustomRendered if it will ‘break’ workflow.” This is disallowed by the EXIF standard.

4 Likes
4

@arturojreal - I thought the same when I saw your name :sunglasses:

Since the docs were sent directly to me, no I don’t think I can just distribute them. The best place would be on the developer portal. No response from Leia on that part of my question.

1 Like
5

I was not being very precise in my language - I’m using EXIF generally to discuss TIFF/EXIF/XMP etc. I’m frequently quite pedantic myself, but I try and limit it to where it’s useful to the discussion. I don’t see here how it could be, since it’s all read/written using the one library (generally). I thought that was pretty clear in the context of my question. Yes I understand the H4V meta data tags for 4V are in XMP, which is in a different record to TIFF and EXIF etc. etc. - but is all read and written from the same library, the same way, using the same calls.

I already listed a case where a specific EXIF tag does affect functionality (tiff:ImageLength) so saying it doesn’t nicely highlights the importance of an updated file spec that includes the EXIF tags. I think you just made my case for me.

What part of my question made you think I’m unfamiliar with the standard? Perhaps it’s the part where I mention that the RED Camera use of Tiff:Orientation is not supported by the spec? You can check on page 18 of the spec if you like. ‘Other’ values (than 1-8) are ‘reserved’ and RED Camera writes ‘0’ (for H4V images, but not 2D images).

I don’t understand your comment, sorry.

I believe that the EXIF standard implies that programs should ignore/preserve tags that you are not using. Is that what you are referring to?

But the CustomRendered tag is specifically one that states ‘the reader is expected to disable or minimize any further processing’ when it is set (see page 42), which taken literally would break workflow. ie: if Leia have plans to start setting (or reading) exif:CustomRendered, then if I am already setting it on images, we could end up very confused. Hence the question.

6

EXIF is separate from H4V metadata tags used for 4V.

I was not being very precise in my language - I’m using EXIF generally to discuss TIFF/EXIF/XMP etc. I’m frequently quite pedantic myself, but I try and limit it to where it’s useful to the discussion. I don’t see here how it could be, since it’s all read/written using the one library (generally). I thought that was pretty clear in the context of my question. Yes I understand the H4V meta data tags for 4V are in XMP, which is in a different record to TIFF and EXIF etc. etc. - but is all read and written from the same library, the same way, using the same calls.

Sorry, I misunderstood you. From my perspective, Extended XMP and EXIF are different, and I am not used to having XMP referred to as EXIF. For the purpose of this discussion, let’s use the term “metadata” if referring to TIFF/XMP/EXIF.

It is not used specially for H4V rendering.

I already listed a case where a specific EXIF tag does affect functionality (tiff:ImageLength) so saying it doesn’t nicely highlights the importance of an updated file spec that includes the EXIF tags. I think you just made my case for me.

I don’t mean to claim that EXIF tags will not affect H4V rendering, just that we (Leia) do not specially set any EXIF values for the purpose of 4V rendering. Of course, as you highlight, some EXIF tags will affect image rendering (4V or 2D).

You can find the EXIF specification online (ie https://www.exif.org/Exif2-2.PDF).

“I also can’t identify if I add tags like exif:CustomRendered if it will ‘break’ workflow.” This is disallowed by the EXIF standard.

I don’t understand your comment, sorry.

Sorry, I misunderstood your question; please disregard the previous answer.

While I understand it would be useful to document this with this level of detail, it is not currently a business priority. Thank you for your understanding.

7

Regarding the missing GPS data and the illegal EXIF data, it would be helpful if you could submit this feedback using the User Feedback app (that component is maintained by RED, not Leia).

8

(In general, anything EXIF is RED, anything XMP is Leia).

2 Likes
9

done.

2 Likes
10

Thanks Arthur!

1 Like
11

@nic bumping this topic because there is a new ‘Leia binary image format’ in RED Player 1.0.6.

Can I please have a spec? I don’t need a lot of detail. A sample file would be helpful.

I assume you are ditching XMP and using either:

  • extra channels (depth map)
  • sequential image (like MPO format)