Author Topic: replacement for Bentley MicroStation CAD drawing, Intergraph Raster bitmap  (Read 2635 times)

jenderek

  • Sr. Member
  • ****
  • Posts: 375
Hello trid users,

some days ago i run TrID inside on Bentley MicroStation CAD drawing and
Intergraph Raster bitmap. Many MicroStation CAD drawing samples like
WRENCH.DGN are misidentified with 97.1% possibility as "Intergraph Raster
bitmap" ( see appended output/trid-old.txt).
Furthermore some drawing files like ACSAMPLE.DGN are not recognized.
And for some Intergraph Raster bitmaps like COMP27.RGB and COMP9.rle the
correct file name extension is not shown.

The identification as "Intergraph Raster bitmap" happens by
bitmap-ingr.trid.xml by only one 2 byte pattern expressed as XML construct:

   <Bytes>0809</Bytes>
   <Pos>0</Pos>

Unfortunately this pattern is not unique enough, because this catches also
some DGN files. So i started a new bitmap-ingr.trid.xml. On web site
mentioned by reference URL there a link to specifications of Intergraph
Raster File Format (from archive.org) is mentioned.

According to documentation at the end of first block 3 bytes are
reserved with value always null. For CEL and DGN files there value is
not null. There "conversion" variable of ViewInfo structure is stored.
So catch raster images by new fourth test expressed by

   <Bytes>000000</Bytes>
   <Pos>508</Pos>

According to docs raster image always start with byte sequence 08 09.
According to documentation first element occupies some blocks a 512
bytes. So size of element in byte is something like 0200h. By dividing
through 2 you get size in words like 0100h. Subtracting 2 for
leading words gives a WordsToFollow value (WTF) like 00FEh. So lower byte of
this short variable stored at offset 2 is always FEh. So first test pattern
now becomes:

   <Bytes>0809FE</Bytes>
   <Pos>0</Pos>

At offset 6 the ApplicationType is stored as a short little endian.
This value identifies the type of application that created
the image file and is in the range from 0 to 9. So the upper byte of this
variable is always 0. This is now expressed by additional XML construct:

   <Bytes>00</Bytes>
   <Pos>7</Pos>

At offset 4 the DataTypeCode is stored as a short little endian.  This is
in the range from 0 to 69. So the upper byte of this variable is always
0. This is now expressed by additional XML construct:

   <Bytes>00</Bytes>
   <Pos>5</Pos>

Furthermore explains this variable usage by remark line:

<Rem>DataTypeCode at offset 4 indicates format,
depth of the pixel data,
used compression and file name extension</Rem>

Then i also add RGB and RLE to possible file name extensions, which is now
expressed by line

   <Ext>ITG/ING/COT/CIT/RGB/RLE</Ext>

So now 6 possible extensions for Intergraph Raster bitmap are listed, but
according to reference up to 19 different extensions are possible.  As user
you are interested to get the right extension especially when running on
examples like FILE0001.CHK.  Unfortunately the extensions have never been
standardized. So i handle only cases where i am sure about filename and i
found an example. So i add three subs classes with a characteristic
DataTypeCode. Bitmaps with DataTypeCode 24=18h are now described by
bitmap-ingr-cit.trid.xml "Intergraph Raster bitmap, CCITT Group 4, 1-bit" by
pattern construct:

   <Bytes>1800</Bytes>
   <Pos>4</Pos>

Then file name extension and mime type are now described by lines like:

   <Ext>CIT</Ext>
   <Mime>image/x-intergraph-cit</Mime>

Do similar for RGB sample by bitmap-ingr-rgb.trid.xml and for RLE by
bitmap-ingr-rle.trid.xml.

   <Bytes>00000000000000000000000000000000000000000000</Bytes>
   <Pos>6</Pos>

For DGN files instead company URL http://www.bentley.com/ i use page about
dgn files found on dgnlib site. This is expressed by:

   <RefURL>http://dgnlib.maptools.org/</RefURL>

On the the same site i found MicroStation 95 Reference Guide as
ref18.pdf. Both are not full complete, but with that information it is
possible to understand current identifications and correct
lines. According to reference at offset 4 coordinate range starts.
For many cases this is 0. This was expressed by construct

   <Bytes>00000000000000000000000000000000000000000000</Bytes>
   <Pos>6</Pos>

But there is no guarantee that all examples start with low coordinates 0. So
i removed such pattern. I also see no hint that later pattern have a
constant value. So i removed also later patterns.

Still recognition as DGN loosed against Intergraph Raster bitmap. So i look
for more characteristics and replaced dgn.trid.xml. According to specification
the first byte contains level in 6 lowest bit, element complex bit is
highest and the remaining bit is described as reserved. Element level seem to
be always 8.

When inspecting samples some have no of these bits set. So value of first
byte is 8. Such samples like WRENCH.DGN are now described by new
dgn-simple.trid.xml with pattern:

   <Bytes>0809FE02</Bytes>
   <Pos>0</Pos>

The other DGN samples have both bits set. So value of first byte is C8. Such
samples like A4FORM.DGN are now described by new dgn-complex.trid.xml with
pattern:

   <Bytes>C809FE02</Bytes>
   <Pos>0</Pos>

With these new 2 variants recognition as DGN comes first.

According to reference there exist also "Bentley MicroStation CAD cell
library". So i create a trid definition cel-bentley.trid.xml for such CEL
files. According to reference type of first element is always 5. Furthermore
WTF value seem to be constant 17h. This is now expressed by:

   <Bytes>08051700</Bytes>
   <Pos>0</Pos>
   
So size of first element is 19h words long, or size is 32h=50
bytes. According to specs second element type is always 1.
This is expressed by XML construct:

   <Bytes>01</Bytes>
   <Pos>51</Pos>

With the new 7 trid definitions all examples are now described more
precisely ( see appended output/trid-v-new.txt). TrID definitions and output
are stored in archive dgn.zip. I hope that my XML files can be used in
future version of triddefs.

With best wishes
Jörg Jenderek

Mark0

  • Administrator
  • Hero Member
  • *****
  • Posts: 2743
    • Mark0's Home Page
Hi Jörg!
Many thanks!