harvard-lts / fits

File Information Tool Set
http://fitstool.org
GNU Lesser General Public License v2.1
92 stars 46 forks source link

Add Projection flags for 360° Videos #189

Open DonRichards opened 5 years ago

DonRichards commented 5 years ago

When fits is ran on 360° Videos the output leaves out the projection key value. If I run exiftools on the video file it output everything including the "projection type"

$ exiftools my_video.mp4
ExifTool Version Number         : 11.11
File Name                                 : MP4.mp4
....
Projection Type                       : equirectangular
...

Projection value are one of these; equirectangular, cubemap, cubestrip, panorama, and stereoequip. I believe it's just missing from this "exiftool_video_to_fits.xslt" but I'm honestly out of my depth with fits.

Is it possible to have this included?

DonRichards commented 5 years ago

This is the fit.sh output for the 360° video file as an example output.txt

DonRichards commented 5 years ago

This is the complete exiftool output for the same video exiftools_output.txt

daveneiman commented 5 years ago

Don,

I’ve taken a look at your output and, hopefully, this extensive explanation will help resolve some of your questions.

There are a few different things going on with FITS when processing MP4 files, not necessarily ideal from the FITS perspective.

1) First of all, the reason that there is no Exiftool metadata in the output.txt file (FITS output file) is that Exiftool is turned off for MP4 files by default in the fits.xml file that comes with the FITS distribution. (fits.xml is in the xml directory.) This is evident by looking at the output.txt file within the <statistics> element at the bottom of the file. Take a look at this line which shows that Exiftool wasn’t run on the file: <tool toolname="Exiftool" toolversion="10.00" status="did not run" /> Exiftool can be turned on by modifying the <tools> section of the fits.xml file. Modify the <tool class="edu.harvard.hul.ois.fits.tools.exiftool.Exiftool"… /> element by removing ‘mp4’ from the ‘exclude-exts’ attribute section of this element.

2) HOWEVER, the above modification to fits.xml will NOT result in Exiftool output showing up in the <metadata> section of the FITS output file in this particular scenario. (See below for a somewhat involved explanation.)

3) As an intermediate step you can turn on the output of each tool embedded within FITS before this output is (possibly) included within the FITS <metadata> section. You can see this generated tool output by editing the fits.xml file. Change the following element value to ‘true’: <display-tool-output>false</display-tool-output> This will result in a very long <toolOutput> element containing output from each tool being run by FITS. <toolOutput> will be after the <metadata> element and before the <statistics> element.

4) There is a shortcoming in FITS that has existed for quite some with regard to MP4 files (and possibly other video file formats). That is, the proper format and mimetype has not been normalized among the tools within FITS that examine video files. As an example, in looking at the FITS output file you provided, output.xml, there is a conflict within the <identification> section.

<identification status="CONFLICT">
    <identity format="Quicktime" mimetype="video/quicktime" toolname="FITS" toolversion="1.1.1">
      <tool toolname="MediaInfo" toolversion="0.7.75" />
    </identity>
    <identity format="ISO Media, MPEG v4 system, version 1" mimetype="video/mp4" toolname="FITS" toolversion="1.1.1">
      <tool toolname="file utility" toolversion="5.14" />
    </identity>
  </identification>

The MediaInfo tool identifies the file format as “Quicktime” whereas the file utility identifies the format as “ISO Media, MPEG v4 system, version 1” even though both identify the mimetype as “video/mp4”. Thus there is the status=”CONFLICT” attribute in the <identification> element. The result of this is that FITS will limit its <metadata> output to only the tool identified in the first <identity> section. Ideally, all tools will identify a file processed by FITS as having the same format and mimetype. This will result in the output of all tools being used to compile the <metadata> section. An example of this is as follows where multiple tools identify the same input PDF file format and mimetype:

<identification>
    <identity format="Portable Document Format" mimetype="application/pdf" toolname="FITS" toolversion="1.4.0 ">
      <tool toolname="Droid" toolversion="6.4" />
      <tool toolname="Jhove" toolversion="1.20.1" />
      <tool toolname="file utility" toolversion="5.31" />
      <tool toolname="Exiftool" toolversion="11.14" />
      <tool toolname="NLNZ Metadata Extractor" toolversion="3.6GA" />
      <tool toolname="ffident" toolversion="0.2" />
      <tool toolname="Tika" toolversion="1.19.1" />
      <version toolname="Droid" toolversion="6.4">1.3</version>
      <externalIdentifier toolname="Droid" toolversion="6.4" type="puid">fmt/17</externalIdentifier>
    </identity>
</identification>

Because of this “CONFLICT” situation, an action item on our end is to consult with our file metadata expert to see if we can normalize tool format output in a consistent manner to avoid the conflict situation seen here as it results in less accurate or less complete metadata from FITS.

5) You mention that there is no Exiftool value for “Projection Type“. Even with Exiftool processing MP4 files it look like this data point would not appear in FITS metadata. In looking at the file that transforms Exiftool output to FITS <metadata> output, xml/exiftool/exiftool_video_to_fits.xslt, there are a limited amount of data points that are transformed from Exiftool output to FITS <metadata>.

6) Though it would likely not address issues raised here, it is recommended that you upgrade the version of FITS you are using. From your output file it appears you are using v.1.1.1. The latest release is v.1.4.0.

Thank you for contacting us about this issue you are having since it is helpful in improving FITS in the future. Given development time constraints we cannot promise a fix/improvement in a specific timeframe. However, by keeping track of future releases and checking release notes, it will be possible for you to see when the issues raised here are addressed.