[Jigs-devel] new ImageType subsystem

[Brendan M. <hb...@an...>]

Ok, I think I know how I want the image type system to work.  It's a
little different than what I was talking about before, because it
doesn't have a central repository of types.  I think this is better.
The main change is that images stored in an ImageSource no longer have
a type assigned to them, the ImageType is dynamically bound to the
Image each time the ImageSource is instantiated.  This means images
can be shared between types, and also that you aren't screwed if you
redefine a type ... the right thing should happen.  I don't have time
to implement this today, hopefully tomorrow, feel free to send me any
input.  Hope the discussion below is clear.

An ImageType will contain the following information.  This is very
similar to the information currently maintained:

Image Type:

      // basic type information
      name
      short name
      max dimension
      min dimension

      // image creation parameters (not dynamically assigned)
      //(Only matter to ImageConverterThread)
      quality
      scaleUp
      scaleDown
      canCopy

      // link information (one of the following is true, probably
      // accessed through methods, info stored in a single boolean

      isRescaledCopy

            true for images created by the ImageConverterThread, i.e.,
            all rescaled images.if isRescaledCopy is true, then this
            image type can (possibly) bind to some images in the image
            source dir.  the ImageSource binds the largest image that
            matches the types dimensions.


      isOriginalRef // is a link to the original image

            an ImageType isOriginal isn't bound by any image, but an
            Image of this type is always present in the image source,
            by reference to the original.


ImageType's serve two functions: telling the ImageConverterThread how
to create a ImageSource directory full of resized images, and letting
a client (a RenderEngine or Desque) specify what types of images it
wants.  Some discussion of these two functions:



            -> tell the ImageConverterThread how to create an
            ImageSource for a particular web project.


How this works: ImageConverter takes an album and an array of
ImageTypes as input.  If a root image source is available, it creates
an ImageSource on top of that directory, dynamically binding the
images to the types it was provided.  It then creates a new image
source, by copying from the root image source or original when
possible, and resizing when this isn't possible.  If we make it so the
root image source always exists, and has at least the original image
type, then we can view the ImageConverter as always taking as input an
image source (the root image source), plus an album, plus a set of
image types.


            -> let's a renderer or desque tell an ImageSource what it
            wants/needs (provides a set of ImageTypes for dynamic
            binding)

How this works: A Renderer (or Desque) provides a set of image types.
The framework then creates an ImageSource from the set of image types
and (possibly) an image source directory.  For each ImageType that has
isRescaledCopy true, the ImageSource associates the largest image in
the directory within the max dimensions with that type.  For each
image type that has isOriginalRef set to true, it _always_ creates an
image, by linking to the original and setting an approrpriate image
size (which will be placed in the html IMG tag).  In general, Desque
can have it's own set of types, which should be designed so they
encompass all image sizes (ie, any image in the image source will be
bound to some image for Desque).


Advantages of this system:

       can maintain several sets of image types for creating web
       output, one or more for each renderer if desired.  the image
       types can share output images in the root image source or other
       image sources when the types overlap in required dimensions.


       also, it is easy to generate local web pages that link to
       whatever images are available in the root image source.


There will be a few other small changes associated with this, but
that's the main idea.  The same file format for sets of image types
will be used, but I think I'll put the code for loading those into
BasicImageType as static methods, and get rid of
BasicImageTypeSource.  I'll also update the ImageType interface so
it's actually usable; currently a lot of things ignore the interface
and refer to BasicImageType.


    - Brendan