Cp-522 Date: 2005/11/02 Clarification of 8 bit lutencoding Status: Letter Ballot

Addition

PS 3.3

There have been different interpretations of the number of bits to be stored as LUT data in the case of 8 bit LUT entries.

The VR for all LUT Data attributes specifies a 16 bit value (US, SS or OW) in PS 3.6. PS 3.3 states that "the LUT Data shall be stored in a format equivalent to 8 or 16 bits allocated where the high bit is equal to bits stored - 1, where bits stored is the third value [of LUT Descriptor]."

In the case of 8 bits per entry (LUT Descriptor value 3 == 8) this means that BitsStored=8 and HighBit=7. Bits Stored specifies how many of the bits in the encoded word are significant; what is not clearly specified is how many Bits Allocated are expected (how long the encoded word is). Either one could:

- pack two 8 bit entires into one 16 bit US, SS or OW, as if Bits Allocated were 8, according to the packing rules in PS 3.5 that apply to Pixel Data, or

- pad the high 8 bits with zeroes and encoded the 8 bit entry in the low 8 bits of one 16 bit US, SS or OW, as if Bits Allocated were 8

The uncertainty arrises because it is not clear whether the wording is intended to mean:

- Bits Allocated should be 8 for 8 bit entries and 16 for 16 bit entries, or

- Bits Allocated should be 8 or 16 for 8 bit entries and 16 for 16 bit entries

Since there is no plausible reason to “waste” 8 high bits of zeroes for each 8 bit entry, it is believed that the intent was that the section be interpreted in the former manner.

It is proposed to clarify the text, and add a note indicating that alternative interpretations are incorrect, but may be detected by comparing the number of table entries with the actual value length of the attribute.

PS 3.3