Version: SVN - built 20080522-UTC (using KDE 3.5.9) Installed from: Debian testing/unstable Packages OS: Linux After editing a JPG file with Digikam's "Image Editor", if saving the file in JPEG format, JPEG options (JPEG quality, Chroma subsampling) are not available. Instead, the file save dialog reports "No options available". The options can be restored with the following workaround (required every time): 1. change "Filter Type" from "JPEG Files" to "All Available Files" 2. change file extension from "JPEG" to "jpg". Options are then presented correctly. (Above two steps must be performed in that order - doesn't work in reverse.) To reproduce: 1. open image in Image Editor; save image as JPG; close editor 2. open JPG image. "Save As" -> JPG options unavailable.
I can confirm this, but on my system (latest build) the options are always not available. The only solution for me is to set another filter (by the way, shouldn't this be called filetype? Filter seems to be wrong in my opinion), for example PNG and then reset the filter to JPEG again. Now all options are available.
Just to confirm - this bug is present in 0.9.4-beta 5 (release candidate.)
SVN commit 812843 by cgilles: digiKam from KDE3 branch: set properlly the file mime type in save as dialog from editor. BUGS: 162496 M +0 -2 editorwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=812843
SVN commit 812849 by cgilles: backport commit #812843 from KDE3 branch CCBUGS: 162496 M +0 -2 editorwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=812849
This bug has re-appeared. The "Save as" dialog will only show options for JPEG when you switch to another filter and back. Andi
This is true for KDE4 port, not KDE3 code... Look also that JPEG2000 file format is not present in the list of type mime support (but it's registered... so why it's doesn't work?) Gilles
It's getting worse. In some folders ALL images make digiKam crash when "Save as" is clicked and the filter type has been changed: Thread 17 (Thread 0xa9270b90 (LWP 9000)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21bb5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7da39f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #3 0xb6aa3119 in Digikam::LoadSaveThread::run (this=0xcfa5228) at /home/andi/Programmieren/workspace/digikam_KDE4/digikam/libs/threadimageio/loadsavethread.cpp:127 #4 0xb7da2c21 in ?? () from /usr/lib/libQtCore.so.4 #5 0x0cfa5228 in ?? () #6 0x00000000 in ?? () Thread 16 (Thread 0xab9deb90 (LWP 8959)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21bb5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7da39f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #3 0xb6aa3119 in Digikam::LoadSaveThread::run (this=0xcc86d08) at /home/andi/Programmieren/workspace/digikam_KDE4/digikam/libs/threadimageio/loadsavethread.cpp:127 #4 0xb7da2c21 in ?? () from /usr/lib/libQtCore.so.4 #5 0x0cc86d08 in ?? () #6 0x00000000 in ?? () Thread 15 (Thread 0xac1dfb90 (LWP 8958)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21bb5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7da39f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #3 0xb6aa3119 in Digikam::LoadSaveThread::run (this=0xccf7a70) at /home/andi/Programmieren/workspace/digikam_KDE4/digikam/libs/threadimageio/loadsavethread.cpp:127 #4 0xb7da2c21 in ?? () from /usr/lib/libQtCore.so.4 #5 0x0ccf7a70 in ?? () #6 0x00000000 in ?? () Thread 14 (Thread 0xac9f0b90 (LWP 8956)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21bb5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7da39f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #3 0xb6aa3119 in Digikam::LoadSaveThread::run (this=0xb28dc48) at /home/andi/Programmieren/workspace/digikam_KDE4/digikam/libs/threadimageio/loadsavethread.cpp:127 #4 0xb7da2c21 in ?? () from /usr/lib/libQtCore.so.4 #5 0x0b28dc48 in ?? () #6 0x00000000 in ?? () Thread 13 (Thread 0xad226b90 (LWP 8954)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb5461af7 in poll () from /lib/libc.so.6 #2 0xb53177e2 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #3 0xb5317b11 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #4 0xb7ea5cd9 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #5 0xb7e7d65b in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #6 0xb7e7d83a in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #7 0xb7d9fd14 in QThread::exec () from /usr/lib/libQtCore.so.4 #8 0xb028f8e2 in Phonon::Xine::XineThread::run () from /usr/lib/kde4/phonon_xine.so #9 0xb7da2c21 in ?? () from /usr/lib/libQtCore.so.4 #10 0x0946b018 in ?? () #11 0x00000000 in ?? () Thread 12 (Thread 0xada27b90 (LWP 8953)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb5464751 in select () from /lib/libc.so.6 #2 0xb026ee32 in xine_usec_sleep () from /usr/lib/libxine.so.1 #3 0x00000000 in ?? () Thread 11 (Thread 0xae633b90 (LWP 8952)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21bb5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb0256664 in ao_loop () from /usr/lib/libxine.so.1 #3 0x00000000 in ?? () Thread 10 (Thread 0xaee34b90 (LWP 8951)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb5461af7 in poll () from /lib/libc.so.6 #2 0xaee7bee0 in ao_alsa_handle_event_thread () from /usr/lib/xine/plugins/1.24/xineplug_ao_out_alsa.so #3 0x00000000 in ?? () Thread 7 (Thread 0xaf681b90 (LWP 8947)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21ee2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb02447d1 in metronom_sync_loop () from /usr/lib/libxine.so.1 Thread 6 (Thread 0xb2896b90 (LWP 8946)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21bb5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7da39f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #3 0xb6aa3119 in Digikam::LoadSaveThread::run (this=0x91d79d0) at /home/andi/Programmieren/workspace/digikam_KDE4/digikam/libs/threadimageio/loadsavethread.cpp:127 #4 0xb7da2c21 in ?? () from /usr/lib/libQtCore.so.4 #5 0x091d79d0 in ?? () #6 0x00000000 in ?? () Thread 5 (Thread 0xb2095b90 (LWP 8945)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21bb5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7da39f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #3 0xb6aa3119 in Digikam::LoadSaveThread::run (this=0x920ca40) at /home/andi/Programmieren/workspace/digikam_KDE4/digikam/libs/threadimageio/loadsavethread.cpp:127 #4 0xb7da2c21 in ?? () from /usr/lib/libQtCore.so.4 #5 0x0920ca40 in ?? () #6 0x00000000 in ?? () Thread 2 (Thread 0xb3411b90 (LWP 8941)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb7d21bb5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7da39f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4 #3 0x082acd2b in Digikam::ScanController::run (this=0x90eb1e0) at /home/andi/Programmieren/workspace/digikam_KDE4/digikam/digikam/scancontroller.cpp:344 #4 0xb7da2c21 in ?? () from /usr/lib/libQtCore.so.4 #5 0x090eb1e0 in ?? () #6 0x00000000 in ?? () Thread 1 (Thread 0xb4bab700 (LWP 8935)): #0 0xb7f1f424 in __kernel_vsyscall () #1 0xb53c8720 in raise () from /lib/libc.so.6 #2 0xb53ca058 in abort () from /lib/libc.so.6 #3 0xb7d9b965 in qt_message_output () from /usr/lib/libQtCore.so.4 #4 0xb7d9ba17 in qFatal () from /usr/lib/libQtCore.so.4 #5 0xb7d9baa6 in qt_assert () from /usr/lib/libQtCore.so.4 #6 0xb76073f3 in KDirModelPrivate::_k_slotDeleteItems () from /usr/lib/libkio.so.5 #7 0xb760b5f5 in KDirModel::qt_metacall () from /usr/lib/libkio.so.5 #8 0xb7e90b03 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #9 0xb7e91063 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #10 0xb75ee1d4 in KDirLister::itemsDeleted () from /usr/lib/libkio.so.5 #11 0xb75f6fd1 in KDirLister::emitChanges () from /usr/lib/libkio.so.5 #12 0xb51b4507 in KDirOperator::updateDir () from /usr/lib/libkfile.so.4 #13 0xb51dc5af in KFileWidgetPrivate::_k_slotFilterChanged () from /usr/lib/libkfile.so.4 #14 0xb51dd0cb in KFileWidget::qt_metacall () from /usr/lib/libkfile.so.4 #15 0xb7e90b03 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #16 0xb7e91063 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #17 0xb51c9a88 in KFileFilterCombo::filterChanged () from /usr/lib/libkfile.so.4 #18 0xb51c9d8b in KFileFilterCombo::qt_metacall () from /usr/lib/libkfile.so.4 #19 0xb7e90b03 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #20 0xb7e91063 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #21 0xb63782e4 in QComboBox::activated () from /usr/lib/libQtGui.so.4 #22 0xb6379e8f in ?? () from /usr/lib/libQtGui.so.4 #23 0x0ea90670 in ?? () #24 0x00000000 in ?? () What can be seen in those folders (all jpeg files) is that the initial filename "on save as" is set to png, for example: test-image01.png, the filtertype is set to JPEG (without shown options). No switching to PNG or TIFF (or whatever fileextension you like) will crash digiKam with the above backtrace. In other folders (also jpg files) the crash is not reproducible. Andi
No switching = Now switching
SVN commit 873967 by aclemens: quick fix: call the filterChanged slot manually since KFileDialog doesn't seem to emit a signal when using setMimeFilter() CCBUG:162496 M +1 -0 editorwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=873967
Another question on this topic: When my original image in the imageditor is a jpg and I click on "save as", it sets the extension to jpeg. But I guess the most common used extension is the one without the e => jpg. In KDE3 it is also set to jpg. Is there a reason why we use this extension in KDE4 now? Andi
No. it must be .jpg. Note that .jpeg is also a valid extension and it recognized by digiKam without problem. Gilles
I don't understand the crashing I have with some folders. There is no visible pattern that differs the one folder from the others that are working. If I want to save an image in a folder called "digiKam tests" and I scroll through the filter list in the "save as" dialog, it crashes. If I start "save as" dialog and go out of the folder, than back (inside of the save-dialog), it is not crashing anymore. Judging from the BT I would say this is Qt's fault (or KDE), not digiKam, but what is wrong there? First I thought it has something to do with withspaces, since images in folders that are not crashing digiKam had no whitespaces in filename or folder name. After renaming the folder that crashes all the time as well as renaming all the files in there it still crashes. I get this on the console: ASSERT: "node" in file /home/jan/Dev/packages/kdemod-core/work/kdelibs/src/kdelibs-4.1.2/kio/kio/kdirmodel.cpp, line 405 KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = digikam path = <unknown> pid = 31894 Very strange. The other problems are not fixed, either. In KDE4 we use a StandardMimeType now for the filter, that is set from the current image from the canvas. But somehow this doesn't make sense because afterwards we read the last used mimetype from settings and chnage the filename to this value. So if I edit a JPG, but the last used mimetype was PNG, I get a filter set to JPEG but a filename with the PNG extension. This is wrong. I will have a look at this later, right now I'm too busy. Andi
SVN commit 873977 by aclemens: fixes crashing when "all image filetypes" is selected as a filter M +8 -3 filesaveoptionsbox.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=873977
SVN commit 874049 by aclemens: Generate default mimetype from last saved image type, not current canvas image. The options should be set correctly now. CCBUG:162496 M +7 -7 libs/widgets/common/filesaveoptionsbox.cpp M +32 -38 utilities/imageeditor/editor/editorwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=874049
We still have the problem with the extension "*.jpeg". Where is it defined? Somewhere in kdelibs due to the use of typeFromMime()? Andi
SVN commit 874409 by aclemens: It seems that we need to call the slot manually, otherwise the options for the mimetype are not set correctly sometimes. CCBUG:162496 M +1 -0 editorwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=874409
>We still have the problem with the extension "*.jpeg". Where is it defined? >Somewhere in kdelibs due to the use of typeFromMime()? yes, in KDELibs i think... Gilles
(In reply to comment #17) > >We still have the problem with the extension "*.jpeg". Where is it defined? > >Somewhere in kdelibs due to the use of typeFromMime()? > > yes, in KDELibs i think... > > Gilles So I guess we can't do anything about it right now. I will close this bug again since the main problem is solved now. Andi