improved picture management
upload in original size with full metadata. store select metadata in db for display + search. automatically move orginal sized image to special storage share. resize picture to two prediefined sizes (e.g. hd 1920x1080 + vga 640x480) in set quality (e.g. 70%), remove metadata, add selected metadata (e.g. copyright) and store resized pictures in db. use the appropriate one depending on picture and/or browser window size whenever the picture is used on the website. allow tagging and management of thousands of pictures.
anonymous
shared this idea
Probably v8
3 comments
-
ryan.wheale commented
The "getattachment" handler is very slow on first load... even running locally. I know you can implement caching... but on a site with lots of images, the App Pool gets refreshed very quickly... defeating the caching altogether. Also, images over 200K are not cached (as per sight settings). A larger value would only cause the App Pool to be refreshed too often.
I have implemented a solution on our server where I generate 7 images for all images loaded into a special "gallery" (custom table). The image is stored at a consistent path in the file system (e.g. ~/{SiteName}/gallery/{guid}/{filename}-{size}.jpg). The "size" portion of the URL is different for all 7 images... and is always tiny, small, med-small, med, med-large, large, huge. The longest dimension of each image is set to 100, 240, 480, 640, 960, 1280, 2048 respectively. This allows me to access the file directly from the file system without having to go through a handler which makes database calls, check permissions, and load the file into memory. This also allows me to deliver images to all devices... even the new Retina iPad. I have implemented a very long public caching policy on the directory (via IIS mgr) and I update the GUID every time the file gets updated to ensure the physical file name changes... which ensures that all updated images are delivered to end users. I also set a cookie on first page load which is calculated using the window width and the value of window.devicePixelRatio. This cookie can then be used in all transformations to determine which image to load. Solution works very well and is very fast.
-
I agree that this is something that is missing. The thing is that so far we didn't come with any decent design on how to manage these things so it is both flexible enough and user friendly for beginners. If you have any suggestions on how the management UI should handle that, let us know.
-
inarius
commented
I think that there are some good ideas here, but much of the functionality should be accomplished with an API rather than taking the static and predefined steps you are describing.
I already see pictures as a special type, and treat them as such on my site. They require more information than a regular file. For instance, they need a special field just for an Alt text description, (one which I would want to be required). In addition, they should have a field of a long description which should be optional.
Regarding all of the other features you mention, they all sound very useful. In fact I have already written some code to grab the EXIF metadata from my own files. However, these should be implemented within the Kentico API and not stored in specific database fields. In fact, the API approach is already more-or-less possible for the resizing options you mention, but I could see a use in some special considerations for HD and VGA resolutions. Take a look at the 'wdith' and 'maxsidesize' parameters for now.
