Imagecache/Image* support

Reasonable request. However, although Image Assist needs to create new derivative image sizes for custom image sizes in certain contents, I would not like to implement another image scaling API. If Image module would already provide ImageCache presets as derivative sizes, Image Assist would not need an additional integration for ImageCache. So Image Assist would further rely on Image module.

On the other hand, Image Assist could also be seen as a stand-alone assistant for images. There have been already thoughts about integrating it with CCK's Imagefield, and if you are aware of the new Image API in contrib, there might be another candidate for integration, too.

So, well, yes. This has to be on the roadmap for Image Assist. However, I would like to squash this issue with in-depth developer discussion first. I'm sorry for that in advance.

IMHO, we should re-factor Image Assist into several layers:
- Image Assist core
- image selection (allowing integration of more than Image.module)
- image derivative retrieval/generation (allowing integration of more than one API)
- image display (allowing integration of more than one API)
- textarea/editor button/plugin (allowing integration with upcoming Wysiwyg API, too)
- image usage tracking (still alpha currently)

Well, for imagecache you wouldn't need no integration of an API, just output different paths.

@scroogie: Just FYI: One needs to select the ImageCache preset to use, and implementing a different image file path for rendering dependent on the existence of another module and configured settings, is an integration of an API.

Well, I guess right now Image assist is just too big, monolithic and inflexible. The image selection tool is what's everyone's primarily after, IMO, and it would be nice to break out that functionality like you suggest, to make it possible to use that with different modules. But we will always have to interact with something to make this tool useful, and until there is some API to interact with (I'm thinking new image handling in Drupal 7 and beyond) it's hard to replace the Image dependency with something else.

I am just adding my two cents in...

Personally, I love imagecache for it's resizing / derivative capabilities. I also love img_assist for the functionality it offers.

However, the fact that they don't integrate well together drives me up the wall. I have to have one set of image presets in Image.module, another in imagecache. And the Image.module presets don't allow cropping and other fun stuff that's somewhat necessary. And it confuses the heck out of clients who maintain their own site, as they don't really grasp quickly that they have to change both presets to make sure all the images are updated.

Ideally, the best solution would be to integrate Image and Imagecache, since Image's derivation operations are half-functional at best. Yes, they resize your image, but they don't do any of the other (necessary) tricks Imagecache can do.

However, barring that, the next best thing would be to make Imagecache work with img_assist as well.

so yeah - +1 imagecache / img_assist integration!

- Image Assist core [macro processing]
- image usage tracking (still alpha currently)

will soon be part of Inline API (discussion + implementation please in corresponding issue).

- image selection (allowing integration of more than Image.module)

rather sounds like a Views implementation. However, Views is not yet part of Drupal core. Anyway, we should check that out.

I'd be willing to help fund (a little) to see if image-assist integration with image-cache and image-field could be possible. Contact me and let me know if you'd like support. Currently my team is using acid-free galleries for a website but, as the designer, I'm running around in circles trying to display the images neatly within teasers as they can't be cropped or displayed in an image-field without the use of said modules.

Subscribing. Usability input form image_assist, imagecache users is welcome at http://groups.drupal.org/node/9957 a proposal for this kind of functionality .

Ripping out anything that Inline API provides from img_assist is a very good start IMO. After that we should find a smart and pluggable way of seperating the different pieces of code for browsing and inserting images from different sources: Image nodes, Imagefield images, maybe attached images, even external images...

I've had a patch in the queue for ages that does integrate image.module presets and imagecache processes great for my needs. Anyone who currently uses image sizes can get access to the full imagecache range of derivatives.
http://drupal.org/node/231622

Would this help? A code review/test/bump over there may help.

dman,

Will your patch allow image assist to be compatible with image cache?

Lets see. I believe image assist runs on the image.module derivatives.
And that patch replaces the derivatives with image_cache processed ones (it doesn't use imagecache on-demand folders) so the filenames are the same as they were before.
In short ... certainly!

Wow! I'm going to try it out tonight!

I'm pretty sure that with the evolution of the three modules in question, this is outdated.
Imagecache now plays directly with image.module, and image.module now has better scaling anyway. Closing

Uhm. That is not necessarily enough for Image Assist. In my dreams, IA allows the user to select an ImageCache preset, or an Image preset, or to define a custom size that may be generated by ImageCache, Image, or any other image processor. Of course, that's pretty far away from what we have now. However, it may be worth to keep this issue.

Sorry if I shouldn't have changed the status on this, but thought some of the following might be new information and/or expanded ideas for some of those involved with Image Assist's maintenance but not directly involved with Imagefield/Imagecache. If not, then just consider it a bump and set it back to postpone. . .

I can confirm from my newbie drupal research on images that Image Assist already works just fine using ImageCache's derivative generations as discussed above, including dynamically generating a custom size when needed!

This is because the Imagecache_4_Image add-on module in the current Imagecache dev (I'm on D5) causes Image module's derivative generation process to call imagecache's, instead of its own native process, in a way that seems to be pretty transparent both to Image and to add-ons like Image Assist.

The way I got it to work was to first define the six presets I wanted in the native Image interface; I then enabled Imagecache, set up the six presets again there (now with more functionality and flexibility) and then finally, went back to the new Image module UI (overridden by Imagecache 4 Image) and selected the imagecache prefixes. Although Image actually seems to ignore the former settings, they do need to be there for it to work, and although I did make the two sets of presets more or less match each other that's probably not necessary.

From then on Image Assist seems to JUST WORK ^TM just fine with imagecache derivatives. I haven't quite figured out the exact algorithm used for its choice of derivatives, but I think it chooses the next biggest image up that fits the tags. Sometimes it's a bit weird and generates a new custom derivative when I think I've put in width/height specs that match an existing pre-set, but very minor issues.

Therefore I think that image_assist's full integration with all the Imagefield-based methods would require very little tweaking, or at least such integration could at least be incrementally improved. Here are some suggestions on specifics:

• Rather than the tag only referencing the Image node-type nid, add the abilility to directly reference the files table fid
• Allow the ability to reference the preset keyword (filename.xxxxxx.png). In this case
• leaving both width/height blank should cause the html to reference the actual preset's dimension
• setting only one dimension differently from the actual preset would cause browser (display-only) scaling, and
• not specifying the preset keyword and putting in something other than the actual width/height should cause the custom derivative generation
• It would be really nice if the custom derivative generation process would allow for more than one, perhaps using the nid in the custom keyword?

I know, gone beyond just a little tweaking. . . :)

This would allow Image Assist to become (again IMO) THE inline placement tool, able to work on sites using either Imagefield or Image module, and especially those combining the two. In fact using the fid should allow IA to work with ANY file attachment, including core Upload module. This would eventually enable merging with Inline module's functionality? Also, this would allow IA to be the best way for developers to ensure their site's design is "future proofed" against whatever direction image-handline takes on its proposed journey into core.

Further details on these ideas here: http://drupal.org/node/231622, and here http://groups.drupal.org/node/14974#comment-50610, and feedback most welcome, especially on the latter posting.

Thanks for taking the time to consider these ideas, and hope that they are helpful, even if only to clarify things for other noobs like me coming to Drupal and confused by its many methods to work with images.

Thanks for your clear appraisal. It's nice to see that someone without preconceptions can plug things together and find it works as expected. As you'll see, the image initiatives have a bit of a history.

Hm.

I'm not sure what accessing the fid directly would achieve. Now that files are also being versioned, that becomes a little un-semantic and fragile. I think? It may make sense in some cases, but I'm not sure it's a good thing.

Introspection of the dimension from the derivative name sounds logical, but unfortunately with the imagecache processes, that information is no longer (easily) visible to other modules. Before, image.module stored that information in-the-clear. now any imagecache process may change it strangely and privately, eg percents, padding or proportional constraints. Can still be done, but only by actually inspecting the final file itself.

Browser-only scaling used to be bad juju. Although it's a lot better than it used to be - I've successfully abused client-side scaling recently. It does require serious fu, probably hard to do without associated CSS and stuff.

... not sure what the last two suggestions are.

Merging with inline is probably a good path. I've recently had pleasant experiences with just embedding content and it just working. This is a positive way forward.

Just thoughts...

dman, I'm flattered but assure you my lack of preconceptions come purely from lack of experience. Plus lack of knowledge of internal workings hinder my ability to contribute to the discussion properly but I won't let that stop me :)

I only brought up fid because I thought it would be the easiest way to allow integration with just about any of the current image handling methods - Upload module (a la Inline), Image and Imagefield, plus maybe Asset, IMCE, WebFM? Haven't checked them out in detail yet.

If you don't use fid, then you'd have to have Image module specific code (as you do now) plus more code to handle pure Upload attachments (wouldn't that be fid anyway?) plus more code to handle Imagefield, then maybe the others mentioned above.

Of course the lowest common denominator is the filepath itself, but the advantage of fid is that file management tools like Asset, WebFM etc allow that to be bulk changed, but when they do (I assume) they'd be updating the path stored in the files table. Basically I just see the fid as a pointer to the filepath.

I don't know about revision control, but why not just use the current file as it's sitting there at render time; rather than "introspection" (?) how hard is it for you to get the current dimensions of a file directly from the file itself? I honestly don't know, but it seems to be a pretty common function. This would allows the site developer/admin using the preview keyword option with no dimensions spec'd to change the actual size of his "medium" preset anytime the theme changes. Imagecache's regeneration will take care of the actual re-sizing, and the data in the original (maybe thousands of) nodes don't need to be touched. This is so compelling I'd actually vote for this syntax to be the main one allowed, plus custom of course - drop the rest!

I wasn't actually recommending browser-side scaling at all, just one option in the toolkit brought up by the current fact that there's only one custom derivative, the last one generated wins. This wouldn't require anything from the module other than setting the img tag options right? I was assuming the closest derivative would be the base to work from anyway so that's the fallback display, but if this is fu by all means leave it out. However if you do then the problem that there's only one custom becomes more pressing.

> not sure what the last two suggestions are.

And I'm not sure which two you're referring to - confusion reigns :)

It would be really nice if the custom derivative generation process would allow for more than one, perhaps using the nid in the custom keyword?

Image Assist 2.x supports this already.

I actually like the thought of cleaning up the filter syntax and only deal with fids – no nodes, no fields, no sizes. HansBKK has a point in that it would make node rendering a lot less complex. Yes, it's easy to extract the size from the image file itself. And that info would be cached. However I guess it wouldn't work with Imagecache, since its files are not proper Drupal files with fids. Or are they?

The image browser on the other hand will still need to know everything about Image module and any other image solution we want it to support (without the container nodes the browser would be a mess IMO). Why not let the image browser take care of all that and reduce the filter syntax to something like:

[img_assist|{fid}|{Alt text}] – and maybe:
[img_assist|{fid}|{Alt text}|{imgcache_preset}]

An alternative (if we want to support more image modules) would be to have a very flexible filter syntax which allows several different modes:

[img_assist|nid={nid}|img_size={thumbnail}|alt={Alt text}] (Image module image)
[img_assist|fid={fid}|alt={Alt text}]
[img_assist|nid={nid}|field={field_name}|alt={Alt text}]
[img_assist|nid={nid}|field={field_name}|imgcache_preset={thumbnail}|alt={Alt text}]
[img_assist|nid={nid}|field={field_name}|custom_size={XXXxYYY}|alt={Alt text}]

Right now the IA writes the image sizes in pixels rather than with preset names. That means each time it interprets a filter tag it has to do some crazy stuff to try to match that size to a Image module derivative size. To me it's a little too complex.

And I wouldn't mind ditching custom sizes in IA completely. And if we really really need them, then yes, maybe we should do fake/browser resizing.

Imagecache with the "imagecache 4 image" (not my name!) uses imagecache to generate preset derivatives.
These are outwardly the same as normal presets and do have fids, but you are still better pointing to nid+derivativetname.

No, other imagecache processes - like applying imagecache to non-image-node images or raw file attachments - do not have fids. although I guess you could point to [path|fid]+[imagecachepreset]. That would still be hell to manage, none of those values are easy enough to regard as assistance. And really an edge case. If you were building something that had the need for this, you really should be using image.module or imagefield and treating your images as objects (the 'container nodes' solution).

Don't want to disturb this brainstorming, but we could have implemented support for ImageCache in Image Assist since ImageCache module exists. ImageCache just expects the path (/files/image/foo-bar.jpg) to be properly prefixed (/files/imagecache/presetname/image/foo-bar.jpg).

And another note: To support arbitrary macro parameters, we will need Inline API. Be sure to read about that stuff at g.d.o.

Go on!

@dman
> imagecache's preset derivatives do have fids, but you are still better pointing to nid+derivativetname
That sounds like a good way to go for handling those (currently probably very few) sites that are using "imagecache 4 image". But if the syntax is going to change anyway, wouldn't it be best to get away from IA being limited to displaying images in Image nodes? If I've got images in my system, whether placed there by Upload, IMCE, Asset or in an Imagefield, I want to be able to display them inline with my content.

@sun - "disturbing brainstorming" is an oxymoron, can't be done! I've gone through your post at http://groups.drupal.org/node/8707, and although it (and most of this discussion) is way over my head, it seems like a lot of thought's gone into how we can get this great variety of image-handling tech integrated into something user-friendly. I haven't got to the UI POV yet in my research but obviously for non-tech end users the WYSIWYG integration is key.

So back to IA itself - how about just using imagecache's filename+presetname in the tag? Then we don't have to worry about where in the database or the filesystem the original file's referenced!

Then the only requirement to use Image Assist with a non-Image-based module world would be that it uses imagecache for its derivatives - from what I've seen a pretty future-safe bet! To my mind it would be great (for example) if a user, not needing image-as-nodes, could just use core Upload, specify a preset size and bang there's the image sitting where he wants it within his post!

We just need to make sure the display code can handle changes to the other parts of the path (/files/imagecache/xxx/image/yyy.jpg) right?

If the interim solution isn't very user-friendly on the front-end, never mind, it's just a formatted text string, motivated users can learn syntax and solutions will arise to make it GUI; start by targeting the tech-friendly users, giving as many options that make sense and aren't too difficult to implement, and it'll be a bit step in the right direction toward breaking down the barriers between the various image-handling solutions in Drupal.

Here's an idea for the image browser - let the config set which preset to use (e.g. thumbnail vs preview) and put up an alpha-based pager based on filename, X# of images per page, if a site only has a few hundred images I might only have three pages first one is aardvark-horse, while another one with hundreds might need aardvark-apples for the first page.

Then as an (admittedly crude) workaround for the fact that non-Image images can't be tagged by taxonomy, one could set up filenaming conventions like all gallery images start with !, all decorative-only ones start with zz. Just a little OT here :)

Thanks for listening

If the interim solution isn't very user-friendly on the front-end, never mind, it's just a formatted text string, motivated users can learn syntax and solutions will arise to make it GUI; start by targeting the tech-friendly users, giving as many options that make sense and aren't too difficult to implement, and it'll be a bit step in the right direction toward breaking down the barriers between the various image-handling solutions in Drupal.

FWIW, I fully agree with this statement. I wouldn't mind to add hook_inline() to Image Assist in this stage already and conditionally exclude IA's macro engine if Inline API is present. Advanced users would be able to use and enhance it then. Actually, such a patch should be quite small.

[rant class="didactic"]

Then as an (admittedly crude) workaround for the fact that non-Image images can't be tagged by taxonomy, one could set up filenaming conventions like all gallery images start with !, all decorative-only ones start with zz. Just a little OT here :)

Or you could realize that ANY non-trivial image management system has the need to do more than just throw uploads into a big pile via a WYSIWYG.

If you were building something that had the need for this, you really should be using image.module or imagefield and treating your images as objects (the 'container nodes' solution).

By the time you have even a few dozen core uploaded images piled into your filesystem, you will start to wish you'd invested in image.module or imagefield. By the time you have a few hundred, you will realize that you will never be able to put them into galleries or organise or even find what you wanted ever again.
Why resist the bulk document management solutions that are available and actually are quite powerful (though not perfect) in Drupal? Trying to make the filebrowser(s) suck less is not a bad thing, but it's not a substitution for actually managing the content in a sane way.

• Images as nodes is not a significant overhead to look after. And has big wins already available.
• Hundreds of images as unstructured, no-metadata, no-naming-conventions, flat-folder files is totally unmanageable.

The fid table is not strong enough to solve that problem.

... If you want to continue down that path, I won't argue any further. You may have use-cases where having only unstructured files makes sense. But the tools are right in front of you in the CMS already.

I like flat-file systems and atomic bits and pieces, I like to avoid unneccessary overhead. But user-upload file bins become trash heaps overnight. Let Drupal index them for you. And all the derivative, imagecache, metadata, sizes, captions, auditing, browsing, searching, etc is free!

[/rant]

(delete) double-post from 3 hours ago (!)

Sorry if I'm coming off as didactic, I'm trying to post in a way that helps others following this, perhaps even newer than me, make sense of the many options available.

Very good points, especially for sites with a diverse population of users contributing content. For sites managed by a coherent team I would think they would need a real image management system (processing workflow, exif/iptc tags etc) separate from the website itself - the site would just be one target publishing medium.

And I personally completely agree with you about taking advantage of images as nodes, and am not too concerned about overhead issues (again for my situation). However I think choice is a good thing, and as many people are implementing other (non-Image-based) solutions, I think it would be great for some tool to allow these to be displayed inline with the content without having to resort to img links directly to the filesystem (yech).

I admit I'm glossing over many very important areas of this huge "image management" topic. But within my currently narrow scope of vision, I think being able to display any image from my site, in line within any post's content, using something along the lines of:

[modulename|filename=somefile.jpg|ic-preset=preview|alt={Alt text}]

would be very cool. But since it depends on imagecache so much I suppose it could be an add-on to that, or a future development of Inline - I haven't done enough research on the other modules that offer inline images, but IMO Image Assist seems to be a decent candidate to handle this if it's possible.

If this kind of content display integration were in place, then I'm sure the community would be driven to continue to improve ways to handle the problems of content/document/file management within the website, and maybe even create different, even more elegant ways than what exist today.

FWIW, I fully agree with this statement

Well since you're one of the maintainers of the module we're discussing I guess that's worth a lot!

I don't understand the implementation details you mention, but if you do decide to proceed with any of this I'll be happy to put in time helping however I can.

In the meantime, I'll continue to write up my "Overview of image handling in Drupal" notes, with the intention of eventually contributing to the Handbook.

First, although the formatting may not have given the right picture, I was framing my own little lecture as being didactic. ... And didactic (as a Greek-speaker) is not a bad thing! I'm good at it ;-)
I'm simply trying to expound best practices...

I won't oppose choice, and I think the module can safely handle a little expansion as you describe.
However, I think that the extended syntax required to be all things to all people will end up just as complex as a pure HTML img tag and you end up with no advantage or consistancy and more documentation and more limitations.
[modulename|filename=somefile.jpg|ic-preset=preview|alt={Alt text}]
<img src="somefile.jpg" class="image-assist ic-preview" alt="Alt Text" />
... !! now really, why not just be semantic instead of making up new languages? It solves the WYSIWYG preview problem also.
img links directly to the filesystem can be intercepted and rewritten if neccessary - just as easily as the img_assist tag does now. http://drupal.org/project/pathologic . No need to hold that against them.

... But that whole semantic approach is another thread. I like microformats and valid markup - I'll never convince the markdown and wiki-text fans. :-B It's got its place.

Thanks dman thought you meant me, and FYI the word can be pejorative, implying "talking down" to the reader, similar to "pedantic".

Good points, you're right of course that the syntax stored within the database doesn't matter as long as the output to the browser works (and ideally is valid of course). Am I correct in thinking that the class= syntax from your example is just there to be parsed by the IA module and wouldn't necessarily be output in the end?

OT - I actually have no problem with the so-called "complexity" of the HTML img tag; my concern with it has been that I want to be able to move my files around. Thanks for pointing out Pathologic, looks great!

This leads me to think that maybe there's a way to do this NOW with some sort of generic module that replaces tokens stored within the content on its way to output to the browser. Any ideas? Is this the same thing as writing a custom input filter (should be called output filter shouldn't it?)

Would such a beast be hard to code if there were an interested sponsor?

I think some useful thoughts have been put to the record here.

Since I wrote my last post I realized that I agree with dman that the filter tag may need to keep the connection to the nodes after all. You can use that to communicate back to the IA browser which image you have placed (not just which file) if you want to change something later. And like I said before, yes we need the container nodes (or some other container) in the IA browser, not just files.

Also, I agree with sun that the filter tag should preferably be moved to a separate module which can be used by other modules than IA. I haven't done my homework on Inline API properly yet, but I'm sure that's the way to go.

Not just for dman, but the Asset module has addressed these file management issues better than anything else I've found so far, at least within the image handling sphere.

I've posted related ideas in other locations, so here are some links for those coming across this thread interested in integrating Drupal's image handling:

Image Assist: http://drupal.org/node/319374
Asset: http://drupal.org/node/319370
Imagefield: http://drupal.org/node/119539

I realize these general discussion are best held in places other than specific module's issue queues, here's my "home page" on Drupal imagehandling in the Image Group: http://groups.drupal.org/node/14974

And sorry I can't contribute more concretely (yet), I know ideas are cheap. . .

@dman: I agree 100% with your rant in #26. However, after thinking a bit about #30, I have to disagree with those statements: Inline filter tags provide an administrative way to allow users to embed arbitrary contents in their posts. If you would use HTML for this, you would not want to allow users to use <embed> or even <script> for example (we all know the reasons) -- hence, no Flash, videos, or even simple images with advanced DIV + SPAN styling like those of Image Assist. Inline filter tags make this possible, regardless of whether content is edited in a client-side editor or in a plain textarea. Because of this, inline filter tags/macros should be kept out of the semantic HTML/input syntax discussion. In http://drupal.org/node/80170 (Inline API draft), one point of the discussion was whether we should store the contents of an inline tag in the database and just use [inline|iid=123] to improve user experience and avoid this topic at all.

And IMO anything that abstracts away from pointing directly to the files themselves has to be a good thing - ideally it would be possible to move files around after the fact and never have to go back and edit the nodes themselves - I'd be willing to use SQL to update paths in a structured field, but would hate to have to try to do it inline within the node body.

hence, no Flash, videos, or even simple images with advanced DIV + SPAN styling like those of Image Assist.

Well, I didn't even pretend to address the additional features of Flash and video - each of which are encumbered by so much legacy and compatability issues that rational embedding DOES need all the help it can get. That's fine - inline has its place, I'm not suggesting deprecating the concept altogether.

But there is absolutely no reason why allowing img tags as one way of embedding images would prevent using advanced formatting filters. Use exactly the same logic - with a different regexp - to garnish img tags. It's an alternative, but equally valid - no lost functionality.

I've already done it with a little filter of my own - (similar to a server-side imagecaption.module) :

..a filter which finds raw images embedded in a page (as in via the WYSIWYG) then backtracks to discover what (if any) node this image represents.
It then reformats the embedded image to add a few classes and css stuff (for alignment and scale) and adds the caption, border and hooks for the lightbox and imagecorner effects.

In some cases, you may find total abstraction [inline|iid=123] a better way to work. Yes, that's cool. I in fact did so it in my version!

<img  id="image-94-thumbnail" alt="Chad Wille and the Sopwith Triplane" class="framed-image image-thumbnail" src="/files/images/thumbnail/soptripe-chad_2.thumbnail.jpg" />

- the 'id' applied to that image is cannonic, and added by the code the first time it detects src="/files/images/thumbnail/soptripe-chad_2.thumbnail.jpg". If I change the content of image-94 the src will be updated as needed. Just through HTML parsing. That's the abstraction you may want if your users think that way.

But other times (WYSIWYG), embedding

<img  src="/files/images/thumbnail/soptripe-chad_2.thumbnail.jpg" />

is simpler, Just Works^TM and the filter can do the hard work for me.
This is going off topic, and is clearly a different approach. I'm just saying it's not at all incompatible with the inline features at all.

Thinking of embeds, I'd be happy to mark them up as <a href="/files/embedme.flv" rel="embed" >A movie</a> and let an inline-type module do the rest of the work. Valid, Plaintext AND WYSIWYG - Editable, Portable, Back-compatable, and equally parseable by a filter.

It's a different project - maybe I'll revisit this code next time I have the need.

@dman: Yes, again, 100% agreement. :) One point of the Inline API discussion was that it could and should support not just one, but multiple syntaxes concurrently. Like you pointed out, it's just a different parser and tag builder.

subscribing

subscribe