Re: Endian again :-<

[Jim Knowles <[e-mail]>]

> After several minutes's thought, I found that fax2tiff assumes
> each image data bytes are encoded as Most Significant Bit first
> order. But my program encode image by LSB first. For example,
> a run-code for white 0 pixel is encoded as follows
> 	00110101	bit-representation in ccitt T.4
> 	0x35		fax2tiff's encoding
> 	0xac		MY encoding
> 
> Because ccitt X.4 defines Least Significant Bit shall be sent first,
> (or the first bit received shall be Least Significant Bit), I think
> my interpretation is more natural than tiff library's interpretation.

I think most fax programs store as you do, since this is how the bits
come off the wire.  However, most of the publicly available g3 encoders
I've seen create files in MSB format, which is the order one might
assume by looking at the T.4 tables.  The "class 2" command set has
an option for telling the modem which order to expect.  Whether this
works or not apparently depends on the implementation in any particular
"class 2" modem. :-)  The PBMPLUS package expects MSB for its g3topbm
program.

> 1) Is the tiff library's interpretation is common or my interpretation
> 	is common?

So, the answer to this is, both are common.

> 2) Is this interpretation affected by the two bytes magic number 'MM'
> 	and 'II'?

These refer to byte order.  There is another field called FillOrder in
TIFF-F that specifies the bit-order.

> 3) Isn't it better to define this issue in RFC?

Apparently, FillOrder didn't make it into RFC1314.  In its absence, I would
assume MSB, since this specifies a format for transmission over the Internet,
not phone wires, and this seems more "natural" to me (we don't usually assume
reversed bit order).  But, since you would assume LSB, and since a very real
use for this format will be to store facsimile received via phone lines,
I think we should add this to the RFC at the next review.

Jim