I've created a module which allows a user to force images to be converted to a specified format. The reasoning behind this is that we want to allow our users to upload images of any format, but for them to be viewable in a browser. I fear there may already be an easy way of doing this, but I couldn't find any option to do it.

The module provides an extra option "ImageMagick Convert All Files To" on the "image toolkit" admin page when using ImageMagick. Currently you can specify that all images be converted to BMP, GIF, PNG or JPEG.

Unfortunately I've had to patch the image.imagemagick.inc file to allow for this, although this change is very minor.

Files: 

Comments

Hetta’s picture

Tried it (put the new module into /contrib/) on 5.x-2.x-dev.
Works a treat, but doesn't rename the images to their new format (".gif" -> ".jpg")

sdrycroft’s picture

This is deliberate, as there is no feedback mechanism to tell a module that uses the tool kit that the resized image has had its filename changed.

drewish’s picture

Status: Needs review » Needs work

please don't post .gz files it makes it hard to visually review without downloading and extracting. why not just add this to the existing imagemagick advanced module?

drewish’s picture

Version: 5.x-1.6 » 5.x-2.x-dev

also, not fixing the extensions is kind of a deal breaker. if we need to alter the api to do that let's do this in the 2.x branch (actually this would only be committed to the 2.x branch).

sdrycroft’s picture

Any chance this has been done for the 2.x branch drewish? When do you anticipate this functionality will be in there?

webrascal’s picture

We experienced a similar problem in a recent project.
I found it safe with ImageMagick-6.5.1-Q16 to specify the encode delegate in every instance.

In image.imagemagick.inc:

  $source_info = image_get_info($source);
  $command = implode(' ', array(
    preg_replace("/[^A-Za-z0-9\!\.\-\+\_\/\040]/", '', implode(' ', $args)),
    $source_info->extension . ':' . escapeshellarg($source),
    $source_info->extension . ':' . escapeshellarg($dest),
  ));

meant that the source and the target would be encoded based on the original. image_get_info respects the filetype regardless of extension (.tmp in this example).

This meant I didn't have to define what we should convert all images to, instead trust on the other filetype settings to only give me the files intended for resizing and respect them individually.

Hope this helps someone out there!

Let me know if this causes further problems as a bit of free testing for everyone is always good and I'll look at fixing them up when I can :)

dman’s picture

Related - off-topic

When I did the same with imagecache_actions, I too had to do the binary conversion of the file format but left the filenames deceptively original.
I couldn't see a useful way to feed the renaming all the way back up the system there either.
In an imagecache pipeline of course, the browser is told to look for a filename, sites/default/files/imagecache/convert-to-jpg/myimage.bmp
So I was able to return the jpeg that was asked for ... although the file was stored mislabelled as a bmp. What to do?
I imagined a 301 redirect was the only way out of this dilemma - but somehow that was a little less 'cached' that we wanted.

sun’s picture

Project: Image » ImageMagick
Version: 5.x-2.x-dev » 7.x-1.x-dev
Component: imagemagick toolkit » Code

Moving to ImageMagick project.

andypost’s picture

I think format conversion is an advanced image style action matbe http://drupal.org/project/imagecache_actions a good home?

dman’s picture

as per #7.
I do a basic format conversion in imagecache_actions (most often to go to PNG when adding transparent effects to jpegs), however it leaves behind a nasty file-fomat/vs/file-extension disagreement.
I've done what I can from my end of the chain., but to fix it properly, we need to push some logic back to imagecache or somewhere to change the derivative file name. This however will have some side-effects on some places that assume the filename remains unchanged.

adrinux’s picture

This is something that's come up in the im_raw issue a couple of times too, people not understanding why they can't 'change' format - they most likely have, but didn't see a changed file-extension. (Yeah, this is a fairly vacuous comment, but it's better than 'subscribe').

worldlinemine’s picture

Would it make sense to instead of forcing the change of the file which results in the conflict, simply generate the various useful dissemination(s) and to use styles to make the file (for example tiff) visible by using those dissemination(s)?

Specifically, leave the uploaded tiff intact and simply generate cached versions of a jpg thumbnail (et cetera). If this would be a reasonable solution then perhaps this issue does belong in the queue for http://drupal.org/project/imagecache_actions ?

dman’s picture

It could end up in the imagecache_actions tasks to actually DO the conversion ... but the first issue is that the file needs to be able to be renamed based on logic that the action can influence.
Currently, the parent build_derivatives process always invents derivative filenames based only on the input filename. Can't be changed from my end ... yet.
So something needs to be put into eg, imagecache_create_url() or imagecache_create_path() that will be sensitve to filename rewrites,
(or the d7 equivalents of those funcs, of course)

sun’s picture

Status: Needs work » Closed (duplicate)