I am working with Drupal 7.
I would like to display images with reflection.

For Drupal 6 there is module Imagecache Effects that offers this option.

Can I add reflection with some custom php code?

Comments

dman’s picture

Looks like it should be possible with about 4 lines of custom PHP. (OK, a little more than that for clarity)
The imagecache_effects old code looks really scary at http://drupalcode.org/project/imagecache_effects.git/blob/e1b10c1602c5d1... But I guess that's because it's including transparency and resizing options into the same action??

A better place to start would be http://www.php.net/manual/en/function.imagecopy.php#85992

I would imagine something like:

  // Grab two copies of the current dimensions.
  $src = $image->info;
  $src['x'] = 0;
  $src['y'] = 0;
  $dst = $src;
  // Manipulate the dimensions to make the imagecopy reverse, eg
  $src['x'] = $src['width']; 
  $src['width'] = -1 * $src['width']; 

  $newcanvas = imagecreatetruecolor($src['width'], $src['height']);

  // SOMETHING like this, but maybe not exactly : This is pure top-of-my-head mock-up
  imagecopyresampled ($newcanvas, $image->resource, $dst['x'], $dst['y'], $src['x'], $src['y'], $dst['width'], $dst['height'], $src['width'], $src['height'] );

  $image->resource = $newcanvas;

THIS PROBABLY WON'T WORK as-is and has at least one serious mistake in as I've not tested it, just guessed.
But the SHAPE of this code - once you figure out which parameters are the real ones that need to be worked on - would be what you need to know about getting a manipulation like this to work at all in the context of customactions.

Get image,
inspect dimensions that are in the info array,
*do your thing*,
set the image->resource to whatever your result gd image object is.
return.

jobe12’s picture

Status: Active » Closed (fixed)
dman’s picture

If you've solved it, it would be nice if you could let everyone know how... please?

jobe12’s picture

I used jQuery, to resolve situation. It was more simple solution for me.
I used this reflection.js

steffenr’s picture

Finally i got the imagecache_fx module working with D7 - there was an issue that caused color-conversion to always return black. In the module attached to http://drupal.org/node/1035482#comment-6641640 you'll find a working version. Maybe we should include the module into imagecache_actions - would be a good-fit in my opinion..

SteffenR

fietserwin’s picture

Version: 7.x-0.0 » 7.x-1.x-dev
Status: Closed (fixed) » Needs work

I'm in favor of merging existing effect modules, so reopening this one in favor of issue #1035482: port imagecache effects to Drupal 7 in the seemingly abandoned module imagecache effects. Not sure if the code can be merged as-is as a submodule to this module.

@SteffenR: would you like to give that a try and post it as a patch/zip here. If it can be copied as-is, pleas post the zip here and set to needs review.

steffenr’s picture

Status: Needs work » Needs review
StatusFileSize
new4.82 KB

I did some code-cleanup / documentation - attached is a zip file containing an imagecache_action submodule that provides the reflect-action.
Thanks for reviewing the code.

SteffenR

dman’s picture

Status: Needs review » Needs work

On my first attempt to use this action, when saving the settings I got

Warning: Missing argument 2 for drupal_substr(), called in .../reflect/imagecache_reflect.module on line 299 and defined in drupal_substr() (line 515 of /Library/WebServer/Documents/drupal7/includes/unicode.inc).
Notice: Undefined variable: start in drupal_substr() (line 518 of .../includes/unicode.inc).
Warning: Invalid argument supplied for foreach() in _imagecache_fx_reflect_color() (line 301 of .../reflect/imagecache_reflect.module).

And no change in the preview image.
(on an older Drupal 7.10-dev I had handy)
... Oh no, I'm wrong, it's just that the small default 30px on the scaled preview was really hard to see :-) Maybe 30% as a starter would have been more obvious to me.

I bumped up the size and it showed up. Still getting the code notices however.

The description of the effect is somewhat misleading right now. It does not 'Reflect the image' - which would be a left-right or top-bottom reversal action.
This "Provides a reflection-like effect" by adding a faded copy of part of the image against one side to emulate a shiny surface. .. That's not the greatest description either, but 'reflect' is reserved terminology in image processing terms :-)

Not sure why, but the theme_imagecache_reflect() summary display didn't show up on the UI, it's supposed to summarize the effect when editing the image style. Maybe an upgrade glitch

Code:
I think it's inappropriate for this module to bring along its own color handling and parsing functions. I know they are ported up directly from the D6 version and seemed to be needed there, but we've got imagecache_actions_hex2rgba($hex) , so it really should use that to replace _imagecache_fx_reflect_color(). There is even a small form widget imagecache_rgb_form() with its own validation func you can use there for consistency with the rest of the library.
Supporting its own huge list of color names like 'DodgerBlue' is not something I think we should do in this module.

I'm not sure about _imagecache_fx_reflect_imagecopymerge_alpha(). I understand why it's needed, that's why we already have image_overlay() that solves the same problem. We shouldn't have two versions of the same algorithm in different files. If you can identify a reason why this one has an advantage over the current image_overlay.inc routine, let us know. I know it has more parameters, but in practice they are unused.

I don't see any imagemagick support, (which doesn't bother me TOO much yet) but there is not even any handling of the alternate library as it just assumes GD. This will cause it to blow up for imagemagick users, not just fail. Need to at least abstract to the image library in the imagecache_reflect_image function.

All these points are pretty small, and not a big deal if it were a limited-use one-off stand-alone module, but each is important enough if this routine was to come into the imagecache_actions library. I don't want one action to have a totally different way of managing color input than all the other widgets do - that's just frustrating.

Thanks for getting it this far. I think it will be possible to get it the rest of the way.

I don't want this library to turn into instagram with too many more one-click "special effects" but this one almost/just scrapes in as being straightforward enough with an OK, and common enough result. Ideally, I'd like to be able to chain some lower level actions like (copy, flip vertically, apply gradient fade, append copy to the bottom of original) to produce that effect (as that toolbox would be more useful) but those actions don't exist yet and this result is - fine. :-)

.dan.

jamesbenison’s picture

StatusFileSize
new10 KB

Dan,

I did some clean up work to get the imagecache_reflect module above working correctly. I don't really address the points you brought up though. And it still needs some documentation and more code cleanup.

Drupal 7.20 broke the reflect script on the imageflow module. It cannot be fixed as that reflect.php script uses a query string. The only sensible solution is to create an image module with a reflect action. The attached module works with an updated version of imageflow I made, but I haven't commited that code yet 'cause this reflect thing is still kinda in limbo.

It doesn't make sense to make this an imageflow submodule. I'd also rather not create another drupal module as a stand alone for reflections. It makes the most sense to have it in your library (to me anyway).

If you are open to that idea I will fix the things you mentioned in #8 and submit a patch. I didn't do it yet 'cause those changes will make this imagecache_reflect module dependent on imagecache_actions.

Let me know what you think.

Thanks

Jim

jamesbenison’s picture

I set up a sandbox for now for the reflect module. See here. That's probably the best place to find the most up to date code until we can figure out who's going to maintain it and where it's going to live.

dman’s picture

It's certainly easier for code review :-)
And means it's still a stand-alone thing that can be used or tested as-is.

Eg by the automated review tool
http://ventral.org/pareview/httpgitdrupalorgsandboxjamesbenison2039279git

dman’s picture

Note, I'm not saying that that review is anything to care too much about - it's all just about whitespace and comment syntax by the looks.
I was just giving a thumbs-up for the sandbox approach

jamesbenison’s picture

Holy smokes! Lots of little details. I obviously didn't run it through coder yet.

Thanks for the heads up. I'll take care of it when I have a few.

dman’s picture

Note that Ventral and coder.module don't agree on everything. Ventral is a lot more picky.
But it's a fun brainless exercise to clean stuff up with.

jamesbenison’s picture

dman,

A few things:

I'm not going to lie, but I think the implementation of adding colors is better in this module than in yours. Using your color management would be a regression. I absolutely agree that there should be a common way of managing colors. I disagree that supporting obscure colors like "DodgerBlue" is necessarily bad. Once named colors are supported it does not matter if there is just a few (like red, white, black) or hundreds (like "Salmon" and "DodgerBlue"). They are all just added to a supported colors array.

If I was in charge of the world I would change imagecache_actions to use color support and form validation more along the lines of how it is done in this module. That validation function I wrote is only a few lines. Stick all the colors in an imagecache_actions colors.inc file and it would actually work as a real color library. Right brained people are not going to want to use hex or rgb. If you are interested I will create a patch.

Let me know what you think about that and whether you think this should be released as part of your library or as a stand alone project. I'm tempted to promote it to full project, but truth be told I already have too many projects and I can be a horrible neglectful module maintainer. I've contacted StephanR in the hopes that he might want to take this on.

Best

Jim

jamesbenison’s picture

Also that colors array could easily be used to populate an autofill.

jamesbenison’s picture

I just made this an official project. My time for doing drupal development is limited, so when I have it things must happen.

As usual I am looking for co-maintainers.

dman’s picture

Status: Needs work » Fixed
StatusFileSize
new219.11 KB
new54.56 KB

That's probably the best way to go. I'd look at this specific reflection effect as a one-off 'special-effect' rather than part of a toolbox of re-usable image manipulation routines, so it would be a bit of a step-child in this project. Not really something I'd be spending a lot of time supporting.

I'm still not keen on color-name palettes, because list like the last one I encountered make me think that someone has missed the point of using memorable names or got stuck in the 90s. But if your "right-brained" people really prefer words to the actual representation of the color, I won't argue with them.

I don't think even autocomplete would solve the actual issue I see. Pretty soon you may as well display the whole chart of words so folk can see them.

And I can't see that the farbtastic colorpicker that the imagecache-color.inc subform uses can be called a *regression* from that.

However

What certainly could be called a regression is that it seems that - at some time in the D7 core upgrades - the way that we call the farbtastic library that comes with Drupal was changed. It's been in D5 and D6, and I'm pretty sure it was still working in the first D7 -dev release. This means, that depending on your combination of versions, there is a good chance some people never even noticed the full color picker in action recently. It just quietly failed to render. Graceful degradation eh?
Still, the references to the farbtastic tool were still all through the existing color-picker form you reviewed - when you compared the existing utility-color.inc validation routine that you say your version is an improvement upon, yeah?

I just had a poke in there now and saw that, against Drupal-7.22, Imagecache_actions 7.x-1.3 it wasn't actually working as before. THAT is a small bug to take care of... I've now changed the way the JS library was being called, and the update is back in the 7.x-1.x-dev code now.

Just as well you brought it to my attention! I'd not even noticed it had stopped working either, as I work with designers that have specific palettes I have to match, so most of the time I have an exact RGB color to define to meet their requirements. I got so used to using specific colors (HEX-RGB) I didn't even see the picker tool was turned off!

jamesbenison’s picture

When it comes to the colors you are preaching to the choir.

It's amazing how we can take simple things and turn them into a complicated mess. At the end of the day it's because they need to appeal to lazy people.

I need another drupal module like I need a hole in the head. Too late, I have another hole.

Status: Fixed » Closed (fixed)

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