design/represent.txt

   1 =head1 NAME
   2
   3   represent.txt - discuss image representation within Imager
   4
   5 =head1 SYNOPSIS
   6
   7   Virtual Images
   8   Image Subsetting
   9   Varying Bits/Sample
  10   Paletted Images
  11   Performance
  12
  13 =head1 DESCRIPTION
  14
  15 I'm going to try to explain what we can get from having a flexible
  16 representation of images within Imager.
  17
  18 The main idea is to have all, or almost all of Imager access the
  19 contents of an image through function pointers embedded in the i_img
  20 structure.  This means that the underlying image data can be formatted
  21 to suit special purposes, including paletted images, images kept of
  22 disk (think of 64k x 64k RGB images), and virtual images (where
  23 there's no actual image data.)
  24
  25 =head2 Paletted Images
  26
  27 This is the form we've discussed the most.  The main advantage here is
  28 when the user is performing simple manipulations on the image data.
  29 One example that came up recently was when mjd was trying to combine
  30 several images into a single animated GIF file.  If we were
  31 representing the image internally as paletted, and the GIF reader and
  32 writer knew how to do that we could have loaded the images into
  33 paletted images and then written them with no quantization required.
  34
  35 Now we could get complicated and have writes with colours that don't
  36 exist in the image cause an extra entry be added to the palette, but
  37 this leads to complications as to when to convert the image to RGB.
  38 Some paletted formats support large palettes, so if we allowed a few
  39 hundred new colours to be drawn into the image and the tried to save
  40 to a format with only small palettes, not only has the user paid the
  41 performance cost in writing to the image (since paletted writes
  42 include a palette lookup), but also the hit in having to re-quantize
  43 the image anyway.
  44
  45 So my idea was to have the paletted write functions be something like:
  46
  47   if (found entry in palette) {
  48     save to the pixel
  49   } else {
  50     convert image to rgb
  51     call rgb save function
  52   }
  53
  54 An initial implementation might only support 256 colour palettes, we
  55 might expand that later to support larger palettes.
  56
  57 We could expose the quant.c functions to allow the user to create
  58 palettes (and possibly tune them), and to convert from RGB images to
  59 paletted images.
  60
  61 For improved memory usage for large images we could also implement 4
  62 and 1 bit/pixel images.  If we want good support for faxing this could
  63 be useful.
  64
  65 =head2 Virtual Images
  66
  67 Another possible type of image is a B<virtual image> where the i_img
  68 that the user has, has no image data directly associated with it.  The
  69 results of retreiving pixels would simply be the result of some
  70 function.  Such virtualness could even be in terms of "virtual
  71 memory", so a 32-bit processor machine could work with 65536x65536x24
  72 bit images which doesn't even fit into the address-space of the 32-bit
  73 machine.
  74
  75 One possible implementation of function based images would be through
  76 the use of the transform2() engine.  This way the user could specify
  77 the function to be used to generate the virtual image.  This is most
  78 useful for very large images, otherwise simply generating a new image
  79 using the transform2() function would be faster.
  80
  81 =head3 Image Subsetting
  82
  83 This would be mainly for when writing to an image, the user could
  84 supply another image where which pixels were non-black allowed writes
  85 to the corresponding pixels in another image.  Since access is
  86 controlled via another image, we aren't limited to rectangular
  87 subsets.
  88
  89 One simple example might be to create a mask image that has some text
  90 drawn in a large font.  When a gradient or other effect is used it
  91 will fill the letters in the target image.  A more subtle effect could
  92 be lightening, darkening or blurring through the image.
  93
  94 One implementation consideration is that if calculating the pixel
  95 value is expensive the caller may want a method to check if given
  96 pixels are writable, to avoid that extra expense.
  97
  98 =head2 Varying Bits/Sample
  99
 100 =head2 Implementation
 101
 102 Since we want some function pointers to only be available for some
 103 images (like 'getpixindex' against paletted images), callers need to
 104 be able to detect the type of image that they are working with.
 105
 106 =head2 Performance
 107
 108 Why is performance last?  Well, it needs to be considered in terms of
 109 the other topics above.
 110
 111 Perhaps some method to check the writability at given pixels could be
 112 used to avoid expensive pixel calculations.
 113
 114 =head2 Robustness
 115
 116
 117
 118 =head1 AUTHOR
 119
 120 Tony Cook <tony@develop-help.com>
 121
 122 =cut