Created attachment 95469 [details] Failed to load image with non-ascii file path On Windows 8.1 x64. Digikam version 4.12.0 built with RelWithDebInfo, with KDE 4.10.2. If path to a file contains non-ascii characters, then an image won't open, yielding "Failed to load image" notification. Steps to reproduce: 1. Create folder with non-ASCII characters inside existing digiKam album (e.g. "Новая папка"). Put an ASCII image file inside. 1.1 Alternatively, add an image file with non-ASCII filename (e.g. "Новое изображение") to regular ASCII folder. 2. Navigate to that folder 2.1 Observe that image previews are shown correctly 3. Open any image inside that folder. Actual result: Image not open. Digikam shows "Failed to load image" notification DebugView shows following: [4452] digikam(4452)/KEXIV2: Cannot load metadata from file (Error # 9 : E:/Google Drive/Leather/Done/???????? ???????/2.JPG: Failed to open the data source: Invalid argument (errno = 22) [4452] digikam(4452)/KEXIV2: Cannot load metadata from file (Error # 9 : E:/Google Drive/Leather/Done/???????? ???????/2.JPG: Failed to open the data source: Invalid argument (errno = 22) [4452] digikam(4452)/digikam (core) void __thiscall Digikam::PreviewLoadingTask::execute(void): Cannot extract preview for "E:/Google Drive/Leather/Done/???????? ???????/2.JPG" [4452] digikam(4452)/digikam (core) void __thiscall Digikam::PreviewLoadingTask::execute(void): Cannot extract preview for "E:/Google Drive/Leather/Done/???????? ???????/2.JPG" Expected result: Image is opened.
digiKam support UTF8 for all encoding char. I renamed under Linux a JPEG file as you propose and restarted digiKam. On the console : igikam.dimg: "/mnt/data/TEST_IMAGES/JPEG/Horizontal/Новоеизображение.jpg" : JPEG file identified digikam.database: Adding new item "/mnt/data/TEST_IMAGES/JPEG/Horizontal/Новоеизображение.jpg" digikam.database: Recognized "/mnt/data/TEST_IMAGES/JPEG/Horizontal/Новоеизображение.jpg" as identical to item 1410 So encoding is good here. Opening the file is not a problem : digikam.dimg: "/mnt/data/TEST_IMAGES/JPEG/Horizontal/Новоеизображение.jpg" : JPEG file identified digikam.metaengine: Loading image history "" digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal => QDateTime(2008-03-17 16:25:07.000 CET Qt::TimeSpec(LocalTime)) digikam.metaengine: Orientation => Exif.Image.Orientation => 1 digikam.general: Stacked View Mode : 1 See screenshot : https://www.flickr.com/photos/digikam/22767695013 Gilles Caulier
The error reported under windows come from the libexiv2 interface used by digiKam. Code relevant is given below : bool MetaEngine::load(const QString& filePath) const { ... Exiv2::Image::AutoPtr image; image = Exiv2::ImageFactory::open((const char*)(QFile::encodeName(filePath)).constData()); image->readMetadata(); ... } We pass file path to Exiv2 using QString (UTF8). Exiv2 use char* data which is converted by QFile::encodeName() function. Following this thread : http://subsurface.hohndel.narkive.com/sM5jj4ot/file-encodename-and-utf8-as-the-default-encoding-under-qt5 With Qt5 the encoding problem must be fixed under Windows Gilles Caulier
(In reply to caulier.gilles from comment #2) > The error reported under windows come from the libexiv2 interface used by > digiKam. Code relevant is given below : > > bool MetaEngine::load(const QString& filePath) const > { > ... > Exiv2::Image::AutoPtr image; > > image = Exiv2::ImageFactory::open((const > char*)(QFile::encodeName(filePath)).constData()); > > image->readMetadata(); > ... > } > > We pass file path to Exiv2 using QString (UTF8). Exiv2 use char* data which > is converted by QFile::encodeName() function. > > Following this thread : > > http://subsurface.hohndel.narkive.com/sM5jj4ot/file-encodename-and-utf8-as- > the-default-encoding-under-qt5 > > With Qt5 the encoding problem must be fixed under Windows > > Gilles Caulier Good to know it should be fixed in Qt5 release. Should we close this report as won't fix or resolved? Or should this rather be fixed even in Qt4 release series?
Maik, This file must be fixed normaly with 5.0.0 + Last Exiv2 shared lib. Can you confirm ? Gilles Caulier
This problem can no longer be reproduced for digiKam-5.0.0. I close this bug. Maik