Image additions

[Pete]

After playing with uploading images, I'd like to suggest a few things - some of these may already be possible but I'm not sure as I've only just started using the software so please bear with me:

• The ability to set default thumbnail sizes in the backend editor - either globally or on a per-template basis would be nice so that content editors don't need to resize thumbnails manually if there's a preferred size
  
• When editing an image to set a link to the larger image, it would be nice to have a box with width and height in a bit like the TinyMCE editor has by default - it's very hard to drag the image to specific size such as 160px wide whereas typing it in would be easier
  
• Perhaps the option to have any image dragged into the editor create a link by default - maybe even the option to have a combination of the above so that you could set up a template for content editors so that as soon as they drag in an image it's the right size and pre-linked to save them work. Of course all that could be on a per-template basis
  
• A maximum image size setting - everyone knows someone who doesn't know what "resolution" means and will likely upload a 3000 pixel wide photo. It would be nice to be able to set a maximum resolution so, on the off-chance someone does upload a large file, the default image stored on the server is resized to fit in with this setting
  

Granted these might sound like very specific things that not everyone would want, however I wonder if they could be considered for a future release or some sort of module (he says not knowing how modules work yet ).

[apeisa]

Pete: welcome to the forums!

• A maximum image size setting - everyone knows someone who doesn't know what "resolution" means and will likely upload a 3000 pixel wide photo. It would be nice to be able to set a maximum resolution so, on the off-chance someone does upload a large file, the default image stored on the server is resized to fit in with this setting
  

As far as I know the other things you suggested aren't there yet, but this last one is (at least on upcoming 2.1 version: https://github.com/ryancramerdesign/P21). Go to setup -> Fields -> choose image field and there "Max Image Dimensions".

[Pete]

Thanks apeisa - I'll check out 2.1 as well then.

Also thanks for the speedy reply - something tells me you're subscribed to be notified of new posts. Or you sensed a disturbance in the Force. One or the other

[apeisa]

Haha - I actually have no notifications, I just live here

[Pete]

Just another quick thought on images in pages - having one image per row in the editor keeps things nice and clear and allows for a larger description field, however if you're whipping up a page with screenshots on it for example and have 40 images it's a lot of scrolling down.

What are people's thoughts on having it as 3 images per row or something like that?

I know it's not as easy as all that and would require some code changes, especially in terms of dragging and dropping to re-order them, but it might be a more useful default. Just my opinion but I'd be happy to hear yours

As you might have noticed from my posts I spend a lot of time thinking - "what would the end-user think?". Makes you come up with some silly suggestions sometimes, but end users are a silly bunch sometimes as well

[ryan]

I've thought that we should eventually provide 2 views for the images. A thumbnail grid view (with just the photos), and the current view. The thumbnail grid view would horizontally stack as many per row as the interface width would allow, and you wouldn't see the description field. Since this isn't yet an option, I recommend putting a FieldsetTab field around your images field, and give it the label "Images". That way, in your page editor, our images will be on their own tab and you won't have to do all the scrolling when making other edits. Another option is to set your images field to be "always collapsed" when configuring it. Many of the sites that I work on have 50+ images on a given page, and have found that utilizing the tab makes it pretty manageable.

Edit: I also meant to add that you would be able to switch between the two views (in JS) just by clicking one of two icons at the top: # or = (if you can imagine those are icons and the first looks like a grid and the second looks like rows).

[Marty Walker]

Hi,

While we're on the subject of images I'd like to put in another feature request/wish.

I work with a lot of artists (http://www.illustratorsaustralia.com/). Once thing they really need in my opinion (and theirs) is a better way to create thumbnails. The basic centre crop just isn't enough for them to highlight the key part of an illustration. Sure, they could upload a seperate thumbnail file, but really, this is 2011. 

textpattern has the best image management I've seen in any CMS I've used. There's a plugin for it called EBL Image Edit (http://textpattern.syserror.net/article/4/ebl-image-edit) will allows you to select a portion of an image and create a thumbnail. There's an option to constrain the proportions too.

A while ago I came across a jQuery cropping tool called jCrop. Unfortunately the jCrop site is down (http://deepliquid.com/content/Jcrop.html) which would better illustrate what I mean. This example (http://nettuts.s3.amazonaws.com/1018_crop/demo/index.html) goes some way to showing how it works.

As much as I love textpattern I think ProcessWire is more artist-friendly. For a portfolio site having this type of thumbnailing option would be a great time saver.

Are there any plans have some centralised image area or let the image field be able to peruse image fields uploaded to other pages? I know this can be done in the wysiwyg editor which is something, but there's often reasons for images to appear in different locations on a site. I'm all for avoiding duplicate imagery.

Just my rambling two cents. 

Regards

Martin

[Pete]

I've used jCrop on a project myself - the project itself is here: http://code.google.com/p/jcrop/ and I think if you download the package it does have the examples to play with.

It is very handy and would be a nice thing to add to the image insertion process currently available in PW.

I guess that it would be best to have some per-template configuration options for this though (if that's actually possible) as for some sections of a website you might want to restrict the dimensions to 16:9 or 4:3 to make all thumbnails on a page appear uniform, whereas on others you might want other restrictions or no restrictions.

[almonk]

I think cropping functionality would make sense in PW and would undoubtedly be a useful feature for some. There's a few philosophical reasons that make it slightly harder in PW than other CMSs such as that thumbnails are usually defined in templates and not on the fields but I think this workflow would work:

• A new fieldtype 'Cropped Image(s)' is created which has the same feature base as the standard Image field but with the extra crop functionality
  
• The developer can define the size of the 'thumbnails' or whatever the images are being used for in the field's settings (just like the image fieldtype). Similarly the settings for the crop can be defined here, ie. ratio, dimensions etc
  
• When the user uploads an image they are prompted to 'edit this crop' or similar
  
• Clicking this link opens a modal window in which the crop can be adjusted

• When the page is saved the cropped version and original are saved as page attachments
  
• The cropped version is available in the api as $page->image->crop or similar
  

Just some thoughts...

[apeisa]

Are there any plans have some centralised image area or let the image field be able to peruse image fields uploaded to other pages? I know this can be done in the wysiwyg editor which is something, but there's often reasons for images to appear in different locations on a site. I'm all for avoiding duplicate imagery.

While there is no way to mirror images from another image field to other (and not sure if that would be good feature), there is nothing to stop you from creating centralized image area or using any image on any page of your website (without using wysiwyg editor).

You can easily do this on template level (pull images from another pages). Let's say you have page /images/ which is your centralized image area. Below that you have galleries, like /images/summer-2011/ and /images/record-covers/ etc... Template type "gallery" have few fields, like "title", "author" (page reference), "tags" (page reference) and "images" (image field).

Now in your templates you can pull those images in various ways:

5 galleries, with thumbnail links to real gallery pages:

<?php
$galleries = $pages->find("template=gallery, limit=5"); //Default sort, so newest is how it's sorted on backend
foreach($galleries as $gallery) {
  $thumb = $gallery->images->eq(0)->size(100,100); //This creates 100x100 thumbnail, crops to center - no better way for cropping yet
  echo "<a href='$gallery->url'><img src='$thumb->url' alt='$thumb->description' /></a>";
}

All galleries with tag "summer":

<?php
// First we need tag page "summer"
$summer = $pages->find("template=tag, name=summer");
$galleries = $pages->find("template=gallery, tags=$summer");
foreach($galleries as $gallery) {
  ...
}

All galleries from user "martin"

<?php
$martin = $pages->find("template=user, name=martin");
$galleries = $pages->find("template=gallery, user=$martin");
foreach($galleries as $gallery) {
  ...
}

I'm not sure if these examples are anything what you were looking for? But through API you have very popular tools for managing and displaying your images in different templates. What I would love also would be nice little cropping tool. Not so simple issue though, probably needs some "default thumbnail" for image fields. EDIT: As I was writing this post, Almonk wrote his about these cropped images.

[ryan]

Great suggestions from everyone.

I've also played around with jCrop in the past and thought we would eventually implement cropping in PW using this or another tool. But will implement it at the API level first (since we need it at that level before we can build a front-end). PW already supports center cropping (by resizing just one dimension) in addition to regular resizing, but doesn't yet support coordinate cropping. I suppose coordinate cropping at the API level isn't that useful since it requires making a visual judgement… but we'll have it anyway.

Forget about TinyMCE for the moment. The existing plan was that image fields (FieldtypeImage) would get an "edit" link for each image. That "edit" link would open ProcessPageImageEdit in a modal window. This is the same image edit screen that you see after selecting an image in TinyMCE. We would add the cropping functionality here (with jCrop or otherwise). You would be making edits to the original image. So any resizes and crops you made would be committed to the image once you hit "save". Though perhaps you'd also have the option to "save a copy" if your field supported more than 1 image.

Now back to TinyMCE. It would work the same way, only it's going to work off copies of the original image, given that it's only "borrowing" images from another field. That's how it already works (with resizes), but just restating it to say that it'll continue to work this way with crops.

Btw, great examples Antti!

Finally, just for fun… here's a screenshot from Dictator CMS (what came before ProcessWire). It had a little bit more advanced image manipulation functions that PW2 does, so far. And please disregard the name and branding for Dictator (made in 2003). That dude in the logo is apparently Kim Il-sung (North Korean Dictator, statue)... I was young and didn't know any better (it was supposed to be a concert conductor). Needless to say, after a friend informed me of this, Dictator was re-branded as ProcessWire. Though Dictator's code is long gone (none of it is in PW2).

[Adam Kiss]

Little OT: Ryan, while my design taste is little different than yours, I must say you have exceptional eye for colors & their combination, and looking at your past work, it seems that this ability evolved and was top notch even in 2003 (except all in all taste changed a little).

[slkwrm]

Here's a

showing interface for image crop in gallery addon in MODx Revo, although it uses ExtJS in its backend.

Hey Ryan, this Dictator branding rocks. Hitler CMS would be even cooler ;D

[Adam Kiss]

On topic: The problem I currently see with this (not to be negative, but that's my first things on mind) is that in PW, every on-page image scaling is done via templates, in code, therefore this scaling in administration just doesn't make sense. Sorry, but it doesn't

But there are few features, that might be in ideal CMS, or rather PW with more features (which = ideal CMS :

• maximal size – I don't know if this is currently possible, but some "if larger then resize" function would be nice, so users won't upload 3000px wide pictures – you'd load pictures with call like this: $image->maxSize(XX,YY)
  
• rescaling upon first load – together with previous function, large pictures could be deleted and replaced by the 'maxSize' version
  
• The original 'select one of 9' resize method – this way, you have fair control over what is cropped when you need smaller version
  
• simple recoloring functions
  

The problem with the recoloring function is when the question 'is it important enough?' comes, the answer is no

As for the select corner cropping, the only problem I see with this (currently), is how to do the UI flexible enough to translate this option to both fields with few images and fields with a lot of images. That is actually often a problem, when it comes to user generated ideas – subjective 'I would do it like this' is often not the best solution, while coming up with UI for majority is (almost) impossible.

Note: I almost wrote 'almonk impossible'

[apeisa]

On topic: The problem I currently see with this (not to be negative, but that's my first things on mind) is that in PW, every on-page image scaling is done via templates, in code, therefore this scaling in administration just doesn't make sense. Sorry, but it doesn't

I agree. But what I see beneficial would be to have cropping tool for thumbnails in admin. In templates you really don't know how to crop, since you cannot see the images. So center crop works there nicely for 90% of images (and it would be really really rare situation that you would use some other cropping there - unless it is some "wise" cropping which tries to analyze images). Portrait pictures of people are problematic for center cropping, lots of head dropping there

To have cropping tool for thumbnails would require that each image could contain another image also ($image->thumbnail). So there would be original (full size image that was uploaded) and then thumbnail image. In templates you could use your images like this:

<?php
echo "<a href='$image->url'><img src='$image->thumbnail->url' alt='$image->description' /></a>";

If there isn't any cropping done, then it $image->thumbnail would be just a regular center cropped image (size would be how it is defined on field settings).

Since thumbnails are also just regular images, you could resize those too in your templates. So you could set your thumbnail size to be "fullsize" and you could just crop those however you want on admin. That would allow you to easily fix poorly cropped images. See this snippet compared to above one:

<?php
$thumb = $image->thumbnail->size(100,100); // If resizing gives bad result, you can crop in admin and wow, it looks good!
echo "<a href='$image->url'><img src='$thumb->url' alt='$image->description' /></a>";

What do you guys think?

• maximal size – I don't know if this is currently possible, but some "if larger then resize" function would be nice, so users won't upload 3000px wide pictures – you'd load pictures with call like this: $image->maxSize(XX,YY)
  
• rescaling upon first load – together with previous function, large pictures could be deleted and replaced by the 'maxSize' version
  

I'm not sure if I follow you here, but isn't this same issue that Pete asked in first message and I answered in first reply? There is already Max dimensions image field setting (in 2.1 at least) which resizes images right after upload.

The problem with the recoloring function is when the question 'is it important enough?' comes, the answer is no

Our current cms has this, and from our 200+ clients I know only one who uses this and end results they have is horrible I think that could be cool in some projects, but should be separate module.

[Adam Kiss]

re: max size – I forgot the original topic. It's not my fault we jump from topic to topic in these posts!

re: 'thumbnail' field – I must say I'm stunned a little. I haven't expected such a horribly complicated solution from your often brilliant mind. Can't you imagine me doing this for 200, 300+ galleries? This is what I mentioned later in my most – The problem isn't in programming the solution (any solution), problem is how to introduce it to Admin UI and/or API AND keep current simplicity.

[apeisa]

Hmm...? please re-read my previous post. For UI wise that wouldn't require anything but "crop thumbnail" link or icon (which could open cropping view in modal or inline - whichever works best). For your 300+ galleries that wouldn't require anything at all. All would work just like before. There is no additional fields, just a new "feature" for current image field. And that feature is $image->thumbnail.

If you would like using cropped images in some of your templates, you would just replace your $image->size(xxx,yyy) to $image->thumbnail->size(xxx,yyy). In API - I don't think that it cannot be much cleaner. Not even a single new method.

If you did read my last reply with thought, could you describe more which makes that such a horribly complicated?

PS: It might be, that I did explain my idea in horribly complicated manner, but I really cannot think easier way to do this. At least for now, let's see about tomorrow

[ryan]

Lots of good ideas here and lots to consider. I'm trying to figure out if some of these things should be built-in, or if we should make the image capabilities as pluggable as possible, or if we should have a couple of different types of image fields (or more likely, a little of each).

It's true that the in-CMS image scaling may not make much sense if you are already scaling the images in the API. But we also can't assume that's the way everyone is using it. I tend to think that interactive scaling will be applicable in some instances. Perhaps it's something a checkbox can enable/disable in the image's field settings.

No doubt, cropping is definitely more useful to the way that most use PW. Antti's got a point in that there may be a need to have the smaller version visually cropped but not the larger version. For instance, this site:

http://directory.pewscholars.org/years/2011/

On that site', we've got these little square thumbnails of people that all have to be the same dimensions vertically and horizontally. But if you click to their bio, the photo is only constrained horizontally. When I initially uploaded the photos, some people's heads were getting chopped, so I had to do some manual cropping and Photoshop and re-upload for a few of them. But of course, that meant that I had to take something away from their full-size photo for the needs of the thumbnail. It wasn't a problem in this case, but certainly it would have been preferable to be able to manipulate my thumbnail separately and not have to crop my full-size photos.

Thinking of another instance, I was working on a site where we had the thumbnail, which led to a portfolio page of "medium" size photos, which in turn led to the full size photos. So if there is an $image->thumbnail, why not an $image->medium too? Once starting down this path of image variations, it's a little hard to predict what the exact need will be. So one option would be to take $image->thumbnail even a little further and provide for definable image variations in the image field's settings. Perhaps you call one of them "thumbnail" and another "toenail", but it's left up to the user what they want to define with a given image field. It would be a little tricky to implement, but it would be useful and only add the additional functionality for those that specifically wanted it.

Another option related to the $image->thumbnail idea is to instead have an $image->original. This is Antti's idea, but maintains an original rather than a thumbnail. By default $image->original would just point to itself. But if you cropped or resized your image at any time, then $image->original would be populated with the original unmodified version. There's no assumption about what it would be used for. Though PW would use it internally so you could interactively scale up or re-crop an image from the original (rather than going through a new JPG compression for every modification). Basically it would just "be there" in the background if you wanted it. The $image you see in your field would be the one you cropped (so the person's head doesn't get cut off). Most folks might not even know PW is keeping a copy of the original (minus a little 'view original' link)... so there's no perception of additional complexity.

From the API perspective, if I wanted to produce a list of 100x100 thumbnails and link to the original unmodified version you'd do it like this:

<?php
foreach($page->images as $image) {
    $thumb = $image->size(100, 100); 
    echo "<a href='{$image->original->url}'><img src='{$thumb->url}' /></a>";
}

If an image had never been cropped, then of course $image->original would be the same thing as $image... no need for performing additional checks in your API code.

Both $image->thumbnail or $image->original could have solved the examples I mentioned above. The main difference is that $image->original would be used by PW internally (so it can scale/crop from the source rather than copies), and there would only be one image to interact with from the admin side (like currently).

[apeisa]

Ryan: I like your $image->original idea much better. It's also much clearer on UI side: you edit the image, but you can always "undo" back to the original.

I also like your idea about adding multiple variations of single image ($image->thumbnail, $image->medium etc)... but after thinking that a while it is probably something that very few sites would need and would require lots of code and documentation. I think core solution here should be simpler (like the $image->original is).

[ryan]

Sounds good, I will plan to implement. Admittedly, this isn't a huge priority for the sites that I work on (though certainly a very useful feature), but perhaps it is more important for others. I'm leaving the country to travel in 2 weeks and want to come back and get 2.1 released asap and then start focusing on multi-language features. I'm thinking it would be good to focus on multi-language features first, as that is the priority. But perhaps the image fieldtype/inputfield improvements would be a good to accompany 2.2 as well.

[apeisa]

Sounds good. Overall pw image manipulation is in good shape. This is something that is sometimes a real timesaver, but never a showstopper. English only admin is a showstopper for many.

[Soma]

How about the possibility to create a config for defining various image sizes?

{

"news_small" => "50,0,70", ([w,h,compr])

"news-big" => "700,0,70",

"portfolio-small" => "50,50",

"portfolio-medium" => "100,100",

"portfolio-big" => "800,0,100"

}

So $image->original would be the uploaded raw picture, while you could use $image->thumb("portfolio-medium") ...

which would be produced on demand. Don't know if it would fit in your concept, but just wanted to throw in my thoughts.

[apeisa]

Soma: good idea, but that is pretty much supported already. You can do those resizes on the fly in your templates. What we are trying to achieve now is to have visual cropping tool without messing with UI and api too much.

[Pete]

But surely the problem with doing the on the fly is that they're done every page load and affects the user's experience when browsing the site if a thumbnail is to be created on the fly as well? Or am I not understanding this correctly (far more likely ).

I think the idea of a config setting where you can set options when creating the field could be the way to go.

[apeisa]

But surely the problem with doing the on the fly is that they're done every page load and affects the user's experience when browsing the site if a thumbnail is to be created on the fly as well? Or am I not understanding this correctly (far more likely ).

Image resizing is done only on first page load, so it affects very little for overall user experience. PW always first checks if there is already required image on right size and resizes only if image is missing. You can actually do very nice resizing already: http://villarental.com/villas/presidio-del-mar/ (new site developed by Ryan).

I have nothing against defining various image sizes. It is pretty much same than one of the ideas that Ryan mentioned in his long reply. Presetting different images, like thumbnail, medium etc...  That would require much more work in UI  (cropping for each variation? preview?) and also require more coding on field setting (although using JSON would be possible shortcut here). That would be very powerful solution, no doubt. Although I believe that over 90% of sites doesn't require more than one cropping variation of each image (sizes and center cropping are well supported already). If multiple sizes are possible with clear and well working solution, I am all for it.