Version: 0.1.3~rc1 (using KDE KDE 3.5.5) Installed from: Ubuntu Packages OS: Linux When invoking Kipi slideshow from digikam, I notice that if the opengl transitions are enabled, the images look blurry and a bit pixelated, as though they are being displayed at a lower resolution than they and the screen have. When the same slideshow is viewed without transition, the slides are sharp. Please note, I have a large screen, size 2560 x 1600 (single DELL 3007WFP monitor) and so it may be that there is an obsolete resolution cap in place on the opengl operations. Other opengl slideshows can handle it.
Brad, This file still valid using kipi-plugins 0.1.6 ? Gilles Caulier
Not yet upgraded to intrepid so still on 0.1.5. One sure way to see it is to run ken burns mode on my very large panoramas. These are in sizes like 15,000 x 3500. They definitely are very blurry in 0.1.5. It does, at least, pan over the panorama horizontally, which is what I want.
*** Bug 182331 has been marked as a duplicate of this bug. ***
SVN commit 1002083 by aclemens: Use SmoothTransformation for image scaling, to avoid rough edges in images. Still the result is a little bit blurry, because we scale down the image to a size of <= 1024px, so that OpenGL translations are still fast. Bigger texture sizes slow things down (not on my system, but maybe on slower computers). So if you have a 2560 x 1600 screen resolution, the images look blurry, since they will be scaled up to fit the screen. Maybe there is a way to avoid the blur effect? At least the rough / pixelated edges should be gone now. CCBUG:140982 M +3 -2 slideshowgl.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1002083
I do understand that using smaller images may increase performance on small screens and slow computers. However, today many people have large screens (not necessarily 1600 high but 1920x1200 can be had for under $250 and is becoming common.) What might make sense is to notice the screen resolution, and adjust the scaling accordingly, or to have a checkbox to enable full use of the resolution, or even to measure the speed of the opengl operations and adjust resolution accordingly.
Yes, we could add a checkbox in the settings dialog. I will review this tomorrow.
SVN commit 1002173 by aclemens: Add a new option to avoid scaling of the image. Bigger textures should mean slower computation, but I can not recognize any slowdown on my machine. Right now the additional checkbox is added in the maindialog, but we can also move it to the advanced panel. What do you think? Brad, can you checkout the latest SVN version and tell us if it is better now? CCBUG:140982 M +1 -0 common.cpp M +1 -0 common.h M +6 -4 maindialog.cpp M +25 -1 maindialog.ui M +2 -0 slideshowconfig.cpp M +11 -12 slideshowgl.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1002173
Tried the new option, and it works on small images, however, it still fails on large panoramic images, which are one of my primary goals. (Because large panoramic images tend to have very large aspect ratios like 6 to 1 or even 20 to 1, they can't fit on any monitor. As such, displaying them and having it slowly pan through the image turns out to be a desirable goal.) When displaying large panoramics, the images seem to be seriously down-rezzed, to the point of seeing individual pixels on many of them. Shorter panoramics display OK. In addition -- perhaps this should be another bug -- really large panoramics, such as ones that are 50,000 pixels wide and 4,000 high, do not display properly at all. You get something which looks like a stretch of a single column or so of the image -- a series of coloured horizontal lines. Though it does seem to pan over them (not that you can easily tell) in ken burns mode. I realize such images are large, though my 1gb GT220 graphics card should be able to hold them in memory. However, it should not have to. With the screen being 1600 high, the approach that would make sense would be to scale the image down to 1600 high (or slightly taller if you plan some ken burns vertical pan, though I don't really want vertical pan on such images) so that it is 20,000 by 1,600, which would be 128 megabytes at 32 bits/pixel. Note that this is not even the biggest I have, I have built panoramas over 100,000 pixels wide. (And I am not even the biggest, see gigapan.org where people have thousands and thousands of images like this.) People seek a way to display these. I will also note that when doing a ken burns on these, such that the panning is fairly quick, there is jerkiness to the pan, and also some tearing. Is the card failing here or the code? To add to the list of panorama feature requests (again possibly I should open another ticket) would be a suggestion that when doing panoramas, the time per slide be variable and the pan rate be fixed. Ie. if you see an image with an aspect ratio of say, more than 3 to 1, modify the display time based on the aspect ratio.
Brad, This file still valid using kipi-plugins 2.4 ? Gilles Caulier
Samuel, This file still valid using kipi-plugins 4.10.0 ? Gilles Caulier
New Kipiplugins 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ? Gilles Caulier
Since the tool is moved to digiKam core with 5.0.0 release, this problem is not reproducible. Gilles Caulier