Use imagecache as a process for normal image.module presets

Screenshot failed for reasons unknown. twice. So here's the one I prepared earlier.

And a patch with 5 whole spaces added to it to make it code formatting-compliant :-}

Hey dman I totally love this patch, but Feel it could be a great standalone module... I'm not sure that I really have the personal bandwidth to track the changes in image.module as well as imagecache.module...

I've even been thinking of splitting out a separate imagefield_imagecache.module to expose imagecache formatters to CCK. To make my life as the maintainer of imagecache easier...

How would you feel about making this a stand alone module? I'd really love to see it in the wild... or making it a part of image.module officially. I really want to keep imagecache simple..

.darrel.

Well, this addition is only a bit of glue between the modules, with no character of its own, so I don't see it as a stand-alone entity really.
However, It looks like I can roll it up independantly, so I'll try that. I hear you about tracking the changes in dependancies, it's a bit hairy.
Still, not worth a hook or API to get image presets to look for any other processes... that's the long-term way to do this.. but overkill when AFAIK imagecache is the only one ever to provide such a function...

I'll turn it into a stand-alone contrib and see if the image guys want it. I do NOT want to create a project for this.
.dan.

both of the patches produced Hunk lines

This one goes against HEAD - revision 1.54. Which did you try it against? It may have been tagged against 5.x.2.0-beta wrongly. There's too many threads for me to figure nowadays.

Yeah I'm not really sure whether the image/imagefield integration should be a part of imagecache or image.module.... I think I may roll this as a contrib imagecache module and move the imagefield integration to the same... maybe move imagecache_profiles there as well... I want people to be able to pick and choose the middleware for their Drupal... not to get a kitchen sink with imagecache.

+1

Providing this as an optional contrib module in the ImageCache project/package sounds good. But I think this patch enhances Image.module in reality, not ImageCache. So providing this feature in the Image package might make more sense.

Moving to Image's queue to hear about drewish's opinion on this.

I guess you are right. It is adding to image.module more than vice versa.

And I have to do some hoopy mess to get the table/form formatted whan trying to form_alter from an external module. image runs its own theme to do form layout ... but that means extending it with a column was hard! It would be better if image.module did this extra form building internally.

subscribing.

dman - anything come of this with image.module? should we be checking an issue over there too?

I tried this patch out today. As the patch doesn't remove any existing code, I just added it as _form_alter() and _image_alter() in a separate module.

Here are my results:
* It adds the UI to image.module's settings page. I can add a new image preset and choose an imagecache profile.
* It adds the matching select option to my image_assist popup. However, imagecache profile 1 replaces image setting 1 - so my image.module setting "Original" is replaced with the first imagecache preset.
* I don't see any difference in the resulting inserted image.

dman, I'm intrigued by your statement,

I want to run imagecache over the built-ins, and not have to screw up other modules and themes by using imagecache pathnames.

I hadn't noticed imagecache do this - can you elaborate some?

Would love to have a hand in pushing this further. It is driving me batty that a great toolkit like ImageCache doesn't play friends with TinyMCE :)

This episode was brought to you by the version numbers:
* ImageAPI + ImageAPI GD 5.x-1.1
* ImageCache 5.x-2.0
* Image Assist 5.x-1.6
* TinyMCE 5.x-1.9

My reluctance to use pure-imagecache methods and instead shoehorn imagecache behaviour into image.module presets is straightforward.

Many of the image-modules I've been working with respect the image.module presets (_original,thumbnail, preview etc), and often present them as settings to choose from - eg views, image_attach, taxonomy_image.
They were not (last year anyway) as savvy about presenting imagecache options, and so to use imagecache usefully either some code, or more often some tricky (unconfigurable) custom theming had to happen.

It seemed better to add the options to image.module, then draw on them from the other modules, than to add imagecache-compatable additions to each of these third-party mods. That's pretty much all I meant by 'screwing up the paths' - anything that used imagecache had to be imagecache aware and use odd long imagecache pathnames. I prefer to use the pathnames as managed by image.module

That said - I've found in a recent (several thousand image) project, that forcing image.module to build all its derivatives at once is a bit painful for the server, and possibly on-demand imagecache behaviour also has its place!

Thanks for the reply. I agree that it's better to get this into core image.module than imagecache - and also that on-the-fly generation is generally more efficient (because images don't get created until they're used).

I'll have a look at why the imagecache presets are overwriting, rather than being appended to, the image presets in that form.

Would be keen to liase with you in pushing this one forward. We have an (NZ-based) project which wants some similar functionality, so it would be good to touch base. (Did I email you separately? I meant to!)

subscribe

works like a charm. I love it. doesn't it just make sense? how come no one'd thought of that before?

here's a patched version of the module, for all those not-tech-savvy such as meself; just rename it to imagecache.module and replace the original file. I didn't patch this properly, I only added the last lines. but worked anyway and might come in handy for some folks out there.

(I don't have to tell you to backup and test, do I?)

I'd like to ask developers: PLEASE post PATCHED versions of modules. the whole point of using Drupal is to abandon lines of code. I know patching is simple for a webdeveloper, but webdesigners get really stuck in that point. ok? ;]

anyway, kudos to ye, dman. keep up the good work.

commited with UI modifications as imagecache_image.module...

Functionality untested. cheers. open new bugs for it if they arise...

seems to work fine. but if one changes the imagecache-preset the derivates are not updated. one have to manually delete all the preview/thumbnail files on server.
derivate-images should also be put on the corresponding imagecache-folder not directly in the files/images folder (actually they are named xyz.preview.jpg & xyz.thumbnail.jpg directly in the files/images folder)

True.
This integration mimics the image.module behavior closely, just using imagecache processing at the time image.module wants to make its derivatives.
This is deliberately to be transparent to the other modules that are built around any of that existing functionality. Several (like lightbox) count on image derivatives being in the predicted location. Others check for the file existence, which would fail if imagecache was being dynamic.
If image.module makes a thumbnail, it saves it in the normal place. Yep. That's intentional.
If image.module rebuilds its derivatives, the derivatives get rebuilt. On demand according to image.module behaviour.

Basically there is no 'caching' magic going on here anymore, only the imagecache filter processing. This was initially created to support watermarking thumbnails etc that imageapi does and image.module doesn't.

This request is reasonable in other use-cases, but has some awkward implications, as the two modules work quite differently. imagecache doesn't keep a database list of files, so relies on just deleting full directories. That is incompatible with the way image.module keeps a list of attached files in the file table. Updating (removing) files would require sending messages to the DB that the files were now missing. Altogether not really what I'd intend.

An optional approach, with different code, that does what you want could be created, but it's essentially a different approach, code-wise.

I'm keeping this closed.. the integration is only to allow image.module to use the imagecache processing pipeline. You'll have to rebuild derivatives from image.module to update your thumbnails. It can be a time consuming process, but is intended to do things the way image.module does things.

When trying to use this, I pretty much immediately get errors (posting the form on the Image settings page) complaining about how a width and height weren't set. Then, it seems that the regular image derivative building is still taking place, and so I get a dozen pages of errors about trying to generate ""x"" images. I certainly expect bugs in any new or existing release, but am I completely missing something here or does this just not work at all?

So were the width and height not set? Is there a reason you didn't want to follow the instructions?
Image.module validation still requires them to be set to something, even if they are overridden or ignored by the imagecache process. It's sorta a quirk, but it's described in the help text there on that page.
EDIT:
Apologies, I was referring to an earlier version of the UI. I see the current DRUPAL-5--2 (dev) has been slightly modified.
But I'm not seeing the complaints you mention either. What exact image.module and imagecache.module checkouts do you have?

On investigation, it looks like there is an issue with the current 'imagecache' selector UI totally replacing the previous 'preview' and 'thumbnail' sizes. Although they are in the form, they are hidden.
Now, this works (for me) and looks a little better in the UI than my earlier attempt. But does force the user to go all-or-nothing. Either use imagecache for every resize, or none. No mix-and-match. Which does eliminate some confusion (which I'd introduced :-} ) over which dimensions really get used.

Although the hidden default thumbnail sizes still work as a fallback, they are not configurable.

The UI is simpler, and basically DOES work. But there's this hidden issue there. A tiny bit of lost/confusing functionality. I can live with it, but we can probably document it a bit.

If you enable "imagecache 4 image", all the resizing (derivative building) process will be taken over by your existing imagecache presets. If you want to change thumbnail sizes, create your own imagecache preset to do so, and select that in the image settings screen.
If you do not, image.module will continue to generate thumbnails but at the default dimensions which you can no longer change easily.

... I still can't replicate the errors PeteS describes. ( image.module DRUPAL-5--2 ) ( or DRUPAL-5--2-0-alpha2 )

OK, I've now been able to replicate the problem on a clean install(s)

Here's a significant re-write, that now uses the image.module 'operations' selector to choose the image process. So it co-operates with the image settings form instead of mutilating it.
... Actually, it SEVERELY mutilates the FAPI behind it by inserting the imagecache options, then extracting them, hiding them, and tricking image.module into thinking that all is normal. But the UI is perfect.
I've thrown out the theme overide we were using, and added logic to the validation phase.

So I'm attaching a D5 patch, the full D5 module file for convenience, and also a D6 port of the same thing!
The CVS I could see imagecache-6.x-1.0-alpha2 didn't even have this addition in it, so I guess we can call this a clean start.

Requires/works with todays image.module dev releases for D5 and D6. I hope they are stable.

Oh, better re-open.
Maybe I should have made a new issue ... but I had this thread open for a few hours waiting to post this fix :-/

I am also suffering this problem...

My 'hack' was to force the form value to 1 by adding this below the form_alter 'hidden' lines...

I've just learned the implication of this... When I submit an image using image_attach the image ends up being 1x1!

I might re-checkout the module and try your method @dman.

dman - I just tried your patch and am still getting the following issue when I submit an image...

The original image was resized to fit within the maximum allowed resolution of 1 x 1 pixels.

Is this related?

Ah fixed - using your patch I had to change the "Original" preset for an Image to Scale Image and then leave the width and height blank. Works perfectly now!

I can +1 this as "good". Nice one dman! :)

That hack was the first quick way out, yeah, but clearly it's cheating. Any problems you got would have been due to an unclean setting, I'm pretty sure you won't get that on a new site.
I'm happy to finally have fixed the UI. Ever since I started, the image settings table layout has been tricky to work around. Now I think it's the way it should be.
The code however could be mode drupal-hook-based instead of the form hack it is now ... but I'll bounce that off the image.module guys I guess.

bump.

http://drupal.org/node/231622#comment-973178
is a stand-alone update of the imagecache+image.module glue.
It only affects its own imagecache_image.module file, so won't break anything that's not using it.

It's got a D6 version too.

bump-a-dump

.... yeah, I definately should have made a new thread :-}

Noob here seeking clarification, please correct any of the below summary if I'm mistaken:

Function:

This allows one to use imagecache with the Image module rather than CCK/Imagefield, but loses the dynamic caching behaviour, only creating static derivatives, which will then be used as if they had been created by the Image module by all the other related modules that work with such files (files? - see below)

Procedure:

install and configure imagecache as usual

download imagecache_image.module.txt from http://drupal.org/node/231622#comment-973178 and rename it to imagecache.module

Overwrite imagecache.module in the imagecache folder with the new version

Questions:

Are the images ("original" + derivatives) files stored in the filesystem, or BLOBs stored in the database?

How specifically does one delete the derivative images previously created by Image module and force their regeneration with the new imagecache process?

How should this be set up to protect from this scenario: Image and Imagecache move on in the development cycle and no one does anything further with this fork?

TIA. . .

1 - they are files, stored in exactly the same way and place that image.module stores its an_image.preview.jpg files.
2 - image.module provides a 'regenerate derivatives' button for each image, and a bulk function through the content manager to do the same. Mass regenerations can also be triggered by changing any dimension in the derivative preset screen.
3 - There's been some support for this utility in theory, I'm not sure why we just haven't got around to rolling it in. I'm not pushing it in myself as a matter of courtesy, because as I submitted the change, I'm not also going to say it's RTBC.
But if at any stage you choose to upgrade to a clean, unpatched distro, then things will continue working as before, and the imagecache-processed derivatives will be overwritten by the plain image.module processed ones. You loose the feature by removing the code, but you don't loose any data or anything.

Thanks very much for your clarifications, seems like a good way to go and thanks for putting in your time to help END THE MADNESS that is images in Drupal

I'd also greatly appreciate (if you have time) your letting me know if I'm completely off-base with this idea on combining the two main methodologies:

"Images in Drupal - Future-proof methodology (Image module + imagefield together)"
http://groups.drupal.org/node/14974

Sorry to bother you Dan, but in following my above step-by-stop, I've just downloaded the current imagecache-5.x-2.x-dev from 2008-Jul-24. When I went to enable it, I saw along with imagecache module itself and its UI, a third module called "ImageCache 4 Image 5.x-2.x-dev Imagecache integration for Image module"

Q1 So is this equivalent to or later than your imagecache_image.module.txt contained in http://drupal.org/node/231622#comment-973178?

In other words am I good to go with the former without having to install anything else? Or is the latter one later or otherwise still needed?

And Q2 I've currently got Image v5.x-1.9 working, should I upgrade to 5.x-2.x-dev or 5.x-2.0-alpha3 (looks like they're the same) before enabling your fork? Note this is all going to be for a production site. . .

Finally Q3 is there anything we non-coding hoi polloi can do to help campaign for this functionality to get rolled into the mainstream Image?

Thanks for your help, and all your great work for the community.

Heh.
Sorry, I was severely jet-lagged last week!
I'd totally forgotten that "ImageCache 4 Image" is now part of the image package. It's a fully compatable and independant glue module. And I fixed up the UI better too. I should have closed this thread.

The glue module - available only to those that want it, not affecting those that dont, using only public hooks to do the job, is a perfectly fine place for it to live. No more action needed, just a bit more MEMORY on my part.

It should just bloody work, But probably it's imagecache DRUPAL-6--2, the 6--1 is quite outdated, and the alpha/dev has been stable for months.

Thanks for the lightning response Dan, and rest assured any and all brain-farts are completely by the by, your brain's forgotten 100x of what's in most of ours'.

I'm happy to know I'm good to go with that dev version of IC without needing anything further from this issue thread. And although I like the "just work" comment, I'm still a bit confused by your D6-related comments since I'm on Drupal 5.

Therefore I'm still not clear on what version of Image module I should be on to work with your "ImageCache 4 Image" module - a one-letter answer will suffice:

>> I've currently got Image v5.x-1.9 working, should I upgrade to A 5.x-2.x-dev or B 5.x-2.0-alpha3 or stick with C stable v1?

Thanks ²

Hope you don't mind me talking to myself here, but for the benefit of those coming here later. . .

I went ahead and tried implementing "ImageCache 4 Image" on a scratch site with Image v5.x-1.9, and so far everything looked A-OK, as long as I only selected IC presets for the first three rows in the Image UI (original, thumbnail and preview, left column options were grayed out.) But when I tried to fill in from no. 4 on, where there's empty left-hand fields to fill in with my own preset names, Image kicked out an error message about width and/or height not being set, as per http://drupal.org/node/231622#comment-938919 above. However, the traditional fields in the middle columns that were used by Image before for setting the WxH parameters are now completely missing from the UI.

I figured this may well mean I should be using Image 5.x-2.x-dev version (2008-Aug-17) so I upgraded, ran update.php selecting Image "5200", tables updated but no joy.

Trying another tack, I disabled "ImageCache 4 Image", went to the original Image config UI, put in dummy width values and saved, then re-enabled ImageCache4Image everything's hunky dory.

Uploaded a JPG and bah-da-bing bah-da-boom, one big original and 5 derivatives sitting in the Images folder!

BTW Q1 I still don't know whether I should have upgraded the Image to 5.x-2.x-dev or not, good thing I did all this on a scratch site :)

Subsidiary Q's:

Q2 I guess the imagecache folder will remain empty unless I start to also use imagefield access methods?

Q3 As long as I stick to Image type nodes (as opposed to Imagefield CCK ones), then Views (and everything else) should be able to pick these up as if they were Image-generated, right?

Q4 I wonder if I do start to use Imagefield nodes, can I configure it to use the same directory/filenames as Image? If not, NBD, disk space is cheap eh?

Finally, I'm so far a very happy camper Dan, thanks so much for this brilliant effort.

IMO this should get folded into the mainstream Image module now, one step closer to the grail of ending the insanity that is images in Drupal.

Maybe this is a good place for you (that is everyone but Dan da man) to put your +1:

http://drupal.org/node/145071

I can personally "+1" DMans patch from #22 with one "minor" tweak...

The patch worked PERFECTLY if I added one preset, but the second preset caused headaches. I ended up rounding it down to the fact that derivative generation was passing a "preset" over which has zero width and height. Fix? Simply add a hardcoded 1x1 width and height... Seems to fix everything :-)

I've attached my revised version of the patch... Anyone care to review? :-)

@nicholasThompson - I don't yet know how to patch so I can't test your code, but rather than working from the code in dman's post above, I reckon using the "imagecache 4 image" module shipping as part of the latest dev release of Imagecache would be the way to go. I had no problems at all with it once I created the "dummy presets" in Image's config screens before enabling I4I - these settings get ignored, but apparently need to be there.

Answering some of my own questions from knowledge gained in the meantime, again for the benefit of those coming here later:

Q1 still don't know, if someone gets the latest dev of Imagecache's imagecache4images working with the stable version of Image, please post here to let us know.

Q2 yes, Imagefield will dynamically generate its derivatives of images stored in ANY location and uploaded from ANY source simply by using its URL access scheme, and nothing will appear until then.

Q3 yes, so far all Image-module compatible add-ons treat the derivatives created by imagcache4image as if they were natively created by Image module.

Q4 haven't done any testing, but from discussions elsewhere seems to be a bad idea to have different modules "sharing" the same files - let each have full "ownership" over its own files, and if you need to say save images as nodes with Image module AND embed them in Imagefields, you need to accept the image files being duplicated in different folders.

I'm having a heck of a time retrieving imagecache_image from CVS.
It's there
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/imagecache/...
But doesn't seem tagged right, and is not coming with any checkouts I've tried so far.
Thus it's hard to update and test - at all.
Can someone investigate its CVS status?

OK. Here is a re-roll/re-port.
Working against todays imagecache.module HEAD (D6) and image.module HEAD (D6)

I sorted out the validation as per
http://drupal.org/node/318434

I've worked around the dimensions problem noticed in
http://drupal.org/node/303751 and http://drupal.org/node/329527

I added a trigger that DOES flush image.module presets when a linked imagecache preset changes as discussed ... um, in another issue somewhere. During testing I found it a bit unintuative, and image.module does just rebuild on-demand, so I'll let the system take the hit.

Hopefully the code is even tighter (I use more of the D6 Form API tricks).
Changed the description a little and the dependancies are imagecache and image.

The CVS branch this module USED to be on seems to be broken, so I can only imagine these files should be added anew. Can we try again?
If not, hey, it can even be downloaded as-is and be its own little working distro.

this thread was about D5 and image-cache 2.x

OK.
It was.
But this didn't make it in correctly back then, and the idea is that new features go into HEAD and get backported, maybe. So the issue was brought forward, even though there is a working patch there for D5.
If it makes you happier, I'll update the status. Done.

And just to confirm re D5, I've had zero problems with the "imagecache 4 image" module contained in

imagecache-5.x-2.2

working together with

image-5.x-2.x-dev-2008-Aug-17

I used the dev Image module when testing and never did try it with the released one, still waiting for feedback on whether that should work or not (I suspect yes)

There were issues with sizes getting unset or needing to be set to something to make image preset validation work, even though they were being overridden, but I think we've got workarounds in place for that.
There was just some sort of CVS split that made it tricky to check a fixed version out. The 'released' one is inaccessable to me :-/ Dunno why.

+1

this module is definitelly "TOP 1" glue module for Drupal.

one small question: have any plans for Drupal 6 version?

#39 is D6.
Just needs CVS love.

though now that imagecache is getting pretty stable i've come around to the idea of making the image module dependent on it for thumbnails. what do you think of moving this issue back over there?

Urr...
If you mean what it sounds like, that doesn't sound like a great idea to me.
I think there are a larger number of sites that get by with just the image.module quite happily - than there are imagecache.module users that don't use image.module. I may actually be wrong with the growth of imagefield + imagecache uses (?).

I appreciate the idea of reducing the duplication of the current 'scale' function provided by the basic image.module. But that's not a huge hit or inefficiency, and the ability to "just work" is not worth sacrificing to reduce the code by 3%.

I don't think imagecache should be made required for image.module. Adding a flashy requirement to a cool, simple, purpose-built module like that should not be necessary.

...although the derivative generation process could possibly be abstracted a little more to make it friendlier to plug the two together. ... even though this imagecache_image.module manages to do it OK, if a bit sneakily.

I still see the imagecache_image glue module as conceptually belonging to imagecache. Even though the code itself does mainly do its business by extending image.module, the functionality and feature set is all about imagecache.

subscribe

I'd actually like to see the integration. Looking forward to your decision.

@drewish: I'm in favor of moving it back to image.module as well...

I really don't mind where it lives - as long as someone wants it.
Please, just take it and commit somewhere.
.dan.

Yesterday I had a weird problem with the page where I'm using this page. An image where the derivatives had to be regenerated called convert with size parameter "0x0!" and I had a duplicate entry for "Original" in the image settings. I don't know if it's because of this patch or because of my test site (im trying out a lot of stuff, so it might be my fault). Did someone else see this already?

Image 6.x-1.0-alpha4, ImageCache 6.x-2.0-beta5 and this ImageCache for Image - Image derivatives cannot be properly set using ImageCache presets.

# warning: imagecreatetruecolor() [function.imagecreatetruecolor]: Invalid image dimensions in /public_html/d6abc/includes/image.gd.inc on line 95.
# warning: imagecolorallocatealpha(): supplied argument is not a valid Image resource in /public_html/d6abc/includes/image.gd.inc on line 97.
# warning: imagealphablending(): supplied argument is not a valid Image resource in /public_html/d6abc/includes/image.gd.inc on line 98.
and so on ....

subscribe

I tried the imagecache for image yesterday with a fresh Acquia Drupal install, but it did not work.

I set image to use imagecache to create the Original, Thumbnail, Embedded sizes. After submitting the dimension set automatically 1x1, and it is not ignored: when I create a new image it is inserted 1px x 1px size. :o(

I had the problem with the 1x1 images too. I found that any time I tried to let imagecache do ANYTHING with the original, it and all my other derived images became 1x1. I had to remove the imagecache preset and let the image.module handle the original image (you can still use the basic scale/scale & crop provided by image.module). All the other imagecache presets worked fine after I changed that back.

Edit: I may have spoken too soon. It seemed to be working fine for a while, but the 1px images are happening again.

Another edit: Okay, now it works again. Sort of. I flushed all the imagecache presets (again), and new images seem to generate derivatives properly.

Problem is, even though all the derivatives show up in the right sizes on the image node, if I try to insert them into a page, then img_assist turns them into thumbnails or 1px images (depending on the browser). Grr. Doesn't seem like an img_assist issue, because if I revert to the image.module presets, the image is inserted at the proper size (after recreating the derivative images). However, when I view the img_assist Filter tags, it gives the dimensions as 1x1 again. So I think somewhere along the line, the imagecache presets are failing to override the image.module dimensions (which I notice become 1x1 when using the imagecache for image module).

In case anybody is curious, I tried a fresh install with a different set-up. In both cases I started with the Image module, Imagecache, and Imagecache for Image (of course). However, instead of using Img_assist (a longtime staple of mine) and FCKeditor for inserting photos, I tried Image Browser and FCKeditor.

Works like a charm so far. No 1x1 images or reducing everything to thumbnails. Of course, imagebrowser is intended to work with both image and Imagecache, so..

Anyway, it looks like Img_assist was the source of my troubles. This new set up allows me to use Imagecache/Imagecache_actions on both image nodes and on images inserted into a text field via FCKeditor, thus meeting both my site requirements (images as nodes and automatic image sizing/watermarking).

the 1x1 preset was just a workaround because image.module wouldn't allow a preset without dimensions. imagecache actions do not all present a final size in a way that the rest of the image routines expect to see. imagecache is more flexible than was anticipated.

The fix - to allow the possibility that an image.module preset does NOT have a defined size - needs to be fed back to all the contrib modules that used to assume it was always there.
Try 1000x1000 - should work just as well.

I'll take a current checkout of the image* modules and see if there are still problems.

I need to test this out a bit more, but I'd love to see this module committed to the appropriate project.

Image Assist has nothing to do with this issue.

To revisit...
I'm doing a heap of image-suite revisions and updates this weekend (lots of docs in the works) and I'd like to see this glue module back on the table.

The bug touched on here is all stemming from the image preset size setting validation step

In order for imagecache_for_image to survive, that assumption that all presets return a fixed set of dimensions has to be worked around. Currently quite badly.

If that validation function also checked that the preset process was one of the known 'scale' or 'scale_crop' before setting its error, then the additional imagecache presets (which do not always know their size ) could be inserted into the pipeline without hackery.

If image.module allowed that, I'll do a re-roll and see where we are at.
I Do not know of the side-effects further down the track of having a preset with undefined dimensions. Does it give image_get_derivative_sizes() a division by zero? That's why I haven't tried harder.

.dan.

I'll test it any patch you post here. I need this integration working ;)

With the November version I've tried again, and it still works just fine out of the box - with todays checkouts of imagecache & image.

It seems that this IS all about img_assist! That's the only situation that I see reports about.

image module didn't mind having dummy values in the size array, but it seems that img_assist is requesting them and using them.
No img_assist, no problem.
This implies that any change will have some sort of downstream effect, and require a patch to img_assist!

I'll see what needs to be done to allow null dimensions to work within image.module, then we'll have to let img_assist.module know that it needs to allow for that.

Here is a re-roll
- the November version wasn't broken - it's just that img_assist (and possibly other extension modules) assume that image.module presets always have a known, fixed size.
I don't know what to tell them, when imagecache presets may have a width of '40%' or a canvas adjustment of '+20px'. They need to deal with a variable-sized preset.

This update includes a lot of tweaking. Importantly it now requires a patch to image.module that allows image.module operations to actually delegate to other modules.
The built-in image.module [scale, scale_crop] operations are hardcoded and limited. This patch attempts to fix that.

Now... image.module is unlikely to be officially patched in a hurry. New features in D7, ported back, yadda yadda.
But imagecache is into core for D7, so there should be a lot more synergy there. then.

If you want this feature now:
- use the November version, it's OK.
- If that produces problems with 1x1 images or validation complaints, use this version and patch image.module
- or if it's just img_assist that's bugging you, try fixing up img_assist to allow for undefined sizes.

I tried img_assist today, and it won't even place my derivative presets, so I don't know what's supposed to be happening.

@dman
Image module will be patched if patches have been tested and the maintainers agree to committing the patch.
I see sun has left this issue as being on 6.x-1.x-dev, so I assume he is in favour of this going into that branch. So am I :)

I've had a super-quick glance at what you've linked in the comment above and the first thing that springs to mind -- if you're patching image.module anyway, why not patch it to add a hook_image_operations, rather than shove your presets in with a hook_form_alter? Then image.module implements it, and so does your module. (And perhaps others, who knows?)

Good thoughts. I hadn't got that far ahead.
The history of this thing (heh, a year old this month) started off as an attempt to do something that worked but did not need code changes to either other modules. I guess I didn't get out of that mindset enough.

You are totally right that if image.module image processing is to allow 3rd party operations, then the form options should have that extensibility built in. The stupid things I've had to do via form alter could be chopped back down to three lines. Or rather, as you say, just an info hook.

obvious, thankyou. I'll have a look at that.

subscribe

subscribe

I lost Imagecache integration when "upgrading" from image module 5.x-2.0-alpha3 to 6.x-1.0-alpha4 and would like to get it back. subscribing ;)

Greetings, -asb

I've got an updated stream of this function available at
http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/dman/imagec...
I use this. You can keep up with this if you like. It works. So far. :-/

can anyone at last combine this peace of code into these modules???

subscribe

subscribe

and are people trying to make this work for both D6 and D5? I'm on 5.

@tevih i'm here for Drupal 6 and this issue also assigned to 6.x-1.x-dev

@tevih New features are implemented on D6. Once that is done, we can think about a backport.

@joachim, @tevih:

> New features are implemented on D6. Once that is done, we can think about a backport.

I'm getting very confused. The functionality dman is developing for D6 (integrating imagecache presets into the image module) exists for D5 for quite a while, at least I have a sub-module "ImageCache 4 Image" running in version 5.x-2.4 that works pretty well; according to /admin/build/modules, that module belongs ImageCache (does it? 437966). So I don't quite understand why it would be necessary to backport this (very cool!) feature since it seems to already exist...

A second thing I don't understand is the relation of the (latest) 5.x-2.0-alpha3 branch to the (latest) 6.x-1.0-alpha4 branch; if new features are developed for D6, I don't understand how this branch (with more features than the 5.x-1.x branches) came into existence; as far as I can see on my D6 sites, stuff like Image Galleries through views does not exist in the 6.x-1.0 branch yet while it is working quite nicely in the 5.x-2.0 branch already.

Sorry, but I'm really confused about this...

@dman:

I tried the imagecache_image module together with ImageAPI 6.x-1.6, ImageCache 6.x-2.0-beta9, and Image 6.x-1.0-alpha4:

1. Created a folder ./sites/all/modules/imagecache_image/
2. Copied imagecache_image.info and imagecache_image.module into this folder
3. Downloaded image-operations_hook-20090419.patch into ./sites/all/modules/image/ and applied the patch
4. Applied Imagecache's presets at ./admin/settings/image/nodes

Parts of the patch are rejected:

However, the Imagecache intregration appears to work quite well.

What can we do to get this into an official/packaged release, either inside the image module's contribs or as separate project?

Greetings, -asb

@asb:

- I don't know all the details of the feature in question here. Policy is to develop on the most recent version first. If something already works on 5 then great.
- about the branches: drewish began working on the 5-2 branch before Drupal 6 was released. I contributed the views stuff for image gallery. Then Drupal 6 was released, it took a long time for Views 2 to be released, and it took me a long time to get image support into galleries. There is now a patch for this by the way :)

I would say what needs to be done for this to be included is just the changes outlined in #66.

I don't know if this module is best kept as a contrib in image or imagecache, but I'm happy to have it here. Let's see what the other maintainer thinks :)

@asb thanks for the feedback.
I imagine image.module may have changed a little bit there in the last month. I'd advise you try to apply those missing lines by hand, because it does eventually have a pointless side-effect of not allowing you to route image derivatives through imagecache if you don't also add a (useless) dimension to the UI. This issue has popped up repeatedly in trying to keep up.

I think that postponing it all until D7 will be disappointing. The thing is, First we need both image.module and imagecache.module to be stable on D7 - then I could look at bridging the gap again. Because neither image.module or imagecache.module currently 'owns' this bridge, it's always falling through the cracks.

The patch I've put in there could, I guess be proposed for image.module D7. It is deliberately and carefully non-invasive, and just opens up a bit of room for this callback.
BUT

• With no imagecache for d7 available, this is impossible to test in D7.
• Therefore I can't really propose or put this new feature into D7.
• Therefore we are not allowed to put it into D6.
• Even though it (something similar) worked in D5.
• :-(

Yeah, this is a bit of a Catch-22.

Either I propose it to D7 with no test case or proof-of-concept. Unlikely?
Or we maybe eventually look at it again after imagecache goes stable on D7. :-C

If I thought there was a chance of this happening, then I'd be suggesting that image.module derivative building be reworked quite a bit to support this abstraction natively (and treat its own scale functions as callbacks alongside our new ones). But I don't know if that would be popular or possible.

I thought that imagecache (API) is going to core in D7?

reply to http://drupal.org/node/231622#comment-857078

Apart from this transparancy, what's the use of creating static derivatives through ImageCache? I thought that ImageCache was all about generating derivatives on the fly and thus removing the clutter of having an_image.preview.jpg, an_image.thumb. jpg, an_image.blablabla.jpg, an_image.so_and_so.jpg, etc.

When I came across this issue, I thought that this would finally suit my needs, i.e. using Image module (+ Image Gallery and Image Assist) but with dynamically generated derivatives from ImageCache.
Alas...

Are there any objections to this idea? Would it be so difficult to alter all the Image dependent modules to use ImageCache?

Quick idea: route the requests for a certain file to a function that determines whether to take a file from disk or to generate a derivative.

I don't know the inner workings of ImageCache or the Image module, so this piece of code may utterly useless.

+1 for imagecache_image

just subscribing.

Hello,

I would like to use imagecache 4 image, but i don't know how to patch original image module file with image-operations_hook-20090419.patch !

I understand that we have to modify these files by hand :
modules/image/image.admin.inc
modules/image/image.module
modules/image/contrib/image_import/image_import.pages.inc

But i'm not familiar with diff files found here http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/dman/imagec......

=> have i to remove line with "-" and add line with "+" ?
I will try that... and post here again...

Regards,
Vincent

OK, Great !
Work just perfectly !

but no file created in imagecache subfolder...
is it normal because file creation is handled by image module ?

Vincent

Working BUT not for original image !

I created 3 presets for original (resize to 1280pixels if image is larger than that), preview and thumbnail.
Preview and thumbnail images are successfuly created, but NOT the original one !

I have the original image file i uploaded, but not the "original" file that imagecache should create with my original "preset"...

Could anybody help me with that problem ?

Regards,
Vincent

#1 - in order to integrate correctly with assumptions all other modules (like lightbox, and image itself) make about presets - the derivative image is saved in the normal place images/imagename.preview.jpg - not in the imagecache directory.

#2 'original' means always original. It is never modified. The UI should probably take care to disable that option and make it clear that changes will not apply to the original.

Hello and thanks for your answer !

For #2 the drupal image module original behavior was to scale to height x weight fixed in the "original" image "label".
with that behavio it is possible tu upload uge image file but to scale and autorotate them to "normal 1280x1024" resolution...

So question is HOW could we handle original image file ?
We could not use original image moodule scale because it does not recognize EXIF, and don't autorotate files...
(autorotate with imagecache action in dev module)

Thanks again for your quick answer,
Regards,
Vincent

Really? Something must have changed since I last looked. I thought original was retained absolutely, because when next re-generating the derivatives, we don't want to be starting from an already-mogrified source.
(Bad things happen if you watermark your 'original' and then generate a watermarked 'preview' from that)

In your case, I'd create a 1280px 'screensize' derivative, and use that where you were previously using _original.
I'm not sure that the code should be changed to modify the 'original' - I see serious data loss possible if you do that. Imagine what would happen if you scaled the 'original' to 50% :-}

You can see just above the image size boxes : Note: 'Original' dimensions will only be used to resize images when they are first uploaded. Existing originals will not be modified.

The original image is modified if we put values in height and weight !
My Goal is to prevent keeping too big jpg files... that why i want to downscale image (if necessary)

The only solution is use original drupal image sacle... but then loosing autorotate... not possible...
AAAhhhhh !!
:o(

Thanks for your help !

Regards,
Vincent

dman, if you know, how to disable the UI check, or just know where to search... tell me !
Because with autorotate it is more important to use the first derivative rotate correctly than the original !
Vincent

I think it could be here, in image.module :

$all_sizes = image_get_sizes(NULL, $image_info['height'] / $image_info['width']);
foreach ($all_sizes as $key => $size) {
// We don't want to include the original.
if ($key == IMAGE_ORIGINAL) {
continue;
...
Vincent

I was look to apply this patch to 6.x-1.0-beta3 but assuming that won't work as the code seems to be all different. Is that correct?

I confess I no longer have any idea what this issue is doing.

I wonder whether the best thing would be to work in a new 6.x branch on the conversion of image module to be a simple wrapper for imagefield+imagecache. This would mean an upgrade script to convert all image data to CCK and the preset data to imagecache.

Perhaps that would be a good idea. It could also have a successor to image_attach through filefield_sources, with optional integration of img_assist/imagebrowser, or a successor for image_gallery either taxonomy- or views-based.