Search

Hi, I was thinking about thumbnails last night in Symphony and I think I came up with a great idea for an extension, the only problem is I don’t believe the JIT Image Manipulation Extension will allow it in its current state.

My idea is to have a file/image upload field which, once the image has been uploaded, adds a movable focal point, (exactly like to SlideShowPro Director) the co-ordinates of this focal point are updated by javascript and added the hidden field which are saved along with the original dimensions.

Then when calling out the data, you pass the mode/width/height/co-ordinates to JIT to process the thumbnail.

Why go to all this trouble? When looping through news entries for clients websites, oftentimes the images end up getting cropped in the wrong places (e.g. the tops of peoples heads being cropped off). Using a focal point/co-ordinate based crop would allow clients, who don’t know how to process images, the ability to choose whats important in an image.

I think it would come in very handy, I’d start on it myself if there was more info on the Extensions API, but what do ye think of the idea in general?

Yes, this is a muchly good idea and one I have considered before. I had vague ideas for an all-encompassing “Image Upload” field that had a variety of manipulation features specific to images:

  • specifying a maximum width/height, if above the image is either rejected, or resized down the maximum once. This prevents 10MB digital photos being sent to JIT, putting load on the server
  • specifying target width/height (or just aspect ratio) to allow a user to crop the image completely, perhaps using Jcrop

This is a pretty large undertaking since JIT doesn’t support this. However JIT does support 9 crop positions which could be selectable in the UI?

Couldn’t the JS just calculate in which of the 9 JIT positions the focal point is located, then store that?

I could see an extension to create an image cropping/focal point field that has the little 9 quadrant table overlaid on the uploaded image so you could easily specify where to keep the focal point. Then you can use that data when you use the image in your templates.

I think this would be a cool feature, and probably pretty realistic to implement, but it is still kinda limiting. Now, obviously I’m just a designer, so I have no idea what goes into programming these things on the backend, but it seems like implementing something like an image cropper wouldn’t be too hard since there’s a lot of code you can borrow from like the JCrop jQuery image cropper. It even includes instructions how use the GD library.

I did a few mockups of my dream Symphony field: Image Crop Field Example 1 View Larger

Image Crop Field Example 2 View Larger

So yeah, that would be my dream field. I have no idea how possible/plausible it would be to put together an extension, but if anyone wants to work on it I could certainly contribute ideas/visuals.

ashooner: yes, the JS could figure out the 9 JIT positions, one way would be to add 9 divs to a container div, figure out the dimensions of the image and divide the width and height by 3 and style the divs to those dimensions, then overlay them over the image and set up some js to select the div on hover and add that to the hidden field.

But…its still not perfect, the focal point idea is a far better method in my opinion, although TheJester12’s mock-ups look pretty sweet too. I think the advantage of focal point cropping over selection cropping is that if you ever need to change the dimensions of the thumbnail you need only change the width and height in the JIT script (or something similar) with the selection method you need to go back and select a smaller crop, also I don’t know how easy it would be to upload the large image and cache thumbnails from it with the selection method, probably a lot of work though.

Yeah, that’s true that the JIT image manipulation is better if you ended up changing things in the future. Although I was kinda thinking that maybe that’s where the checkbox that said “Use as aspect ratio” might come in. So instead of specifying a specific pixel width and height, you could just say height: 3, width: 4, and then it would keep a higher quality version on the server and you could still potentially use the JIT resizing on the front-end?

I dunno, just ideas. I guess I always just think that a person will always make a photo look better than a program. As a designer, I don’t like to lose the control.

@TheJester12: A JCrop field has been on my list of things to do for a while. My plan was to modify the JIT extension to accept another mode of cropping that would correspond to the output from JCrop.

I’ve knocked up a version of the JIT Image Manipulation extension that allows you to more specific cropping. It’s available on GitHub if anyone feels like testing it. The URL syntax is along the lines of:

http://blah.com/image/4/200/200/50/50/500/picture.jpg

Or rather:

http://blah.com/image/4/new-width/new-height/x-offset/y-offset/resize-factor/picture.jpg

Note that the resize factor is out of 1000 to allow for reasonable granularity. I haven’t tested it particularly extensively, but it’s a start.

@Makenosound thats, awesome, I might try making a jquery focal point plugin over the weekend if I get a chance

I started building an (at the moment) all javascript Image Cropper extension using Makenosound’s version of the JIT Image Manipulation extension and the jQuery Jcrop plugin. It can be applied to upload and textarea fields for now.

To work with sections with upload fields, the extension needs six extra fields for the coordinates. While cropping an image those fields are filled with the according values and saved to the database. You can then use those fields in your XML/XSLT to output an URL for the new JIT mode.

Image Cropper for upload fields big version

For the usage with textarea fields, the extension prepends a link to those fields. The link opens a modal dialog where you can put an URL to an image to start the cropping funcionality for this image. After confirming, the extension appends a link with the according URL for the new JIT mode.

Image Cropper for textarea fields big version

I uploade a quick video where you can see the usage.

Symphony CMS Image Cropper Extension Demo from Jonas Coch on Vimeo.

I’m going to release the code after stabilizing the extension in the next days as an alpha version.

The next steps are to polish the interface, to implement configurations like minimum and maximum dimensions and aspect ratio and to combine it with other extensions like the Mediathek or WYSIWYM/WYSIWYG editors.

@Makenosound: Would it be easily possible to implement another mode for JIT that resizes the image to a fixed size after cropping it with the given coordinates. I would like to program it myself, but I’m more a frontend guy than a backend guy.

Wow! Great work on this! Looking forward to giving this a spin.

Very nice!

Awesome, you’ve done what we’ve all just been thinking.

I have a question, what would you think of storing the coordinates in something more compact than actual data fields? Couldn’t you store them as a single url string that you end up using with JIT, or does that present other problems?

klaftertief: Not sure how easy it is but I’ll definitely have a look into it. Great work btw, it’ll be a wonderful addition once complete.

Thanks for your kind words.

@ashooner: I want the extension to be as flexible as possible in regard to the backend administration and frontend output. The main principle is that you have only one resource of an image with multiple output possibilities.

On the one hand i can imagine a new section field with strict image options like max/min size and ratio and URL output for a selected JIT mode. (That’s more a PHP/database/field-extension thing and as mentioned, I’m more comfortable with frontend development.) My counterquestion: is there anything to consider with using actual data fields except the additional adjustments? (For me it was the easiest implemantation and it shows the flexibility of Symphony.)

On the other hand I want to have the editor/administrator to have the possibility to choose the display (JIT method) for the frontend output in dependance to the context. So I dont’ want to save an URL string (that means a fixed frontend display). I want to have the editor to be able to choose the clipping and optionally the width/height of an image with the possibility for an admin to overwrite the sizing options. I think it’s the easiest to save the plain cropping values (choosen by the editor) with optional sizing attributes defined by an admin for th specific section.

(Please excuse my rather complicated expression.)

My most immediate problem is the possibility to save configurations for different and multiple fields in different sections. At the moment I think it’s better not to define new section fields for the different purposes. Is this possible without defining new fields?

@Makenosound: What does the resize-factor actually do? In my installation it resized the image given the facor leaving a black background. See image with factor 1000 compared to image wth factor 400.

I hope I’ll have news during the week.

ashooner: glueing them all together would also break database normalization rules.

Doing that in the XSLT will only require a small utility, should be easy to implement.

@klaftertief: The resize factor is intended to let you scale the cropped portion—the reason it’s a factor of 1000 is to give you some flexibility. Unfortunately when the new size is too small it just shows black, you can see it more effectively on an example at 500 (so 50%).

Perhaps a better way to do it would be:

image/4/crop-width/crop-height/xpos/ypos/resize-width/resize-height/external

Where crop-width/height is the crop from the original size and resize-width/height is the output size. It’s starting to be a bit convoluted though. The other option might be to simply specify a max-size that limits the longest side to that. Thoughts?

This implementation of a new mode is exactly what I would like to have. And thanks for your clarification on the resize factor. I was puzzled about the black parts.

I think that it’s important, from an authors point of view, not to change the clipping of an image. For an admin it’s important to have control over the maximum an minimum width or height of an image. So I think we need the flexibility of

image/4/crop-width/crop-height/xpos/ypos/resize-width/resize-height/external

combined with restrictions in the backend (provided by the image cropper plugin) for aspect ration an min- and max height and width.

So

/crop-width/crop-height/xpos/ypos

comes from authors and

/resize-width/resize-height

is defined in the template with an option to define only one size, like

/0/resize-height

This is great, I’d love to give it a whirl when you feel like its ready to test out. Thanks a ton for your hard work on this!

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details