When deciding what Drupal image solution that you need, then it depends on what you're trying to do with the images.
UPLOAD.MODULE
- Drupal doesn't do any image handling out of the box
- Basic Implementation: Use upload module to move stuff to a server via the Drupal interface
- Can then use the URL of that image into a node -- primitive, but works
- Attaches the image to the node -- when node is deleted, then image is also deleted.
- Can only put in if you use non-filtered HTML -- have to change input filter to Full HTML
- When you go through the theming layer -- upload favicon, user images, etc
- Can move to more complex solutions from here.
IMAGE.MODULE (http://www.drupal.org/project/image)
- Creates a new content type called Image
- Views integration
- Most content is a node, and it creates a custom image type
- A little better UI and provides previews
- Can include in blocks
- Add taxonomy
- Creates a number of derivitive images -- can create custom image sizes,
- Creates an image subdirectory,
- Creates a custom URL way of handling it, but it's slow because the images have to through a Drupal bootstrap - can only do a couple per page otherwise it is too slow
Contrib packages
-
Image_attach.module
- Solves the problem of having a node type where you just simply want to have images appear with it
- Can be turned on and off for each individual Content Type
- Allows for reuse of existing Image nodes
- Supports multiple images
-
Image_import.module
- Bulk image loader
-
Image_gallery.module
Set backs
- All attached images will be the same size.
- The reuse of existing images when large amounts of images are in the system becomes unrealistic
- If you create a new custom size, the image module will generate that custom size for every image node already on your site. This can be very intensive if you have a large number of image nodes.
IMAGEFIELD.MODULE
- Adds image handling features to the CCK File field type
- Supports multiple images in a single field
- Can now do galleries through views
- Needs clean urls and public files
- Doesn't support easy reuse of previously uploaded images
- Imagefield doesn't support it as much
- As mentioned in the Lullabot Deprecated podcast: Almost any custom content type has been replaced with CCK + Views
Sometimes you want an image tightly associated with a node -- CCK is good for that, and when the node is deleted, then the image is deleted as well.
If you want to treat an image as a node so that you can -- Vote, gallery, taxonomy, etc
If you don't want to have to reupload the image, then ...
Do you want extra fields -- Credit field, description field -- Then create more CCK fields and build it out in the theme level
If image are nodes, then create a field, then still have to build out the info in the theming layer
CCK needs an image_reference CCK field
Can create a view to display an image, --
list type field
Create a viewfield --
Insert a view into a CCK field to get the image
(More details from Sarva @ AlianDesign)
IMAGECACHE.MODULE
http://www.drupal.org/project/imagecache
http://www.lullabot.com/audiocast/drupal_podcast_no_25_almost_beta podcast starting at 16:15, Nate Haug explains the imagecache.module
image_cache -- does require a bit of coding in order to get it to work
One main frustration is that as web developers we can set it up fine, but it's when we hand off to a client, and have to explain a three-step process for handling images that it becomes too overwhelming
Making it very user friendly is key.
It's confusing to set up initially, but hopefully it gets easier once you have the right set up for your situation
Want to do the image handling all on the same page -- or to be able to streamline it
Train clients to use image assist -- can heaving theming stuff from image assist
Use of inline filter -- [img:1]
A SIDE DISCUSSION ABOUT INPUT FILTERS --
Different modules have different sets of filters
Title/Body -- Before it is presented on a page
Can't edit a node unless you have permission for that particular default input filter
Best practice is to create a user account for each role that you have, then run through the different permissions
Input filter should really be called "output filter" because the user input is stored directly into the database, it's the filters that alter the content to make it suitable for display.
There is a reason why the 
tag is not included within the Filtered HTML tags, people can point to a malicious javascript. If you don't trust your users, then you probably shouldn't enable the tag within the Filtered HTML options.
IMAGE HANDLING WITH WYSIWYG EDITORS
Most WYSIWYG recommend that you use full HTML -- and you then control which buttons are available
TinyMCE editor -- Input Filter of Full HTML -- No Community filter (may not be a good combo for untrusted users)
Image assist allows you to scroll through all of the images as thumbnails or via galleries
IMCE file handling -- Good solution for just uploading images w/o titles and descriptions
File handling will be associated with users and not associated with nodes
FCK WYSIWYG editor can use CSS classes -- and Image assist can as well
MISCELLANEOUS
Out of a box, Drupal has a Title and Body
If you want more control, then you can have more fields that you can control on theming level
TIP: Simple MENU module is great for putting the admin interface over the top laid out like a desktop application menu system.
Out of the box, comes with an image and a preview (?)
Image Magick does a better job at resizing images, and the flie sizes are smaller
But it takes some setting up with moving the *.inc file -- and you have to have Image_Magick installed on your server
Basic image module only has one subdirectory for files that get uploaded through that path
$base_url/files/images/sitting.jpg
Have to do 508 compliance with the alt tags filled in-- all attribute in HTML -- CCK does do that
What is your use for how you're going be handling images
On the theming layer, then take the Title and use that for the ALT
The default Upload module also apparently takes care of this.
Demonstration of the Upload + Image + Image attach enabled
Moving through the upgrade path through Drupal 6 and beyond
What about upgrade paths? What is the best solution for that?
Anything with CCK and Views is a good bet for the future
REFERENCES:
Angie Byron gives a brief overview of image resizing & image handling starting at around 21:40 in this podcast. She's discussing this article that she wrote: "Image and Image Exact Sizes vs. Imagefield and ImageCache"