Image Rotation setting for individual ImageFields

I think this will be a great feature for 2.1... I may want to implement it slightly differently and use a work around for GD2 without imagerotate support. I'm not sure that image.inc tests for this. But you can create a new image and copy it over pixel for pixel if imagerotate isn't compiled into gd.

just FYI.. I'm still totally in love with this feature... I would like to see it use ImageAPI instead... Cuz I don't have ImageRotate support in my GD.

The attached patch uses imageapi with a fallback to image.inc. I wasn't sure if it needed to do some imageapi error handling, so I didn't add any.

There were some problems with both the GD2 and ImageMagick toolkits when rotating images. I'll file issues and reference them here. After applying those patches, rotation should work fine with both toolkits.

I did notice some problems with imagecache after rotating the images. I usually had to reload the page a couple times before the correctly rotated image was displayed for each preset. I'm not sure if the call to imagecache is wrong or there's a problem with imagecache. I'm using imagecache 5.x-2.0.

The rotation only happens when you're updating a node, not on the initial insert.

Updated patch so it works on insert, too.

Works excellent for me! THX!

Awesome! This is just what I was looking for. This is a critical feature.

Thank you much.

For usability, I think a better Labeling, should be:
90 clockwise
90 counter-clockwise
180 degrees

I don't know how to do patching, but the changes are:

Change lines starting 807 at imagefield.module, from:

        $form[$fieldname][$delta]['rotate'] = array(
          '#type' => 'radios',
          '#title' => t('Rotate clockwise'),
          '#options' => array(
            0 => t('0°'),
            90 => t('90°'),
            180 => t('180°'),
            270 => t('270°'),
          ),
          '#default_value' => 0,
        );

To:

        $form[$fieldname][$delta]['rotate'] = array(
          '#type' => 'radios',
          '#title' => t('Rotate'),
          '#options' => array(
            0 => t('0°'),
            90 => t('90° clockwise'),
            270 => t('90° counter-clockwise'),
            180 => t('180°'),
          ),
          '#default_value' => 0,
        );

Also, why the float: left in the radio buttons. Doesn't look good good, IMHO.

And one more: can the image be displayed in the rotated mode while editing the image? Because now, when editing the picture and changing the rotation will rotate the already rotated image. So either:

1) display the currently rotated image in the editing, or
2) display the original rotation while editing, but also default select the current rotation (and if changed, apply it to the original)

Thank you!

Update:

I noticed that the image is actually rotated in the edit, but because of the imagecache problem Junyor described, it doesn't show up until refreshing one or two times.

The imagecache flush is now located at the _imagefield_rotate -function. Is this a good place for it or should there be more places where to flush the cache?

Whats the status on this patch. Any chance it will put into the 6.x version? I am not really a coder, but I can help test it out.

IMHO alternation of the uploaded image in imagefield isn't optimal. Rotation will always lead to loss of data and it is always nice to keep the original file in one piece. If I understand things correctly this patch rotates the original image before storing. Depending on the rotation toolkit you also loose EXIF information. Rotation should be presentation layer work, i.e. imagecache.

I'd rather see f.ex. an imagecache module that serves as an 'editor' for images/files, with interface in the imagefield widget.

I've just written a module with an imagecache action that rotates images according to the EXIF orientation field, and this has led me to thinking in more general terms. Would it not be nice to provide the imagecache actions in some way to imagefields individual, i.e. in the node edit form?

Ok, I'm beginning to mumble, but my point is that to keep the imagefield as general as possible you should leave the image rotation apart from the original image.

@kaare: i agree 100% here regarding the pristine condition of imagefields but we might have to consider a few concessions when the image is serveed on on the node edit form, and other otherwise "non presentational" conditions. Again implementing imagecache support for these displays might be a good idea but it might add too much clutter for too little gain.

I don't think this will make it into the D5 version (sorry everyone that worked hard on this) since I'm putting it into "maintenance only" and only D6 is getting new features. Due to the significant differences between D5 CCK and D6 CCK, maintaining both versions is like maintaining two separate modules.

A few more things I'd like to see in this:

- The rotation should be two buttons (preferably an image with little rotate icons) for clockwise and counter clockwise, rather than radio buttons. Though we can still use the same logic for generating the final image since we don't want the change actually saved until node save. With both the current approach and this new approach though, we have the problem that preview does not reflect the rotation settings.
- The ability to rotate needs to be configurable when setting up the widget.
- Needs to be ported to Drupal 6. :)

subscribing

Ok, here's a start on a D6 port of this patch. This should 'work' but some of the implementation is wrong and it doesn't address all the requirements from 15.

1. Using hook_nodapi to process the fields. Wrong, wrong, wrong, but I'm not sure of any other way to intercept the elements until http://drupal.org/node/417122 happens.

2. Admin previews, imagecached files, and prob the raw image are cached by the browser so you don't see the updated rotated image unless you refresh the browser. Not sure how to force the browser to request new versions of files. Could be solved by renaming/moving the filepath and saving the rotated image as a new file?

3. Widget not configurable per field. Should be easy to add if anyone has the time?

4. Uses a dropdown to select the rotation, sorry just thought it was neater and didn't have time to do buttons and images etc.

5 Could do with a class on the widget, not sure how to add that.

The Image Cache Action module already handles rotation

But only on a per imagecache basis. This feature request is to allow rotation for individual files by content editors.

In the OS exif data is usually used to rotate an image for display, so you get users confused as to why their images are wrongly rotated once they're uploaded to the server, when they look fine to them in Finder, Explorer etc.

Thanks muhlender for your work on this. I think you should be able to eliminate the use of hook_nodeapi() by using hook_elements() instead, then you won't have to find the individual fields in hook_nodeapi() or hook_form_alter(). See FileField Insert for an example of how to modify the field on a per-field basis rather than using hook_nodeapi().

But as for settings (which would definitely be nice to have), that definitely requires #417122: Allow drupal_alter() on Field and Widget Settings, which looks like it's making progress.

Ok, here's an updated patch. This should take care of most of the requirements, so tentatively marking as needs review.

Changes from last patch.

1. Added ability to set rotation option on a per field basis, using #417122: Allow drupal_alter() on Field and Widget Settings. Followed code from one of the other modules using this now.

2. Fields processed using imagefield_widget_value() function, where imagefield data items are already processed.

3. Added javascript rotation to the images using the jquery rotate library from google code. Worth renaming the library function in case another module uses it? or use Libraries API, but then you have another dependency?

4. Changed dropdown to left and right buttons where javascript is enabled. JS to calculate rotation is slightly clunky, but there's a tradeoff between making the js simple and the php form processing simple. Went for making the php simple.

5. To force the browser to display the rotated file, I've saved the rotated file to the temp folder, and then created a new file/object using filefield API. The file rename here seems to be a bit wonky, if you rotate a file several times you get filenames like muhleder_3_0_0_0_0_0_0_1_0_0_0_0.jpg. Need to take a look at this.

So prob not quite ready, but it should be quite a lot better than the last version in UX and functional terms so worth letting people have a look at.

subscribing

very interesting. subscribing :)

+1 Very awesome patch!

This patch fixes some bugginess I found in the javascript: It kept adding the rotate buttons over and over.

Also fixed some code/comment style issues.

I didn't understand why we needed a imagefield_widget_settings_alter() when we are defining the imagefield widget settings in the same file. So I moved this stuff up into the main widget settings functions.

Hiya mfb,

been a while since I looked at this, but off the top of my head I think the widget_settings_alter was to allow site builders to choose whether or not to have the rotate widget on per field basis.

Yes, the widget_settings_alter was used to provide this setting for each field. But why not create this setting in the main form definition a few lines above. the widget_settings_alter seemed superfluous.

Any news on when this will be posted to a full release? It would be helpful.
Thanks! :)

This probably won't be added to the official release of ImageField, since this entire module has been moved into core in Drupal 7. In order to have a linear upgrade path in the future, I'd suggest that this modification become a separate module that extends ImageField, similar to the way that ImageField Extended works.

Rotate images individually w/ImageCache

I've created this set of modules that lets the user rotate images (imagefields) on a per image basis. The actual rotation is done by an ImageCache action, and the UI is presented in the ImageField widget.

This is basically just a proof of concept of what I mentioned in #13. What I'd really like to see, or implement, is to have the whole array of imagecache actions exposed on a per image basis with a simpler / more user friendly ui for the user.

I'm posting this here to emphasize my point that this can and should be solved on display/render time and that this issue therefore belongs elsewhere (ImageCache, maybe)

Let me know what you think.

+1 subscribing

*comment removed*

Sorry, wrong issue.

subscribing

Thanks for this - I've installed the modules on my test site and it appears to be working properly.

I agree with your concept - extra per-image features would be extremely useful on many sites.

subscribing, +1 for per-image settings

This isn't being added to ImageField directly, as I suggested, please make into a separate project (merging into ImageCache isn't a good option either, since it's also been moved to core, maybe ImageCache Actions?).

subscribing

subscribing

I don't want the users of my site to rotate and actually save pictures with correct positions, however I would like to provide to users a possibility to rotate on the fly during viewing of the pictures like it is done on twitpic.com, for example. They use http://jquery-rotate.googlecode.com/files/jquery.rotate.1-1.js I tried to add <script src="http://jquery-rotate.googlecode.com/files/jquery.rotate.1-1.js"></script> in page.tpl.php and wrapped image field output in all the necessary divisions, unfortunately it still does not work. Could someone point out how to jquery.rotate.1-1.js for on the fly rotation, please.

Update: After careful adding all the classes and divisions, I've finally got it working.

Here's an example of how to get this working:

Add the .js file to your scripts directory and include <script src="/scripts/jquery.rotate.1-1.js"></script> in your page.tpl.php header.

Add the following input button to your template, page or node file, depending on where your image appears:

<input type="button" value="<-Rotate" name="RotateL" class="inputSubmit" id="RotateL" onclick="$('.imagefield').rotateLeft();"><input type="button" class="inputSubmit" value="Rotate->" name="RotateR" id="RotateR" onclick="$('.imagefield').rotateRight();">

You'll note that this is acting on the default "imagefield" class of your CCK image filefield.

Cheers

Note that the solution in #40 & #41 will not permanently store the rotation.

The patch in #26 works, and stores the rotation. Thank you! Applied to imagefield.module in imagefield 6.x-3.7. Using with latest stable builds for Image API and Image Cache.

Patch in #26 worked beautifully for me too. I wonder if there might be a way to support swfupload - bulk image uploader (http://drupal.org/project/swfupload). The rotation option is available for fields of that widget type, but when I check it and save, it doesn't stay saved.

Thanks lot. Just what I needed. its working fine.

Per #37, this will never be added to ImageField directly, it will need to be implemented as a separate project since ImageField has been moved into core.

So... patch #26 apparently works beautifully. But won't ever be incorporated.

The module in #31 works beautifully too! Thanks kaare! Just "installs and runs", nicely documented, and even a separate module to work around a specific bug! It's a shame that this is lying around lonely in an issue queue for so long.
Just wanted to mention that again. And renamed title to better show what the module does.

I can see why you want to have this module be more 'generic' and apply to more ImageCache actions. Sorry, no time to do it myself :)

Since this will not be implemented in ImageField... I'm changing the project, just to see what people say about the possibility to distribute this as an extra module along with the Imagefield Extended project.
Imagefield Extended has nothing to do with ImageCache...
...but that is only part of the code. And the biggest chunk of code / issues to be tackled, is the same for both I.E. and this module:
- providing a UI for more actions (could the module in #31, if it gets extended, benefit from depending on code in I.E.? I haven't looked...)
- integration of the form items in other widgets (i.e. swfupload). That is on the wish list for both.

A 10sec review of this thread is pointing towards an independent module for the task at hand. As per #31.

subscribing

Created a sandbox project for the module as it is in #31. Hopefully I'll have some time playing with a more generic solution soon.

I read #13 about rotating at the UI vs a one-time action on the imagefield, and I think from my perspective (at least for my site) a one-time action is preferable to a presentation layer solution using Javascript to rotate. I'm dealing with images that number into the hundreds of thousands - and that's before any presets are created. Considering that the rotation is simply to 'fix' the picture and it's a once and done action, from a performance perspective my thought is that it's better to do it one time. Otherwise it's adding a new table to the database, adding SQL queries to determine the proper rotation angle, and then using the UI to rotate appropriately. For most sites that may not be a bad thing, but for simple rotation it seems like a lot of work.

Not sure how I'm going to approach it yet, but I'm on a quest for simple, one-time, server-side rotation via ImageMagick + Imagecache.

Unless someone can point this issue to a new home, I will be closing it as a "won't fix" as this module is not the right place for it.

@kaare
Do you still have plans for your module?

@Alan D: Unfortunately, no. Not for D6 anyway.

Closed because Drupal 6 is no longer supported.