home *** CD-ROM | disk | FTP | other *** search
/ Resource Library: Graphics / graphics-16000.iso / amiga / convrtrs / pbmplus / update4.lha / DCOL_proposal.txt next >
Encoding:
Text File  |  1993-07-09  |  3.0 KB  |  71 lines
  1. TITLE: DCOL IFF-ILBM chunk proposal
  2.  
  3. Form/Chunk ID: Chunk DCOL (ILBM direct color description)
  4. Date Submitted: June 25, 1993
  5. Submitted by: Ingo Wilken
  6.               Bloherfelder Str. 72
  7.               26129 Oldenburg
  8.               Germany
  9.               email: Ingo.Wilken@informatik.uni-oldenburg.de
  10. Supporting software: experimental implementation in ppmtoilbm/ilbmtoppm
  11.                      (from the PBMPlus package)
  12.  
  13. PURPOSE:
  14. --------
  15. With the growing number of 3rd-party graphic boards that support direct
  16. color (for example "HiColor", 5:5:5, 6:5:5, 5:6:5 or 5:5:6 RGB encoded
  17. in a word, one word per pixel), I've been thinking about how to store such
  18. images in an IFF file.   There is already a format that does something
  19. similar: deep (24bit) ILBM, but storing (for example) a 5:5:5 direct color
  20. picture in a deep ILBM would waste 9 planes.  Now, my idea is to generalize
  21. the deep ILBM format to support a different number of bits for red, green and
  22. blue each instead of the fixed 8:8:8 planes in deep ILBMs.  A deep ILBM can
  23. then simply bee seen as a special case of a direct color ILBM with 8 bits
  24. for each color component.
  25.  
  26. Now we need a way to determine whether a ILBM is a normal file with the
  27. bits giving an index into a colormap, or a direct color ILBM with absolute
  28. RGB values.  We also need a way to store how many planes are used for red,
  29. green and blue values.  The easiest and most flexible way to store this
  30. information is a new chunk, DCOL (direct color description).  The presence of
  31. this chunk indicates a direct color ILBM, otherwise it's a colormap-indexed
  32. ILBM (since a colormap-indexed ILBM with 24 planes doesn't make much sense,
  33. we can safely assume that a 24-plane ILBM is a 8:8:8 direct color ILBM even
  34. without the presence of a DCOL chunk).
  35.  
  36.  
  37. SPECIFICATION:
  38. --------------
  39. /* IFF chunk ID macro for a DCOL chunk */
  40. #define ID_DCOL    MakeID('D','C','O','L')
  41.  
  42. typedef struct {
  43.     UBYTE r;      /* number of bits (planes) for reds */
  44.     UBYTE g;      /* number of bits (planes) for greens */
  45.     UBYTE b;      /* number of bits (planes) for blues */
  46.     UBYTE pad1;   /* reserved, ignore on read, write as 0 */
  47. } DirectColor;
  48.  
  49. The number of planes given in BMHD.nPlanes must be the same as the
  50. sum of the planes in the DCOL chunk.
  51.  
  52. Bits in a direct color ILBM are stored similar to deep ILBMs:
  53.     saved                                                    saved
  54.     first --------------------------------------------------> last
  55.     R(0) R(1) ... R(r-1) G(0) G(1) ... G(g-1) B(0) B(1) ... B(b-1)
  56.  
  57. This means a reader program that supports deep ILBMs can easily be modified
  58. to support direct color ILBMs (at least upto 8 planes per color component).
  59.  
  60.  
  61. NOTES
  62. -----
  63. This format is extremly flexible, for example is allows the storage of a
  64. possible future 'super true color' image with 16 or even 32 bits for red,
  65. green and blue each.
  66.  
  67. I've been asked why I named this chunk 'direct color' = 'DCOL' instead
  68. of 'true color' = 'TCOL' or 'TRCL'.  It's simply because 'true color' is
  69. usually associated with 24-bit images.
  70.  
  71.