Please, provide the ability to specify width and height of resulting images.
Currently, the most simple workaround is to add fake effect which products output image of known size (see the screenshot, the second effect is actually 'Resize').

Comments

adrinux’s picture

Status: Active » Closed (works as designed)

This already works for me, but I think you may be having issues with your syntax.

This works for me:

-resize "1700x1000>"

This is doing something different, in that it resizes then crops but it works for me:

-resize 220x220^ -gravity center -extent 144x144

Also, adding multiple actions is perfectly acceptable, you can always use a normal drupal 'scale' or 'scale and crop' image style after any effects you apply with Imagemagick.

Does your command work as expected on the command line, outside of drupal?

OnkelTem’s picture

Let me clarify - I was talking about width and height html attributes on img tags. Do you get then in your example?

adrinux’s picture

ImageMagick Raw Effect module shouldn't have anything to do with with the html markup when the image is output.

Images should generally be output using theme_image() function:
http://api.drupal.org/api/drupal/includes!theme.inc/function/theme_image/7

Also just came across this bug for drupal 7.12 core http://drupal.org/node/1329586 which can result in height and width not being output. If you're not writing custom code it's possible you're suffering from this bug.

OnkelTem’s picture

Status: Closed (works as designed) » Needs review
StatusFileSize
new2.67 KB

@Adrian

I believe you still don't get what I mean. Here is a patch which does what I want.
Having width and height of replacement content is critical when you deal with layouting with js for example.

OnkelTem’s picture

StatusFileSize
new2.65 KB

minor fixes in codes' comments

adrinux’s picture

You're right. I have no understanding of why this would be needed. im_raw is about processing images, not output. Height and width html attributes need to be dealt with at output time surely? What would happen if another module modified the image before it was output?

Perhaps this is something new with drupal-7 image styles though...

It'll may be weeks, if not months, before I can take a proper look at this I'm afraid.

adrinux’s picture

Version: 7.x-1.0-beta1 » 7.x-1.x-dev

Should be against the dev branch.

OnkelTem’s picture

Still have to use this patch to get IM_RAW to not break effects sequences

OnkelTem’s picture

Title: Add Width & Height attributes » Provide sane dimensions callback
Assigned: Unassigned » OnkelTem
Category: feature » task
StatusFileSize
new4.84 KB

This patch is a rewrite of the previous #5.
It features ability to _keep_ dimensions of original image and makes UI more intuitive.
Please review.

OnkelTem’s picture

StatusFileSize
new62.1 KB

Addition to #9.
Providing screenshot of new UI of the effect:

41.png

Suggestions on better language are welcome.

adrinux’s picture

Apologies for the delay in looking at this. Nice work on the UI!
I see what the problem is now, but I'm not entirely convinced this is the right solution – surely there is some way to check image dimensions of the result and make sure those are passed along to drupal?

I'll take a closer look, if I can't find a way to do it automatically I suspect your solution is the only way to go.

To elaborate, one of the sites I use this module on has a command that produces different image dimensions depending on ratio of height:width (portrait vs landscape), I could go with your strip dimensions, but it would be nice to have the correct dimensions added.

adrinux’s picture

So, the symptom is this: images processed with this effect have no height and width attributes when output.

The problem: appears that we need to add a dimension callback, as you identified.

Solution: would be to add a dimension callback. What I still don't see is why we would need a UI for the image size, so I'm not going to apply this patch as is.

OnkelTem’s picture

Solution: would be to add a dimension callback. What I still don't see is why we would need a UI for the image size, so I'm not going to apply this patch as is.

As it follows from the screenshot, we have 3 different cases and it's up to a user to select how s?he wants to process dimensions.
We can't silently strip dimensions (current behavior) - variant 1
We may want to preserve dimensions - variant 2
We may want to type custom dimensions - variant 3.

How this could be achieved without UI, huh?

adrinux’s picture

Still looking at this, and beginning to see why you arrived at the solution you did: All the effect does is pass some ImageMagick options along to ImageMagick module etc.

As far as I can see we have no way of checking the effect result to see what it's image dimensions are. So we have to actually enter them in a form, to be passed along. This just seems so inelegant.

Assuming we use your patch then, I have some questions: why would anyone want to 'strip dimensions'? That option seems superfluous.
Keep and changed make sense though.

I wish there was some way to tell Drupal to update the $dimensions after the effect has run...

OnkelTem’s picture

As far as I can see we have no way of checking the effect result to see what it's image dimensions are. So we have to actually enter them in a form, to be passed along. This just seems so inelegant.

True.

Assuming we use your patch then, I have some questions: why would anyone want to 'strip dimensions'? That option seems superfluous.

This is for cases when an im_raw effect changes size of images AND when we don't really care about HTML width/height attributes (it is not error if we have none of them, right?). In this case the "strip" behavior is the only correct one.

I wish there was some way to tell Drupal to update the $dimensions after the effect has run...

The only dimensions data Drupal stores — is the original dimensions of an image. All (proper) effects implement transform_dimensions callback. The information on intermediate dimensions transformations is not stored anywhere.

adrinux’s picture

This is for cases when an im_raw effect changes size of images AND when we don't really care about HTML width/height attributes (it is not error if we have none of them, right?). In this case the "strip" behavior is the only correct one.

Yes, but what are those use cases? I can't think of any. And anybody actually wanting an image without dimensions can remove them at output time...

All (proper) effects implement transform_dimensions callback.

Yes, but they also generally know the dimensions that will result from the effect.
I'm still troubled by some possible imagemagick options, like resize shrink:
-resize 250x250\>
Which will only downsize to 250. If an image is smaller, it won't be up-sized to match – what dimensions do you then enter in the form? If you use 250, then smaller images will have the wrong dimensions.

In many ways I think actually just following up with a standard resize effect is just as good a solution.

Some other idea's: can we inject and enable an image style that detects and corrects dimensions after the im_raw style?

Perhaps what we should be working towards is an Imagemagick Raw Style, rather than just an effect. That way we could have a little more power...

OnkelTem’s picture

Yes, but what are those use cases? I can't think of any.

And you just given an example of such use case :) :

-resize 250x250\>
Which will only downsize to 250. If an image is smaller, it won't be up-sized to match – what dimensions do you then enter in the form? If you use 250, then smaller images will have the wrong dimensions.

And anybody actually wanting an image without dimensions can remove them at output time...

Writing a hook, catching specific image style, stripping dimensions... does it sound really easy? I don't think so.

In many ways I think actually just following up with a standard resize effect is just as good a solution.

This is most evident solution, I agree.

Some other idea's: can we inject and enable an image style that detects and corrects dimensions after the im_raw style?

I had similar thoughts, but I'm afraid we can't since image printing happens in two steps:

1) theme('imagestyle') creates <IMG> tag with attributes before an effect had a chance to run (at this step all effects are invoked to provide dimensions via that dimensions callback) (*)

2) real processing happens when a browser renders a page and request an image from "src".

(*) There is a pending patch for D7/D8 which makes image URL available for dimensions_callback. This may save us, as we can run an effect at theming :) The link: #1364670-9: ImageStyle::transformDimensions unable to deal with all effects.

UPDATE Changed link from 11th to 9th comment — to the correct patch.

adrinux’s picture

OK. Seems like you've figured out the least worst option.
I'll do some proper testing of this patch tomorrow.

I'd like to change some of the text - mentioning specific JS libraries or even talking about 'good' html seems out of place and a little verbose.

Also, I think 'keep' should be the default method, not 'strip'.

I'm happy to apply this patch and then make changes myself - unless you'd prefer to polish the patch?

OnkelTem’s picture

I'd like to change some of the text - mentioning specific JS libraries or even talking about 'good' html seems out of place and a little verbose.

Ok.

Also, I think 'keep' should be the default method, not 'strip'.

Since this implies that IM command doesn't change dimensions, I believe this should be bold in description, or people will get screwed images.

I'm happy to apply this patch and then make changes myself - unless you'd prefer to polish the patch?

No, it's ok. It's your turn :)

adrinux’s picture

Status: Needs review » Fixed

I've committed it. Kept the default to strip, after further though it does seems safer.

I made substantial changes to the form item description texts, hopefully to make it more explicit what is happening and why we need to set dimensions. And also trying to advise which dimension method to use when.

Should make it into the next release (which will probably be another beta).

Thanks for your work and patient explanation OnkelTem.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

asd as always