Hello trid users,
some days ago i handled a JPEG variant for stereoscopic views. These
examples all have file name extension MPO. When running TrID on such
examples i get an unexpected output.
The examples are described generic as "JFIF-EXIF JPEG Bitmap" by
bitmap-jfif-exif.trid.xml and as "JPEG bitmap" by bitmap-jpeg.trid.xml. Both
suggest filename extension JPG or JPEG (see appended output/trid-v-old.txt).
For comparison reason i check these examples by file command utility. When
running file command (version 5.41) the examples are also described generic
as "JPEG image data" (See appended output/file-5.41.txt). The file command
suggest 2 more file name extensions when running with --extension
option. That are jpe and jfif (See appended output/file-ext-5.41.txt).
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). This identifies the
examples as "Exchangeable Image File Format", but it complains about MPO
suffix by EXTENSION_MISMATCH as true (See appended droid-mpo.csv).
So i run tridscan on examples to generate bitmap-mpo.trid.xml. Some
information about this Multi-Picture Format variant of JPEG images can be
found on file formats archive team web site. That is expressed by line like:
<RefURL>
http://fileformats.archiveteam.org/wiki/Multi-Picture_Format </RefURL>
On some web sites the mime type image/mpo is mentioned, but this type is not
officially registered. So MPO as JPEG variant get that mime type that is
also shown by all mentioned tools. That is expressed by line like:
<Mime>image/jpeg</Mime>
After generating definition i look inside and by comparing i begin to refine
it. The first XML construct looks like:
<Bytes>FFD8FFE1</Bytes>
<Pos>0</Pos>
That is characteristic for JPEG and looks similar to construct inside
bitmap-jpeg.trid.xml. There this looks like:
<Bytes>FFD8FF</Bytes>
<Pos>0</Pos>
Second XML construct looks like:
<Bytes>457869660000</Bytes>
<ASCII> E x i f</ASCII>
<Pos>6</Pos>
So also inside global strings section also a line appears like:
<String>EXIF</String>
So in my MPO example this appears at fixed offset. But i do not know if this
is always true. And at least that is characteristic for JPEG images with
EXIF part as we find it described by bitmap-jfif-exif.trid.xml.
In definition are many short nil patterns like:
<Pattern>
<Bytes>0000</Bytes>
<Pos>17</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>719</Pos>
</Pattern>
I assume that these are generated by lucky circumstances or too few
inspected examples. So i delete such patterns.
In global string section i still get lines like:
<String>CDEFGHIJSTUVWXYZCDEFGHIJSTUVWXYZ</String>
<String>()*456789</String>
<String>()*56789</String>
<String>2'''R</String>
<String>$3BR</String>
<String>0100</String>
I assume that these are generated by lucky circumstances or too few
inspected examples. So i delete such lines.
When starting generating XML definition i get in global section a line like:
<String>MPF'II*</String>
After adding more examples like A-Kon2011-0101.MPO which are described by
file command as Exif standard big-endian this line vanished because in big
endian variants the expression looks like MPF'MM*. So the double II is
replaced by double MM and the average expression shrinks to something like
MPF\0, which is apparently estimated as too short by tridscan command. So i
manually add such a line inside global string section. This looks like:
<String>MPF'</String>
If you are not satisfied with that solution, then you must create 2 XML
files for big and little endian variant with corresponding longer lines.
With the new trid definition now all JPEG Multi-Picture Format images are
now described more precisely ( see appended output/trid-new-v.txt). TrID
definitions, some examples and output are stored in archive MPO.zip. I hope
that my XML file can be used in future version of triddefs.
With best wishes
Jörg Jenderek
