Version: 1.9.0 (using KDE 4.6.0) OS: Linux Enable auto detection of libjpeg turbo under fedora 14 or later. If the source of digikam/showfoto is complied under fedora 14 system that has libjpeg-turbo compiled from source it often fails to compile correctly. /libs/jpegutils/jpegutils.cpp: In function ‘bool Digikam::loadJPEGScaled(QImage&, const QString&, int)’: /libs/jpegutils/jpegutils.cpp:198:12: warning: enumeration value ‘JCS_EXT_RGB’ not handled in switch /libs/jpegutils/jpegutils.cpp:198:12: warning: enumeration value ‘JCS_EXT_RGBX’ not handled in switch /libs/jpegutils/jpegutils.cpp:198:12: warning: enumeration value ‘JCS_EXT_BGR’ not handled in switch /libs/jpegutils/jpegutils.cpp:198:12: warning: enumeration value ‘JCS_EXT_BGRX’ not handled in switch /libs/jpegutils/jpegutils.cpp:198:12: warning: enumeration value ‘JCS_EXT_XBGR’ not handled in switch /libs/jpegutils/jpegutils.cpp:198:12: warning: enumeration value ‘JCS_EXT_XRGB’ not handled in switch The code dose not seem to know about the new JCS_EXT used by libjpeg-turbo. Reproducible: Always Steps to Reproduce: If the source of digikam/showfoto is complied under fedora 14 system that has libjpeg-turbo compiled from source it often fails to compile correctly. Actual Results: The code dose not seem to know about or check for the new JCS_EXT used by libjpeg-turbo. Expected Results: Would help to make digikam/showfoto faster in handling Jpeg files. libjpeg-turbo is a much faster implementation of the jpeg library. Auto detection of libjpeg-turbo or inclusion would help speed up things.
A solution is given at this blog : http://microgroove.jp/shaolin/2011/06/digikam_vs_libjpeg-turbo.html Please test and report... i don't have jpegturbo installed on my computer Gilles Caulier
Hi, Thank you Gilles for sending me the link to patch the libjpeg-turbo bug in fedora, seems to work with the default libjpeg-turbo. No wearied jpeg errors at compile time (system has ver 1.1.0) will install a custom build ver 1.1.1 and check if it still works fine after some time. regards, Monts
Monts, Can you take a look if patch work fine with 2.0.0. CmakeLists.txt file is a little bit different with this version about jpeg handling. Thanks in advance Gilles Caulier
after a fresh git pull did see the CmakeLists.txt file is diffrent. As suggested in the workaround the following code # Extract version of libjpeg so that we can use the appropriate dir # See bug #227313, #228483 FILE(READ "${JPEG_INCLUDE_DIR}/jpeglib.h" jpeglib_h_content) FILE(READ "${JPEG_INCLUDE_DIR}/jconfig.h" jpeglib_h_content) STRING(REGEX REPLACE ".*#define +JPEG_LIB_VERSION +([0-9]+).*" "\\1" jpeglib_version "${jpeglib_h_content}") MESSAGE(STATUS "Identified libjpeg version: ${jpeglib_version}") cmake -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` .. failed did a minor change to the code ... FILE(READ "${JPEG_INCLUDE_DIR}/usr/include/jpeglib.h" jpeglib_h_content) FILE(READ "${JPEG_INCLUDE_DIR}/usr/include/jconfig.h" jpeglib_h_content) STRING(REGEX REPLACE ".*#define +JPEG_LIB_VERSION +([0-9]+).*" "\\1" jpeglib_version "${jpeglib_h_content}") MESSAGE(STATUS "Identified libjpeg version: ${jpeglib_version}") -know it is hard coded but works for now ... cmake -DCMAKE_BUILD_TYPE=release -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` .. no extra C/C++ flags passed this time, making a release build - kipi-plugins 2.0.0-rc dependencies results <http://www.kipi-plugins.org/> -- libjpeg library found.................... YES Linking CXX executable digikam [100%] Built target digikam showfoto build size 352,432 digikam build size 6,446,367 JPEGs loads in image editor (verified by using 5 different camera make and models) To do --- one more build to be be tested as by default, `make install' for jpeg-turbo will install all the files in `/opt/libjpeg-turbo/bin', `/opt/libjpeg-turbo/lib' etc. You can specify an installation prefix other than `/opt/libjpeg-turbo' using `--prefix', for instance `--prefix=$HOME'. build a custom libjpeg-turbo-1.1.1 with -prefix=/usr/local and test it out. More testing need to be done to verify if this works on all Fedora 14 and later.
You have harcoded path because ${JPEG_INCLUDE_DIR} string variable is null... In fact libjpeg is not found properly by cmake script before, in case of jpegturbo... Gilles Caulier
monts, Do you see my comment # ? Gilles Caulier
monts, I would to see a feedback about my comment #5 please... Gilles Caulier
libjpeg turno is available everywhere under Linux since a while, and nobody cry more about a detection problem... So for me, problemis fixed... Gilles Caulier