This one is tricky... we can already specify a manual thumbnail for any image, but this has a few problems: its dimensions are never dynamically altered (because it is possibly a remote image). But what would be nifty would be if you could take an original large image and then specify a custom thumbnail for different dimensions.
One possibility might be to use the thumbnail override field to store a (modified) copy of the original, e.g. if the original stub were 2014/05/01/img.jpg, then our custom thumbnail (e.g. a region selected via jCrop) might be 2014/05/01/img.thumb.jpg or thumbs/123/thumb.jpg. The problem is that we don't have metadata for the custom thumbnail (height and width predominantly). We could store this info with the custom thumb in the filename, e.g. thumbs/123/600x400.jpg so we could "know" the dimensions.
The related problem is with resizing images... if you use one of the output filters, which image should be resized? The original or the thumbnail? Sometimes you might want all thumbnails to use a specific region of the original image. Other times you might genuinely want a smaller dimension of the original.
Perhaps we could do check 2 places when pulling up a resized image:
thumbs/{asset_id}/{w}x{h}.{ext}
resized/{asset_id}/{w}x{h}.{ext}
That way if we find a custom thumbnail in the first directory, it will be used. The downside to this approach is that we have to hit the filesystem twice, but I think that's a minimal performance hit.
This one is tricky... we can already specify a manual thumbnail for any image, but this has a few problems: its dimensions are never dynamically altered (because it is possibly a remote image). But what would be nifty would be if you could take an original large image and then specify a custom thumbnail for different dimensions.
One possibility might be to use the thumbnail override field to store a (modified) copy of the original, e.g. if the original stub were 2014/05/01/img.jpg, then our custom thumbnail (e.g. a region selected via jCrop) might be 2014/05/01/img.thumb.jpg or thumbs/123/thumb.jpg. The problem is that we don't have metadata for the custom thumbnail (height and width predominantly). We could store this info with the custom thumb in the filename, e.g. thumbs/123/600x400.jpg so we could "know" the dimensions.
The related problem is with resizing images... if you use one of the output filters, which image should be resized? The original or the thumbnail? Sometimes you might want all thumbnails to use a specific region of the original image. Other times you might genuinely want a smaller dimension of the original.
Perhaps we could do check 2 places when pulling up a resized image:
That way if we find a custom thumbnail in the first directory, it will be used. The downside to this approach is that we have to hit the filesystem twice, but I think that's a minimal performance hit.