During the Multimedia panel at DrupalCon I elaborated on my plan for a single image module to rule them all in Drupal 6 and eventually Drupal 7. The plan is as follows:

1. Merge image.module and imagefield.module into a single CCK based module (so much more imagefield than image)
2. Provide an upgrade path for current users of image.module to the new CCK based image module
3. Merge the functionality of imagecache into image.module, again providing an upgrade path for users of 1.x image module. The image manipulation abilities of imagecache get merged in and should replace the current settings for image thumbnails. It's likely that the method for cron-generating of images will be maintained, but complemented by the on-the-fly generation of images provided by imagecache.

Then to make this "unified" image module part of Drupal 7:
4. Get CCK in core ;)
5. Move the image manipulation abilities of imagecache to image.inc, to provide a central framework for manipulation without image module.
6. Open a core issue and start continue the discussion there.

This issue has been discussed with walkah, dopry, and drewish. I plan to take the lead on implementation, though help will be greatly appreciated once the ball gets rolling on this herculean task.

Comments

drewish’s picture

drewish CreditAttribution: drewish commented

+1 ;)

vaish’s picture

vaish CreditAttribution: vaish commented

subscribe

TBarregren’s picture

TBarregren CreditAttribution: TBarregren commented

+1 (and subscribing)

jpetso’s picture

jpetso CreditAttribution: jpetso commented

Cool stuff, interested, subscribing. Go get 'em, Nate!

Stefan Nagtegaal’s picture

Stefan Nagtegaal CreditAttribution: Stefan Nagtegaal commented

Count me in and feel free to contact me about it! :-)

gaele’s picture

gaele CreditAttribution: gaele commented

subscribe

eigentor’s picture

eigentor CreditAttribution: eigentor commented

Is there a way you could collaborate with Wim Mostrey? He has got quite far with the asset module http://drupal.org/node/225400 , so there might be synergy... as efforts should be bundled...

hyperlogos’s picture

hyperlogos CreditAttribution: hyperlogos commented

5. Move the image manipulation abilities of imagecache to image.inc, to provide a central framework for manipulation without image module.

If It's not overly presumptuous of me, I'd like to call your attention to #238678: Support for pluggable image formats (or at least adding SVG!)... Do you have any plans to enhance the overall modularity of the image functionality? (Or am I just not understanding some method drupal provides to extend it already, in which case I'll slink away in shame?)

Regardless, image desperately needs to be in core, likewise CCK.

andershal’s picture

andershal CreditAttribution: andershal commented

subscribing

Brian@brianpuccio.net’s picture

Brian@brianpuccio.net CreditAttribution: Brian@brianpuccio.net commented

Subscribing.

(an upgrade path for me is crucial, I'm on D5 with image.module and if you can get me to D6 with CCK + imagefield, I'll buy you dinner)

nevets’s picture

nevets CreditAttribution: nevets commented

My only concern would be maintaining the ability to use image cache functionality on images defined in other ways that image field (I currently use it with the user picture)

ezra-g’s picture

ezra-g CreditAttribution: ezra-g commented

Subscribing.

MichaelK-1’s picture

MichaelK-1 CreditAttribution: MichaelK-1 commented

subscribe

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

I've ported Imagefield to Drupal 6 in the imagefield queue: http://drupal.org/node/224813, though the patch is still pending. It's intentionally written to serve as the foundation for Image 2.0. The typical upgrade path for users converting from Imagefield to Image 2.0 will be "disable imagefield, enable image". Because the two will have the same foundation there won't be any upgrade script necessary (here's hoping).

Some responses:
@eigentor: It's unlikely that image and asset will be combined. While generic uploading needs to be refactored in core (upload.module), asset module is a heavy chunk of code. The goal is to provide basic image handling with the flexibility to be built upon in contrib. Fortunately with the new file handling in core, asset module should be able to swap out any uploaded file and also keep track of any files uploaded through image (or any other module).

@drinkypoo: Adding flexibility to image.inc is a primary goal. SVG support won't be part of core, but could be handled by contrib modules when the various image_ manipulation functions are called.

NikLP’s picture

NikLP CreditAttribution: NikLP commented

Subscribe, but I'm not clear on this - is this what is happening in 5.x-2.x alpha and 6.x-1.x alpha, or is that totally different?

If not, does that mean there is still effectively ZERO support for image handling/processing in 6...?? :/

eigentor’s picture

eigentor CreditAttribution: eigentor commented

So for once I'm quite happy I did not get the point ;). If this is really going to happen, it is very exciting. Image handling in core finally coming true... (I mean, not really core, but very close)
It has been some time for the redundancy now, and this would be fantastic. Having a best practice for images (and files in general ...) Merging modules instead of offering yet a new one... great!

HansBKK’s picture

HansBKK CreditAttribution: HansBKK commented

+1000

Here are some of the issues I've come across in my newbie research into the current state of affairs; obviously most developers in the image-handling arena are aware of all these issues, but for the benefit of others, and of course while some of these are critical needs, some just "would be nice",

Having only one, single-value CCK field per node for storing the link to the image needs to be "hard-codeable" (per CCK content type?) for those admin/designers for whom 1:1 "image as node" functionality is very important (currently Image module's adherents).

In favouring Imagefield's methods please don't repeat the need to upload multiple duplicates just to display an image in multiple nodes - maybe nodereference is the solution?

Filtering inline-style macro tags are important for many, ideally merging Inline/Image Assist/Asset syntaxes (sp?)

With proper permissions, the ability to specify target upload path in the filesystem, both via ad-hoc and token-based automatic folder creation (for the latter see Upload Path)

The file browser should allow both local and server-side browsing via the file-system, as well as browsing nodes filtered by not only taxonomy but user and dates - for maximum flexibility maybe Views-based browsing? With the ability to switch between different imagecache preset thumbnails, set the number of thumbs to display per page. . .

Support for both public and private upload methods, or role-based simulation of private if public is required (see Asset and WebFM)

For photo-oriented applications being able to get to the EXIF/IPTC data would be great - see MAQUM

joachim’s picture

joachim CreditAttribution: joachim commented

+1

There needs to be a ready-baked system provided as part of this: a module that you can just install and bang! you've got image nodes. In other words, a wrapper module that takes care of creating a content type and adding the imagefield to it automatically.

heather’s picture

heather CreditAttribution: heather commented

what is the upgrade-proof method recommended for using images in d6?

at the moment, i am recommending (and using) imagefield in a specific 'image' node, then node reference as HansBKK mentions above. in this way, the images are 'assets'. i use imagefield instead of image module because in other parts of the site, i also like to be able to place an image directly into a content type.

i'm on the verge of making a screencast how-to, but i want to check all my bases first.

does anyone on this thread have a link/recommendation to a definitive "best way to handle images" guide for drupal?

thanks!

HansBKK’s picture

HansBKK CreditAttribution: HansBKK commented

I can tell you authoritatively no, there isn't such an authoritative guide, nor would such a recommendation be anything but the poster's opinion, no matter how informed; the community seems divided on fundamental philosophies.

Search Google too see just how nuts I've been going in this arena :0

IMO both Image and Imagefield's have enough traction that there will be migration paths for existing data if ever a best-of-all-possible-worlds "one image-handling module to rule them all" did emerge, or if any existing image-handling module ended up in core D7.

I've just started an overview section for the Handbook targeted at helping newbies figure this stuff out, but it seems you're past that level - help with this doc project would be great, please join in.

A related posting on trying to come up with a "future-proof" methodology very early in my research is here, but I haven't revisited it for a while, all my current notes are going into the Handbook first, then I'll update my procedure there once I've figured it out.

SeanBannister’s picture

SeanBannister CreditAttribution: SeanBannister commented

+1000 great to see this happen.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

Of course, we'll investigate this and I know that drewish and quicksketch are already working hard on further steps. However, this issue is completely derailed in the meantime and provides no real value. I tend to won't fix this.

Algirdas’s picture

Algirdas CreditAttribution: Algirdas commented

subscribing to this utopian idea :)

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented

Yeah it's true, this idea is nearly dead, at least in the Drupal 6 time-frame. My attempts to do much of anything in the Image/File Field queues received cold receptions. I'm now targeting for direct inclusion in Drupal 7, at least of the ImageCache/API modules. We'll see how fields in core shakes out before committing to putting ImageField directly in core.

If possible, I'd like to leave this issue open long enough just to post to my core issue for ImageAPI/Cache merging once it becomes available.

basicmagic.net’s picture

basicmagic.net CreditAttribution: basicmagic.net commented

subscribe

andribas’s picture

andribas CreditAttribution: andribas commented

subscribe

quicksketch’s picture

quicksketch
he/him
CreditAttribution: quicksketch commented
Status: Active » Closed (won't fix)

I'm targeting for Drupal 7 core now. I should have closed this issue previously when I submitted them.

ImageAPI is already in core: #373613: Create "Image" Objects, Operate on Images By Resource
ImageCache is well on its way: #371374: Add ImageCache UI Core
FileField in core is still not started, but the idea is seeded: #391330: File Field for Core

Between all of these, I think this eliminates the need for Image module in Drupal 7 (if FileField in core provides an image thumbnail). All that would be left to do would be to create a gallery, which falls on the shoulders of Views (which is currently not looking like a possibility for D7). All told, I think this issue is "won't fix" within the Drupal 6 timeframe. Drupal 7 on the other hand, is a whole different game. :-)

NikLP’s picture

NikLP CreditAttribution: NikLP commented

I don't think aiming to get anything fixed "before" D7 is really worth anything anyway. IMO D6 is a bit of a lame duck, contrib is STILL behind, nearly 14 months after official release...

Anyway, death to image.module, yays to imagefield in core, but what of the conversation regarding images [or "assets"] as "primary objects" in Drupal? Has that been argued out to its necessary conclusion?

OT, sorry! :p

Encarte’s picture

Encarte CreditAttribution: Encarte commented

subscribing

drewish’s picture

drewish CreditAttribution: drewish commented

see #560780: Add Image Field to image.module

mparker17’s picture

mparker17
he/him
Primary language English
Location UTC-4
CreditAttribution: mparker17 commented

Subscribing