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.pew...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).
).
