------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From NewsAssi Gmx net 2007-01-25 19:48 ------- Creating of thumbnails: 2-3 seconds per image (raw) Viewing image: 5-7 seconds per image (raw) CPU usage: all free time: 90-95% System: iMac Intel Core Duo 2.00 GHz I would be happy, if it could be faster _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From caulier.gilles kdemail net 2007-01-25 20:27 ------- > Viewing image: 5-7 seconds per image (raw) If you talking about preview (F3) not Editor (F4), here on my poor computer (PIII-650Mhz-300Mb) it take less than 1 second per RAW image... Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From NewsAssi Gmx net 2007-01-25 20:35 ------- Okay... that is realy intresting... I ment eding (left klick/F4)... Preview needs one second... It's faster then the thumbnail action *LOL* _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From kusi forum titlis org 2007-01-27 17:25 ------- I agree that the image viewing in digikam is too slow. Therefore I wrote an OpenGL based image viewer (KIPI plugin). Get it here: http://kde-apps.org/content/show.php?content=52276 Kusi _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 caulier.gilles kdemail net changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Albums GUI |Preview _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From marcel.wiesweg gmx de 2007-02-14 18:10 ------- SVN commit 633639 by mwiesweg: Use faster JPEG loading method (scale before decoding) for JPEG previews - move code from thumbnail ioslave to libs/jpegutils - use code in PreviewTask CCBUG: 132047 M +2 -149 kioslave/digikamthumbnail.cpp M +135 -0 libs/jpegutils/jpegutils.cpp M +2 -0 libs/jpegutils/jpegutils.h M +1 -0 libs/threadimageio/Makefile.am M +9 -2 libs/threadimageio/previewtask.cpp M +1 -0 showfoto/Makefile.am --- trunk/extragear/graphics/digikam/kioslave/digikamthumbnail.cpp #633638:633639 @ -68,6 +68,7 @ #include "rawfiles.h" #include "dcrawiface.h" #include "dmetadata.h" +#include "jpegutils.h" #include "digikamthumbnail.h" #include "digikam_export.h" @ -76,7 +77,6 @ extern "C" { #include <unistd.h> -#include <jpeglib.h> #include <sys/stat.h> #include <sys/types.h> #include <sys/ipc.h> @ -274,156 +274,9 @ return false; } -// -- JPEG Extraction --------------------------------------------------------------------- - -struct myjpeg_error_mgr : public jpeg_error_mgr -{ - jmp_buf setjmp_buffer; -}; - -extern "C" -{ - static void myjpeg_error_exit(j_common_ptr cinfo) - { - myjpeg_error_mgr* myerr = (myjpeg_error_mgr*) cinfo->err; - - char buffer[JMSG_LENGTH_MAX]; - (*cinfo->err->format_message)(cinfo, buffer); - kdWarning() << buffer << endl; - longjmp(myerr->setjmp_buffer, 1); - } -} - bool kio_digikamthumbnailProtocol::loadJPEG(QImage& image, const QString& path) { - QString format = QImageIO::imageFormat(path); - if (format !="JPEG") return false; - - FILE* inputFile=fopen(QFile::encodeName(path), "rb"); - if(!inputFile) - return false; - - struct jpeg_decompress_struct cinfo; - struct myjpeg_error_mgr jerr; - - // JPEG error handling - thanks to Marcus Meissner - cinfo.err = jpeg_std_error(&jerr); - cinfo.err->error_exit = myjpeg_error_exit; - - if (setjmp(jerr.setjmp_buffer)) - { - jpeg_destroy_decompress(&cinfo); - fclose(inputFile); - return false; - } - - jpeg_create_decompress(&cinfo); - jpeg_stdio_src(&cinfo, inputFile); - jpeg_read_header(&cinfo, true); - - int imgSize = QMAX(cinfo.image_width, cinfo.image_height); - - int scale=1; - while(cachedSize_*scale*2<=imgSize) - { - scale*=2; - } - if(scale>8) scale=8; - - cinfo.scale_num=1; - cinfo.scale_denom=scale; - - switch (cinfo.jpeg_color_space) - { - case JCS_UNKNOWN: - break; - case JCS_GRAYSCALE: - case JCS_RGB: - case JCS_YCbCr: - cinfo.out_color_space = JCS_RGB; - break; - case JCS_CMYK: - case JCS_YCCK: - cinfo.out_color_space = JCS_CMYK; - break; - } - - jpeg_start_decompress(&cinfo); - - QImage img; - - // We only take RGB with 1 or 3 components, or CMYK with 4 components - if (!( - (cinfo.out_color_space == JCS_RGB && (cinfo.output_components == 3 || cinfo.output_components == 1)) - || (cinfo.out_color_space == JCS_CMYK && cinfo.output_components == 4) - )) - { - jpeg_destroy_decompress(&cinfo); - fclose(inputFile); - return false; - } - - switch(cinfo.output_components) - { - case 3: - case 4: - img.create( cinfo.output_width, cinfo.output_height, 32 ); - break; - case 1: // B&W image - img.create( cinfo.output_width, cinfo.output_height, 8, 256 ); - for (int i = 0 ; i < 256 ; i++) - img.setColor(i, qRgb(i, i, i)); - break; - } - - uchar** lines = img.jumpTable(); - while (cinfo.output_scanline < cinfo.output_height) - jpeg_read_scanlines(&cinfo, lines + cinfo.output_scanline, cinfo.output_height); - - jpeg_finish_decompress(&cinfo); - - // Expand 24->32 bpp - if ( cinfo.output_components == 3 ) - { - for (uint j=0; j<cinfo.output_height; j++) - { - uchar *in = img.scanLine(j) + cinfo.output_width*3; - QRgb *out = (QRgb*)( img.scanLine(j) ); - - for (uint i=cinfo.output_width; i--; ) - { - in -= 3; - out[i] = qRgb(in[0], in[1], in[2]); - } - } - } - else if ( cinfo.output_components == 4 ) - { - // CMYK conversion - for (uint j=0; j<cinfo.output_height; j++) - { - uchar *in = img.scanLine(j) + cinfo.output_width*4; - QRgb *out = (QRgb*)( img.scanLine(j) ); - - for (uint i=cinfo.output_width; i--; ) - { - in -= 4; - int k = in[3]; - out[i] = qRgb(k * in[0] / 255, k * in[1] / 255, k * in[2] / 255); - } - } - } - - int newMax = QMAX(cinfo.output_width, cinfo.output_height); - int newx = cachedSize_*cinfo.output_width / newMax; - int newy = cachedSize_*cinfo.output_height / newMax; - - jpeg_destroy_decompress(&cinfo); - fclose(inputFile); - - image = img.smoothScale(newx,newy); - - return true; + return Digikam::loadJPEGScaled(image, path, cachedSize_); } void kio_digikamthumbnailProtocol::exifRotate(const QString& filePath, QImage& thumb) --- trunk/extragear/graphics/digikam/libs/jpegutils/jpegutils.cpp #633638:633639 @ -108,6 +108,141 @ #endif } +bool loadJPEGScaled(QImage& image, const QString& path, int maximumSize) +{ + QString format = QImageIO::imageFormat(path); + if (format !="JPEG") return false; + + FILE* inputFile=fopen(QFile::encodeName(path), "rb"); + if(!inputFile) + return false; + + struct jpeg_decompress_struct cinfo; + struct jpegutils_jpeg_error_mgr jerr; + + // JPEG error handling - thanks to Marcus Meissner + cinfo.err = jpeg_std_error(&jerr); + cinfo.err->error_exit = jpegutils_jpeg_error_exit; + cinfo.err->emit_message = jpegutils_jpeg_emit_message; + cinfo.err->output_message = jpegutils_jpeg_output_message; + + if (setjmp(jerr.setjmp_buffer)) + { + jpeg_destroy_decompress(&cinfo); + fclose(inputFile); + return false; + } + + jpeg_create_decompress(&cinfo); + jpeg_stdio_src(&cinfo, inputFile); + jpeg_read_header(&cinfo, true); + + int imgSize = QMAX(cinfo.image_width, cinfo.image_height); + + // libjpeg supports 1/1, 1/2, 1/4, 1/8 + int scale=1; + while(maximumSize*scale*2<=imgSize) + { + scale*=2; + } + if(scale>8) scale=8; + + cinfo.scale_num=1; + cinfo.scale_denom=scale; + + switch (cinfo.jpeg_color_space) + { + case JCS_UNKNOWN: + break; + case JCS_GRAYSCALE: + case JCS_RGB: + case JCS_YCbCr: + cinfo.out_color_space = JCS_RGB; + break; + case JCS_CMYK: + case JCS_YCCK: + cinfo.out_color_space = JCS_CMYK; + break; + } + + jpeg_start_decompress(&cinfo); + + QImage img; + + // We only take RGB with 1 or 3 components, or CMYK with 4 components + if (!( + (cinfo.out_color_space == JCS_RGB && (cinfo.output_components == 3 || cinfo.output_components == 1)) + || (cinfo.out_color_space == JCS_CMYK && cinfo.output_components == 4) + )) + { + jpeg_destroy_decompress(&cinfo); + fclose(inputFile); + return false; + } + + switch(cinfo.output_components) + { + case 3: + case 4: + img.create( cinfo.output_width, cinfo.output_height, 32 ); + break; + case 1: // B&W image + img.create( cinfo.output_width, cinfo.output_height, 8, 256 ); + for (int i = 0 ; i < 256 ; i++) + img.setColor(i, qRgb(i, i, i)); + break; + } + + uchar** lines = img.jumpTable(); + while (cinfo.output_scanline < cinfo.output_height) + jpeg_read_scanlines(&cinfo, lines + cinfo.output_scanline, cinfo.output_height); + + jpeg_finish_decompress(&cinfo); + + // Expand 24->32 bpp + if ( cinfo.output_components == 3 ) + { + for (uint j=0; j<cinfo.output_height; j++) + { + uchar *in = img.scanLine(j) + cinfo.output_width*3; + QRgb *out = (QRgb*)( img.scanLine(j) ); + + for (uint i=cinfo.output_width; i--; ) + { + in -= 3; + out[i] = qRgb(in[0], in[1], in[2]); + } + } + } + else if ( cinfo.output_components == 4 ) + { + // CMYK conversion + for (uint j=0; j<cinfo.output_height; j++) + { + uchar *in = img.scanLine(j) + cinfo.output_width*4; + QRgb *out = (QRgb*)( img.scanLine(j) ); + + for (uint i=cinfo.output_width; i--; ) + { + in -= 4; + int k = in[3]; + out[i] = qRgb(k * in[0] / 255, k * in[1] / 255, k * in[2] / 255); + } + } + } + + int newMax = QMAX(cinfo.output_width, cinfo.output_height); + int newx = maximumSize*cinfo.output_width / newMax; + int newy = maximumSize*cinfo.output_height / newMax; + + jpeg_destroy_decompress(&cinfo); + fclose(inputFile); + + image = img.smoothScale(newx,newy); + + return true; +} + bool exifRotate(const QString& file, const QString& documentName) { QFileInfo fi(file); --- trunk/extragear/graphics/digikam/libs/jpegutils/jpegutils.h #633638:633639 @ -26,10 +26,12 @ // Qt includes. #include <qstring.h> +#include <qimage.h> namespace Digikam { +bool loadJPEGScaled(QImage& image, const QString& path, int maximumSize); bool exifRotate(const QString& file, const QString& documentName); bool jpegConvert(const QString& src, const QString& dest, const QString& documentName, const QString& format=QString("PNG")); --- trunk/extragear/graphics/digikam/libs/threadimageio/Makefile.am #633638:633639 @ -18,5 +18,6 @ -I$(top_srcdir)/digikam/libs/dimg/loaders \ -I$(top_srcdir)/digikam/libs/dmetadata \ -I$(top_srcdir)/digikam/libs/dcraw \ + -I$(top_srcdir)/digikam/libs/jpegutils \ -I$(top_srcdir)/digikam/digikam \ $(all_includes) --- trunk/extragear/graphics/digikam/libs/threadimageio/previewtask.cpp #633638:633639 @ -31,6 +31,7 @ #include "ddebug.h" #include "dmetadata.h" #include "dcrawiface.h" +#include "jpegutils.h" #include "previewloadthread.h" #include "previewtask.h" @ -137,8 +138,14 @ { // Try to extract Exif/Iptc preview. if ( !loadImagePreview(qimage, m_loadingDescription.filePath) ) - // Try to load with Qt/KDE. - qimage.load(m_loadingDescription.filePath); + { + // Try to load a JPEG with the fast scale-before-decoding method + if (!loadJPEGScaled(qimage, m_loadingDescription.filePath, size)) + { + // Try to load with Qt/KDE. + qimage.load(m_loadingDescription.filePath); + } + } } if (qimage.isNull()) --- trunk/extragear/graphics/digikam/showfoto/Makefile.am #633638:633639 @ -33,6 +33,7 @ $(top_builddir)/digikam/utilities/splashscreen/libsplashscreen.la \ $(top_builddir)/digikam/utilities/slideshow/libslideshow.la \ $(top_builddir)/digikam/libs/threadimageio/libthreadimageio.la \ + $(top_builddir)/digikam/libs/jpegutils/libjpegutils.la \ $(LIB_QT) $(LIB_KDECORE) $(LIB_KDEUI) $(LIB_KUTILS) \ $(LIB_KFILE) $(LIB_KPARTS) $(LIBJPEG) $(EXIV2_LIBS) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 caulier.gilles gmail com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From caulier.gilles gmail com 2007-04-06 18:54 ------- This file is implemented in 0.9.1 release. I close it. Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From cimmo libero it 2007-04-09 10:54 ------- Photos aren't prefetched in 0.9.1 so why closed as fixed? Photos are still loaded when page down is pressed and not before. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 arnd.baecker web de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From arnd.baecker web de 2007-07-03 18:49 ------- I went through all comments for this bug, and agree with #21 that prefetching is not yet done. I therefore re-open this bug. Summary of open points: - "The ultimate optimization to do is to preload in background to the cache the next and previous image around the current selected image from current album. " (Gilles, in #11) - "Other optimizations to speed-up the drawing of pictures on the screen can be done using Qt4." (Gilles, in #11) - "For preloading there is a requirement that we dont meet currently: The ability to stop the loading. We can do this with the DImg loaders, but the preview is based on QImage." (Marcel, in #13) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From marcel.wiesweg gmx de 2007-07-04 13:34 ------- Since January a lot has changed: 1) There is preloading in image preview. If you dont believe, start digikam from a console and watch the output in a directory with raw images ;-) 2) This is obviously what we are dealing with in the immediate future (weeks) 3) The preview is now based on DImg, but internally, loading of embbeded previews in raws and in IPTC and half-size preview of raws is non-interruptable (the latter may change I think, why not use the DImg loader). We have solved this problem by using two loading threads. Then the only problem is the use of resources by the non-interruptable operation, when the prediction of the preloading was not met (i.e., the currently preloaded image is not the needed one) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Ad 1) Well, I didn't believe, and before posting I did
the test with a directory of raw files, however without a look at the console. And it does feel much slower to go from the current to the next image than going back to the previous (or other cached images). I.e., once they are in cache it works brilliantly! Looking at the console ouput: it does indeed say that the next image is preloaded. However, when going to the next image, it again says "Running RAW decoding command kdcraw ...." on that image (?!) *and* the subsequent image (which is fine). Sometimes I even observe a kcdraw call for the previous images? (Just simply going through a bunch of images from the first to the last, in F3 preview mode, "Embedded preview load full image size" in the "Album Settings") Maybe I am interpreting the output incorrectly? BTW, how large is the cache used for all this (is its size configurable)? In general, I know that you have been working very hard on this, and the improvements are brilliant and very much appreciated (All this, including 2) and 3) look technically rather involved!). Thanks a lot, Arnd _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From arnd.baecker web de 2007-07-04 14:09 ------- Ad 1) Well, I didn't believe, and before posting I did the test with a directory of raw files, however without a look at the console. And it does feel much slower to go from the current to the next image than going back to the previous (or other cached images). I.e., once they are in cache it works brilliantly! Looking at the console ouput: it does indeed say that the next image is preloaded. However, when going to the next image, it again says "Running RAW decoding command kdcraw ...." on that image (?!) *and* the subsequent image (which is fine). Sometimes I even observe a kcdraw call for the previous images? (Just simply going through a bunch of images from the first to the last, in F3 preview mode, "Embedded preview load full image size" in the "Album Settings") Maybe I am interpreting the output incorrectly? BTW, how large is the cache used for all this (is its size configurable)? In general, I know that you have been working very hard on this, and the improvements are brilliant and very much appreciated (All this, including 2) and 3) look technically rather involved!). Thanks a lot, Arnd _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From caulier.gilles gmail com 2007-07-04 14:14 ------- Arnd, To extract an embedded preview from RAW file the command is "kdcraw -e ..." Look dcraw man page for details. Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From arnd.baecker web de 2007-07-04 14:34 ------- Right - thanks Gilles! So to me it seems that it does not preload when "Embedded preview load full image size" is set in the "Album Settings". Details: - Folder with 4 raw images: IMG_1939.CR2, ..., IMG_1942.CR2, - album view - then press F3 (to preview IMG_1939.CR2): digikam: IMG_1939.CR2 : RAW file identified Running RAW decoding command: kdcraw -c -v -h -w -a -H 0 -b 1 -q 0 -o1 IMG_1939.CR2 Running RAW decoding command: kdcraw -c -e 'IMG_1940.CR2' Using embedded RAW preview extraction # Is there any preload done here? # I.e. should there be a kcdraw -c -v .... IMG_1940.CR2? - Page Down: digikam: IMG_1940.CR2 : RAW file identified Running RAW decoding command: kdcraw -c -v -h -w -a -H 0 -b 1 -q 0 -o 1 IMG_1940.CR2 Running RAW decoding command: kdcraw -c -e 'IMG_1941.CR2' Using embedded RAW preview extraction Running RAW decoding command: kdcraw -c -e 'IMG_1939.CR2' Using embedded RAW preview extraction If "embedded preview load full image size" is not active, I only see the kdcraw -c -e '...' commands (and just 4 of them), and that's it. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From marcus.hardt iwr fzk de 2008-02-19 09:20 ------- Same for jpg. Images load really fast -- unless "Embedded preview load full image size" is set in the "Album Settings" which is unfortunate since I cannot zoom in. While I don't know, where this behaviour comes from, maybe a reasonable workaround is to reload the full image size on zoom? _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From caulier.gilles gmail com 2008-03-19 08:06 ------- Arnd, Why this file have been re-open ? It's still a problem somewhere ? Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From arnd.baecker web de 2008-03-19 08:40 ------- Gilles, the open issue is detailed in c#26. Unless something has changed, this problem is still there ... _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 caulier.gilles gmail com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marcel.wiesweg gmx de ------- Additional Comments From caulier.gilles gmail com 2008-03-19 08:58 ------- Marcel, What do you think about comments in #26 from Arnd ? Something is wrong in preloading interface ? Gilles caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From marcel.wiesweg gmx de 2008-03-19 23:00 ------- SVN commit 787804 by mwiesweg: Load high quality version also when preloading the preview. Seems to fix the bug. CCBUG: 132047 M +6 -2 imagepreviewview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=787804 _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by Bugzilla from kdebug@mail.4brad.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=132047 ------- Additional Comments From caulier.gilles gmail com 2008-03-19 23:03 ------- Arnd, Can you confirm ? Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Free forum by Nabble | Edit this page |