Version: (using KDE KDE 3.5.5) Installed from: Debian stable Packages OS: Linux While Bug #149485 has a totally awesome way of resizing images on the fly, what I want is far simpler, it would be nice to have a simple box that you move across the image, when you click, the corners are saved, and the image is scaled and resized on the fly to fit the display medium. The use case is this: I do some slideshows, but often on widely different display screens, sometimes on my 1600x1200 screen, sometimes on the 1280x800 laptop, sometimes on a 1280x1024 beamer and now I've just bought a 1920x1080 LCD for the living room. All these have a far smaller resolution than the pictures I shoot though, and in many cases just scaling the image is not what you want. I never use the digital zoom of my camera, because I keep telling myself that it is better to crop away the irrelevant stuff when I get home, but I end up never doing it, because cropping means loosing information too. So, it would have been much better to just store several bounding boxes, that are applied on the fly to the image depending on the display medium. Furthermore, it would be nice to store aspect ratios, in many cases, you would take most of the image, and use the same box for e.g. 1600x1200 and 1280x1024, etc. So, an idea of inheritance would be great, use the right aspect ratio unless a box for exactly the resolution exists. I think it would be nice to have this for thumbnail generation too, often downscaled thumbnails of images aren't recognizable. In the UI, one should be able to set which box you're using, since if the box is totally freenhand, it is much more difficult to get exactly right. Actually, I've seen this implemented using JavaScript on some website, but I can't remember where....
To specify a rectangular region, one possibly could use tags, which are associated with a region, http://bugs.kde.org/show_bug.cgi?id=146337 This could then be used by the slideshow etc. to only display that part of an image. Still, this sounds like a lot of work to specify those regions for each image and for *each* output format. So I am a bit sceptical about how many people would really go through this. (Of course one could try to start with some reasonable default settings, which would be maximal size, with respect to the center) Cocnerning the thumbnail generation, I do see substantial problems, as the thumbnails are directly associated with a full image and shared between different applications (like konquerer etc.) which follow the freedesktop standard for thumbnail management. To internally, on the fly, generate a crop might be doable, but would pretty complicate the code. On the other hand, if action lists for a sequences of operations on images (like white-balance, levels, curves ...) are implemented in the future, a solution for displaying thumbnails for images which do not exist physically would have to be found anyway.
Yeah, it would be a lot of work, but the additional overhead might not be so big. I'm on the brink of having people pay me to do slideshows, so there is a lot of work that has to be done for each image that I would want to show anyway. Typically, I would do this only for the picture actually used in the slideshow, but it is indeed important that the operation is quickly done for each picture. For a professional slideshow, the alternative is not really to not do it, but to crop and scale images and store the slideshow separately, which is not only a slower operation for the user, but it also consumes more disk space and creates an maintainence overhead, and makes it difficult to add more metadata. Since the aspect ratio is fixed when each box is made, the ideal interface would probably to first fix one corner, then fix another, but constrained by the aspect ratio. That probably won't take more than a few seconds per image. BTW, since we're talking about professional stuff here, is there a bounty system in place now? :-)
Arnd, All over this file are relevant of Kipi-plugins Slideshow i think. It's the advanced tool to slide image on screen. There is already a lot of options in this tool. What do you think about ? Note: The Slideshow tool from digiKam core is more simple... Valerio, can you give us your viewpoint... Gilles
Gilles, well, I don't use the slideshow myself, but apart from providing the infrastructure on the side of digikam (namely rectangles and their support in the GUI and database and a cropping tool), yes this would be mainly a feature for the slide-show. Kjetil, about specifying the rectangle I think that a cropping tool like the image editor has, is precisely what you suggest. However, I am not sure, where this cropping tool should be enabled (maybe only preview mode?) and what the optimal way to specify the aspect ratio would be (maybe another side-bar?). As far as I know, there is no bounty system, but donations are surely welcome ;-), see http://www.digikam.org/?q=donation (and/or contact Gilles directly in case of any questions).
Are you talking about Bounty System like this ? http://en.wikipedia.org/wiki/Bounty_(reward) digiKam has a donation way using paypal. it's simple and secure. Gilles
Hi there! I did a bit more looking around on my work box today (which has 0.9.2) and did find the Aspect Ratio Crop, which sets the box like I envision, but perhaps it is a bit cumbersome to have a dialog box for each use, yes... Yeah, I think the preview mode would be the right place to do it. And perhaps a sidebar where you would have something like * 16:9 * 1920x1080 * 1280x720 * 4:3 * 1600x1200 * 1152x864 * 1024x768 ...etc So, if you select a 4:3, that box will be used for any of the three resolutions below, if you select 1024x768, the box will only be used for that resolution. Then, I have to look a bit more carefully into the slideshow system! :-)
Kjetil, What's about his file using digiKam 4.10.0 ? Gilles Caulier
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ?
Thanks for following up! I have to admit I'm not tracking releases that closely anymore. I have a box sitting around I'd like to set up to track Debian unstable, but I haven't gotten to it yet... So, I'll check it out when I get there! :-) Thanks for the great work on Digikam, I like it a lot! Kjetil
The current behavior with 5.0.0 is enough and work perfectly. Gilles Caulier