|
From: Brendan M. <hb...@an...> - 2004-03-29 00:52:56
|
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
|