|
Hi all,
Since few day, i working hard to create a new tool to make pseudo HDR image. After some try with QtPfsGui code imported and improved as a new kipi-plugins (code is in my home dir from KDE svn), I never give a right result as HDR creation and Tonemapping. QtPfsGui code is very very very experiemental. Only one time, i create successfully an HDR image without artefact. This is not enough for me/ I cannot understand why users said that QtPfsGui is a good program. Please, if you fell that i'm wrong let's me hear. Perhaps i have a simple view of programmer, but at least code speak about : I lost one week to review and fix this code to be suitable, readable, and maintainable. It's a shame to writte code like this... but it's another story... So, after to be tired to play with QtPfsGui code, i thinking to take another way : Enfuse. The idea is simple : 1/ Define a stack of bracketed images. 2/ If Raw images, convert it to TIFF 16 bits with auto-gamma. 3/ Auto Align stack with Hugin auto_align_stack command line program. 4/ Start pseudo-HDR editor, the famous Enfuse frontend designed by me (:=))) All is done, excepted step 2, partially implemented. Tool is currently suitable with all other images formats as JPEG, PNG, TIFF, etc... You need to install Hugin and Enblend project to your computer before to use this new tool. Now the screenshots... Champagne please ! 1/ The tool is available in digiKam Tools menu : http://farm3.static.flickr.com/2657/4203352088_78f8025d41_o.png 2/ The first stage of the tool is an assistant : http://farm3.static.flickr.com/2681/4203352164_388c23be82_o.png 3/ You need first to set-up bracketed images stack : http://farm3.static.flickr.com/2590/4203352256_91dd0dbd55_o.png 4/ After that tool is ready to process auto alignment of stack : http://farm3.static.flickr.com/2629/4202593315_7bd8a6fe66_o.png 5/ Auto-Alignment can be long... so, take a cup of Champagne to be patient : http://farm3.static.flickr.com/2596/4203352414_edc73d4d8d_o.png 6/ "Et Voilà". Auto-Alignment is done. Aligned images are save to temp TIFF files : http://farm5.static.flickr.com/4006/4203352494_49704b8972_o.png 7/ And now, the best for the end... Let's go to fuse bracketed images : http://farm3.static.flickr.com/2496/4203352570_b30255d05b_o.png 8/ Enfuse take a while too, depending of options used... At least, result is great (:=))) : http://farm3.static.flickr.com/2761/4202593625_e03a4d8256_o.png My TODO List : - Move this tool from my home KDE svn dir to trunk to be available in kipi-plugins 1.1. I will do it soon. - Add Raw support. - Add a stack of processed images in Enfuse Gui. Selecting one items will display it in preview. You can select the best to export in your collection. - Add some advanced Enfuse options. Here i'm waiting comments form users... - Hack last bugs, memory leak, and other joys (:=)))... Important : this tool is also available as a stand alone application "expoblending". It's installed in your usual binary place from your computer. I'm waiting your viewpoints, feedback, critics... etc... Your servant Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Ok, now that it compiled some comments:
1. Nice! Great results on first shot. :) Thanks for the tool. 2. What about adding the ability to generate a preview on a down-scaled version of the images? That could speed up the process of finding the right parameters. 3. Sometime the next-buttons were disabled for me without any reason. Especially after adding the photos to the list via a selection in digikam I couldn't move on. It only works after opening the dialog to add photos and then closing it without adding photos there. 4. Enfuse only works once. Create an initial version using enfuse, change parameters, click "process" again and I get an error message. Johannes Am 21.12.2009 14:22 schrieb Gilles Caulier: > Hi all, > > Since few day, i working hard to create a new tool to make pseudo HDR image. > > After some try with QtPfsGui code imported and improved as a new > kipi-plugins (code is in my home dir from KDE svn), I never give a > right result as HDR creation and Tonemapping. QtPfsGui code is very > very very experiemental. Only one time, i create successfully an HDR > image without artefact. This is not enough for me/ > > I cannot understand why users said that QtPfsGui is a good program. > Please, if you fell that i'm wrong let's me hear. Perhaps i have a > simple view of programmer, but at least code speak about : I lost one > week to review and fix this code to be suitable, readable, and > maintainable. > > It's a shame to writte code like this... but it's another story... > > So, after to be tired to play with QtPfsGui code, i thinking to take > another way : Enfuse. > > The idea is simple : > > 1/ Define a stack of bracketed images. > 2/ If Raw images, convert it to TIFF 16 bits with auto-gamma. > 3/ Auto Align stack with Hugin auto_align_stack command line program. > 4/ Start pseudo-HDR editor, the famous Enfuse frontend designed by me (:=))) > > All is done, excepted step 2, partially implemented. Tool is currently > suitable with all other images formats as JPEG, PNG, TIFF, etc... > > You need to install Hugin and Enblend project to your computer before > to use this new tool. > > Now the screenshots... Champagne please ! > > 1/ The tool is available in digiKam Tools menu : > > http://farm3.static.flickr.com/2657/4203352088_78f8025d41_o.png > > 2/ The first stage of the tool is an assistant : > > http://farm3.static.flickr.com/2681/4203352164_388c23be82_o.png > > 3/ You need first to set-up bracketed images stack : > > http://farm3.static.flickr.com/2590/4203352256_91dd0dbd55_o.png > > 4/ After that tool is ready to process auto alignment of stack : > > http://farm3.static.flickr.com/2629/4202593315_7bd8a6fe66_o.png > > 5/ Auto-Alignment can be long... so, take a cup of Champagne to be patient : > > http://farm3.static.flickr.com/2596/4203352414_edc73d4d8d_o.png > > 6/ "Et Voilà". Auto-Alignment is done. Aligned images are save to temp > TIFF files : > > http://farm5.static.flickr.com/4006/4203352494_49704b8972_o.png > > 7/ And now, the best for the end... Let's go to fuse bracketed images : > > http://farm3.static.flickr.com/2496/4203352570_b30255d05b_o.png > > 8/ Enfuse take a while too, depending of options used... At least, > result is great (:=))) : > > http://farm3.static.flickr.com/2761/4202593625_e03a4d8256_o.png > > My TODO List : > > - Move this tool from my home KDE svn dir to trunk to be available in > kipi-plugins 1.1. I will do it soon. > - Add Raw support. > - Add a stack of processed images in Enfuse Gui. Selecting one items > will display it in preview. You can select the best to export in your > collection. > - Add some advanced Enfuse options. Here i'm waiting comments form users... > - Hack last bugs, memory leak, and other joys (:=)))... > > Important : this tool is also available as a stand alone application > "expoblending". It's installed in your usual binary place from your > computer. > > I'm waiting your viewpoints, feedback, critics... etc... > > Your servant > > Gilles Caulier > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
2009/12/21 Johannes Wienke <[hidden email]>:
> Ok, now that it compiled some comments: > > 1. Nice! Great results on first shot. :) Thanks for the tool. > Thanks. I justy added the way to process enfuse only on selected items from bracketed stack. Checkout trunk again... > 2. What about adding the ability to generate a preview on a down-scaled > version of the images? That could speed up the process of finding the right > parameters. Yes, i can do that using IPTC preview. I need to process preview comptation after align_images_stack. On my TODO list... > > 3. Sometime the next-buttons were disabled for me without any reason. > Especially after adding the photos to the list via a selection in digikam I > couldn't move on. It only works after opening the dialog to add photos and > then closing it without adding photos there. > Yes a little bug. Missing to call slot somewhere... > 4. Enfuse only works once. Create an initial version using enfuse, change > parameters, click "process" again and I get an error message. Already temporally fixed. It's about tmp files cleaned. I need to find a better way Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Johannes Wienke-3
2009/12/21 Johannes Wienke <[hidden email]>:
> Ok, now that it compiled some comments: > > 1. Nice! Great results on first shot. :) Thanks for the tool. > > 2. What about adding the ability to generate a preview on a down-scaled > version of the images? That could speed up the process of finding the right > parameters. > > 3. Sometime the next-buttons were disabled for me without any reason. > Especially after adding the photos to the list via a selection in digikam I > couldn't move on. It only works after opening the dialog to add photos and > then closing it without adding photos there. Fixed on svn. Please test and report Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
> My TODO List :
> > - Move this tool from my home KDE svn dir to trunk to be available in > kipi-plugins 1.1. I will do it soon. Done > - Add Raw support. Done on my computer... But as align_images_stack is not able to handle different image color depth format at the same time (ex : JPEG 8bits and tiff 16bits) i'm not sure if to provide a RAW decoding settings panel in wizard is really a good way. I prefer an automatized process, which decide the right raw decoding settings to use. Your viewpoints ? Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
2009/12/22 Gilles Caulier <[hidden email]>:
>> My TODO List : >> >> - Move this tool from my home KDE svn dir to trunk to be available in >> kipi-plugins 1.1. I will do it soon. > > Done > >> - Add Raw support. > > Done on my computer... But as align_images_stack is not able to handle > different image color depth format at the same time (ex : JPEG 8bits > and tiff 16bits) i'm not sure if to provide a RAW decoding settings > panel in wizard is really a good way. > > I prefer an automatized process, which decide the right raw decoding > settings to use. Your viewpoints ? > > Gilles Caulier > Raw support commited on turnk. Please test and report Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Gilles Caulier-4
Hi,
Am 21.12.2009 22:07 schrieb Gilles Caulier: > Just compile and install libkdcraw form trunk in place... > > I do it here without any problem. Hm, now I got a problem with this. A trunk version from 2 days ago always causes digikam to crash when opening the settings and I got no idea what the problem is: Thread 1 (Thread 0x7f78d25517c0 (LWP 9111)): [KCrash Handler] #5 0x00007f78ccd14a96 in QListData::size (this=0x6781d80, index=0) at ../../include/QtCore/../../src/corelib/tools/qlist.h:87 #6 QList<QToolBoxPrivate::Page>::size (this=0x6781d80, index=0) at ../../include/QtCore/../../src/corelib/tools/qlist.h:117 #7 QToolBoxPrivate::page (this=0x6781d80, index=0) at widgets/qtoolbox.cpp:147 #8 0x00007f78ccd14bed in QToolBox::setItemIcon (this=<value optimized out>, index=0, icon=...) at widgets/qtoolbox.cpp:642 #9 0x00000000004c7394 in SetupDcraw (this=0x536be00, parent=<value optimized out>) at /home/languitar/workspace/digiKam/utilities/setup/setupdcraw.cpp:110 #10 0x00000000004b134c in Setup (this=0x5198c10, parent=<value optimized out>) at /home/languitar/workspace/digiKam/utilities/setup/setup.cpp:212 #11 0x00000000004b1c71 in Digikam::Setup::exec (parent=0xf927f0, page=Digikam::Setup::LastPageUsed) at /home/languitar/workspace/digiKam/utilities/setup/setup.cpp:336 #12 0x00000000005fac7f in Digikam::DigikamApp::qt_metacall (this=0xf927f0, _c=QMetaObject::InvokeMetaMethod, _id=87480272, _a=0x7fff6b6edde0) at /home/languitar/workspace/build/digiKam/digikam/digikamapp.moc:217 #13 0x00007f78cbd66ddc in QMetaObject::activate (sender=0x28be710, from_signal_index=<value optimized out>, to_signal_index=<value optimized out>, argv=0x1) at kernel/qobject.cpp:3113 #14 0x00007f78cc8dd0a7 in QAction::triggered (this=0x6781d80, _t1=false) at .moc/release-shared/moc_qaction.cpp:236 #15 0x00007f78cc8de4ef in QAction::activate (this=0x28be710, event=<value optimized out>) at kernel/qaction.cpp:1160 #16 0x00007f78ccccaecd in QMenuPrivate::activateCausedStack (this=<value optimized out>, causedStack=..., action=0x28be710, action_e=QAction::Trigger, self=true) at widgets/qmenu.cpp:967 #17 0x00007f78cccd0dea in QMenuPrivate::activateAction (this=0x4bb8d50, action=0x28be710, action_e=QAction::Trigger, self=<value optimized out>) at widgets/qmenu.cpp:1060 #18 0x00007f78cdda62be in KMenu::mouseReleaseEvent (this=0x4bb8990, e=0x0) at ../../kdeui/widgets/kmenu.cpp:456 #19 0x00007f78cc9319c0 in QWidget::event (this=0x4bb8990, event=0x7fff6b6ee800) at kernel/qwidget.cpp:7549 #20 0x00007f78cccd35ab in QMenu::event (this=0x4bb8990, e=0x7fff6b6ee800) at widgets/qmenu.cpp:2353 #21 0x00007f78cc8e2efc in QApplicationPrivate::notify_helper (this=0xc7aea0, receiver=0x4bb8990, e=0x7fff6b6ee800) at kernel/qapplication.cpp:4056 #22 0x00007f78cc8ea011 in QApplication::notify (this=<value optimized out>, receiver=0x4bb8990, e=0x7fff6b6ee800) at kernel/qapplication.cpp:3758 #23 0x00007f78cdcd3ab6 in KApplication::notify (this=0x7fff6b6f0780, receiver=0x4bb8990, event=0x7fff6b6ee800) at ../../kdeui/kernel/kapplication.cpp:302 #24 0x00007f78cbd51c2c in QCoreApplication::notifyInternal (this=0x7fff6b6f0780, receiver=0x4bb8990, event=0x7fff6b6ee800) at kernel/qcoreapplication.cpp:610 #25 0x00007f78cc8e98e0 in QCoreApplication::sendSpontaneousEvent (receiver=0x4bb8990, event=0x7fff6b6ee800, alienWidget=0x0, nativeWidget=0x4bb8990, buttonDown=<value optimized out>, lastMouseReceiver=<value optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:216 #26 QApplicationPrivate::sendMouseEvent (receiver=0x4bb8990, event=0x7fff6b6ee800, alienWidget=0x0, nativeWidget=0x4bb8990, buttonDown=<value optimized out>, lastMouseReceiver=<value optimized out>) at kernel/qapplication.cpp:2924 #27 0x00007f78cc94fe2e in QETWidget::translateMouseEvent (this=0x4bb8990, event=<value optimized out>) at kernel/qapplication_x11.cpp:4343 #28 0x00007f78cc94eaa9 in QApplication::x11ProcessEvent (this=<value optimized out>, event=0x7fff6b6f0330) at kernel/qapplication_x11.cpp:3550 #29 0x00007f78cc977d0c in x11EventSourceDispatch (s=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:146 #30 0x00007f78c4ef8bce in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #31 0x00007f78c4efc598 in ?? () from /lib/libglib-2.0.so.0 #32 0x00007f78c4efc6c0 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #33 0x00007f78cbd7a1a6 in QEventDispatcherGlib::processEvents (this=0xc40590, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:327 #34 0x00007f78cc9774be in QGuiEventDispatcherGlib::processEvents (this=0x6781d80, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:202 #35 0x00007f78cbd50532 in QEventLoop::processEvents (this=<value optimized out>, flags=) at kernel/qeventloop.cpp:149 #36 0x00007f78cbd50904 in QEventLoop::exec (this=0x7fff6b6f0660, flags=) at kernel/qeventloop.cpp:201 #37 0x00007f78cbd52ab9 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:888 #38 0x00000000006b51f1 in main (argc=<value optimized out>, argv=<value optimized out>) at /home/languitar/workspace/digiKam/digikam/main.cpp:195 The current source language is "auto; currently c". That's the relevant part of the backtrace. Do you - or anyone else - have an idea what this could be? Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Look like "kdcraw" icon from libkdcraw is not found on your system,
and Kdelibs crash (this is abnormal of course) Gilles 2009/12/23 Johannes Wienke <[hidden email]>: > Hi, > > Am 21.12.2009 22:07 schrieb Gilles Caulier: >> >> Just compile and install libkdcraw form trunk in place... >> >> I do it here without any problem. > > Hm, now I got a problem with this. A trunk version from 2 days ago always > causes digikam to crash when opening the settings and I got no idea what the > problem is: > > Thread 1 (Thread 0x7f78d25517c0 (LWP 9111)): > [KCrash Handler] > #5 0x00007f78ccd14a96 in QListData::size (this=0x6781d80, index=0) at > ../../include/QtCore/../../src/corelib/tools/qlist.h:87 > #6 QList<QToolBoxPrivate::Page>::size (this=0x6781d80, index=0) at > ../../include/QtCore/../../src/corelib/tools/qlist.h:117 > #7 QToolBoxPrivate::page (this=0x6781d80, index=0) at > widgets/qtoolbox.cpp:147 > #8 0x00007f78ccd14bed in QToolBox::setItemIcon (this=<value optimized out>, > index=0, icon=...) at widgets/qtoolbox.cpp:642 > #9 0x00000000004c7394 in SetupDcraw (this=0x536be00, parent=<value > optimized out>) at > /home/languitar/workspace/digiKam/utilities/setup/setupdcraw.cpp:110 > #10 0x00000000004b134c in Setup (this=0x5198c10, parent=<value optimized > out>) at /home/languitar/workspace/digiKam/utilities/setup/setup.cpp:212 > #11 0x00000000004b1c71 in Digikam::Setup::exec (parent=0xf927f0, > page=Digikam::Setup::LastPageUsed) at > /home/languitar/workspace/digiKam/utilities/setup/setup.cpp:336 > #12 0x00000000005fac7f in Digikam::DigikamApp::qt_metacall (this=0xf927f0, > _c=QMetaObject::InvokeMetaMethod, _id=87480272, _a=0x7fff6b6edde0) > at /home/languitar/workspace/build/digiKam/digikam/digikamapp.moc:217 > #13 0x00007f78cbd66ddc in QMetaObject::activate (sender=0x28be710, > from_signal_index=<value optimized out>, to_signal_index=<value optimized > out>, argv=0x1) at kernel/qobject.cpp:3113 > #14 0x00007f78cc8dd0a7 in QAction::triggered (this=0x6781d80, _t1=false) at > .moc/release-shared/moc_qaction.cpp:236 > #15 0x00007f78cc8de4ef in QAction::activate (this=0x28be710, event=<value > optimized out>) at kernel/qaction.cpp:1160 > #16 0x00007f78ccccaecd in QMenuPrivate::activateCausedStack (this=<value > optimized out>, causedStack=..., action=0x28be710, > action_e=QAction::Trigger, self=true) at widgets/qmenu.cpp:967 > #17 0x00007f78cccd0dea in QMenuPrivate::activateAction (this=0x4bb8d50, > action=0x28be710, action_e=QAction::Trigger, self=<value optimized out>) at > widgets/qmenu.cpp:1060 > #18 0x00007f78cdda62be in KMenu::mouseReleaseEvent (this=0x4bb8990, e=0x0) > at ../../kdeui/widgets/kmenu.cpp:456 > #19 0x00007f78cc9319c0 in QWidget::event (this=0x4bb8990, > event=0x7fff6b6ee800) at kernel/qwidget.cpp:7549 > #20 0x00007f78cccd35ab in QMenu::event (this=0x4bb8990, e=0x7fff6b6ee800) at > widgets/qmenu.cpp:2353 > #21 0x00007f78cc8e2efc in QApplicationPrivate::notify_helper (this=0xc7aea0, > receiver=0x4bb8990, e=0x7fff6b6ee800) at kernel/qapplication.cpp:4056 > #22 0x00007f78cc8ea011 in QApplication::notify (this=<value optimized out>, > receiver=0x4bb8990, e=0x7fff6b6ee800) at kernel/qapplication.cpp:3758 > #23 0x00007f78cdcd3ab6 in KApplication::notify (this=0x7fff6b6f0780, > receiver=0x4bb8990, event=0x7fff6b6ee800) at > ../../kdeui/kernel/kapplication.cpp:302 > #24 0x00007f78cbd51c2c in QCoreApplication::notifyInternal > (this=0x7fff6b6f0780, receiver=0x4bb8990, event=0x7fff6b6ee800) at > kernel/qcoreapplication.cpp:610 > #25 0x00007f78cc8e98e0 in QCoreApplication::sendSpontaneousEvent > (receiver=0x4bb8990, event=0x7fff6b6ee800, alienWidget=0x0, > nativeWidget=0x4bb8990, buttonDown=<value optimized out>, > lastMouseReceiver=<value optimized out>) at > ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:216 > #26 QApplicationPrivate::sendMouseEvent (receiver=0x4bb8990, > event=0x7fff6b6ee800, alienWidget=0x0, nativeWidget=0x4bb8990, > buttonDown=<value optimized out>, lastMouseReceiver=<value optimized out>) > at kernel/qapplication.cpp:2924 > #27 0x00007f78cc94fe2e in QETWidget::translateMouseEvent (this=0x4bb8990, > event=<value optimized out>) at kernel/qapplication_x11.cpp:4343 > #28 0x00007f78cc94eaa9 in QApplication::x11ProcessEvent (this=<value > optimized out>, event=0x7fff6b6f0330) at kernel/qapplication_x11.cpp:3550 > #29 0x00007f78cc977d0c in x11EventSourceDispatch (s=<value optimized out>, > callback=<value optimized out>, user_data=<value optimized out>) at > kernel/qguieventdispatcher_glib.cpp:146 > #30 0x00007f78c4ef8bce in g_main_context_dispatch () from > /lib/libglib-2.0.so.0 > #31 0x00007f78c4efc598 in ?? () from /lib/libglib-2.0.so.0 > #32 0x00007f78c4efc6c0 in g_main_context_iteration () from > /lib/libglib-2.0.so.0 > #33 0x00007f78cbd7a1a6 in QEventDispatcherGlib::processEvents > (this=0xc40590, flags=<value optimized out>) at > kernel/qeventdispatcher_glib.cpp:327 > #34 0x00007f78cc9774be in QGuiEventDispatcherGlib::processEvents > (this=0x6781d80, flags=<value optimized out>) at > kernel/qguieventdispatcher_glib.cpp:202 > #35 0x00007f78cbd50532 in QEventLoop::processEvents (this=<value optimized > out>, flags=) at kernel/qeventloop.cpp:149 > #36 0x00007f78cbd50904 in QEventLoop::exec (this=0x7fff6b6f0660, flags=) at > kernel/qeventloop.cpp:201 > #37 0x00007f78cbd52ab9 in QCoreApplication::exec () at > kernel/qcoreapplication.cpp:888 > #38 0x00000000006b51f1 in main (argc=<value optimized out>, argv=<value > optimized out>) at /home/languitar/workspace/digiKam/digikam/main.cpp:195 > The current source language is "auto; currently c". > > That's the relevant part of the backtrace. Do you - or anyone else - have an > idea what this could be? > > Johannes > > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Am 23.12.2009 12:13 schrieb Gilles Caulier:
> Look like "kdcraw" icon from libkdcraw is not found on your system, > and Kdelibs crash (this is abnormal of course) kdcraw is installed in the normal kde prefix and these files exists: /usr/share/icons/hicolor/128x128/apps/kdcraw.png /usr/share/icons/hicolor/32x32/apps/kdcraw.png /usr/share/icons/hicolor/48x48/apps/kdcraw.png /usr/share/icons/hicolor/64x64/apps/kdcraw.png Shouldn't that be enough? Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
yes sure... Comment setupdcraw.cpp:110 to be sure...
Gilles 2009/12/23 Johannes Wienke <[hidden email]>: > Am 23.12.2009 12:13 schrieb Gilles Caulier: >> >> Look like "kdcraw" icon from libkdcraw is not found on your system, >> and Kdelibs crash (this is abnormal of course) > > kdcraw is installed in the normal kde prefix and these files exists: > /usr/share/icons/hicolor/128x128/apps/kdcraw.png > /usr/share/icons/hicolor/32x32/apps/kdcraw.png > /usr/share/icons/hicolor/48x48/apps/kdcraw.png > /usr/share/icons/hicolor/64x64/apps/kdcraw.png > > Shouldn't that be enough? > > Johannes > > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Am 23.12.2009 12:32 schrieb Gilles Caulier:
> yes sure... Comment setupdcraw.cpp:110 to be sure... Ok, forget about the problem. With a compile recompile and disabling ccache it works now... No more ccache for me. ;) Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
(:=)))...
I just commit in kipi-plugins a new widget to zoom in / zoom out / pan Exposure blending tool preview... Gilles 2009/12/23 Johannes Wienke <[hidden email]>: > Am 23.12.2009 12:32 schrieb Gilles Caulier: >> >> yes sure... Comment setupdcraw.cpp:110 to be sure... > > Ok, forget about the problem. With a compile recompile and disabling ccache > it works now... No more ccache for me. ;) > > Johannes > > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Johannes Wienke-3
You must be doing something wrong ;-) , I had never problems with ccache :-)
Maybe you need to check the settings... Andi Clemens ----------------- www.digikam.org On Wednesday 23 December 2009 13:03:17 Johannes Wienke wrote: > Am 23.12.2009 12:32 schrieb Gilles Caulier: > > yes sure... Comment setupdcraw.cpp:110 to be sure... > > Ok, forget about the problem. With a compile recompile and disabling > ccache it works now... No more ccache for me. ;) > > Johannes > _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
Am 23.12.2009 19:17 schrieb Andi Clemens:
> You must be doing something wrong ;-) , I had never problems with ccache :-) > Maybe you need to check the settings... Default settings... I also had several problems where dependent files weren't recompiled so that I didn't notice a problem but Marcel coulnd't compile the code. ;) Did you change any settings? Johannes _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
In reply to this post by Bugzilla from andi.clemens@gmx.net
Andi,
I create a new version of PreviewImage widget in libkipi-plugins, using QGraphicsView,as you have done in RedEyesRemoval, Plus some improvements, as toolbar, I checked code from libksane, where Sare has used also QGraphicsView. Idem into DarkRoom from Ciry Berger (Krita team). In all case, Zoom and panning is slow. Can you reproduce ? I make something wrong with Scene cache settings ? Sound like Qt4 APi is not yet optimized here.(:=)))) In all case, digiKam::PreviewWidget using imlib2 code is very well faster... Gilles 2009/12/23 Andi Clemens <[hidden email]>: > You must be doing something wrong ;-) , I had never problems with ccache :-) > Maybe you need to check the settings... > > Andi Clemens > ----------------- > www.digikam.org > > On Wednesday 23 December 2009 13:03:17 Johannes Wienke wrote: >> Am 23.12.2009 12:32 schrieb Gilles Caulier: >> > yes sure... Comment setupdcraw.cpp:110 to be sure... >> >> Ok, forget about the problem. With a compile recompile and disabling >> ccache it works now... No more ccache for me. ;) >> >> Johannes >> > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
> Andi, > > I create a new version of PreviewImage widget in libkipi-plugins, > using QGraphicsView,as you have done in RedEyesRemoval, Plus some > improvements, as toolbar, > > I checked code from libksane, where Sare has used also QGraphicsView. > Idem into DarkRoom from Ciry Berger (Krita team). > > In all case, Zoom and panning is slow. Can you reproduce ? > > I make something wrong with Scene cache settings ? > > Sound like Qt4 APi is not yet optimized here.(:=)))) > > In all case, digiKam::PreviewWidget using imlib2 code is very well > faster... Are you using Qt facilities to implement the zooming? I would expect to continue using the current zooming code when drawing on the graphics view. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
2009/12/24 Marcel Wiesweg <[hidden email]>:
> >> Andi, >> >> I create a new version of PreviewImage widget in libkipi-plugins, >> using QGraphicsView,as you have done in RedEyesRemoval, Plus some >> improvements, as toolbar, >> >> I checked code from libksane, where Sare has used also QGraphicsView. >> Idem into DarkRoom from Ciry Berger (Krita team). >> >> In all case, Zoom and panning is slow. Can you reproduce ? >> >> I make something wrong with Scene cache settings ? >> >> Sound like Qt4 APi is not yet optimized here.(:=)))) >> >> In all case, digiKam::PreviewWidget using imlib2 code is very well >> faster... > > Are you using Qt facilities to implement the zooming? > I would expect to continue using the current zooming code when drawing on the > graphics view. Hum, what do you mean exactly ? Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
> >> In all case, Zoom and panning is slow. Can you reproduce ? > >> > >> I make something wrong with Scene cache settings ? > >> > >> Sound like Qt4 APi is not yet optimized here.(:=)))) > >> > >> In all case, digiKam::PreviewWidget using imlib2 code is very well > >> faster... > > > > Are you using Qt facilities to implement the zooming? > > I would expect to continue using the current zooming code when drawing on > > the graphics view. > > Hum, what do you mean exactly ? You say that imlib2 code is faster than the new graphics view widget's zooming From that I understood that you're not using DImg based zooming but some other code to do the zooming. I didn't look at the code yet at all. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
2009/12/24 Marcel Wiesweg <[hidden email]>:
> >> >> In all case, Zoom and panning is slow. Can you reproduce ? >> >> >> >> I make something wrong with Scene cache settings ? >> >> >> >> Sound like Qt4 APi is not yet optimized here.(:=)))) >> >> >> >> In all case, digiKam::PreviewWidget using imlib2 code is very well >> >> faster... >> > >> > Are you using Qt facilities to implement the zooming? >> > I would expect to continue using the current zooming code when drawing on >> > the graphics view. >> >> Hum, what do you mean exactly ? > > You say that imlib2 code is faster than the new graphics view widget's zooming > From that I understood that you're not using DImg based zooming but some other > code to do the zooming. > I didn't look at the code yet at all. Marcel, All zoom and paning features are controled by QT4::QGraphicView. No more. Code is very simple, but... not very fast. Look there : http://lxr.kde.org/source/extragear/graphics/kipi-plugins/common/libkipiplugins/previewimage.cpp#80 Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
> > All zoom and paning features are controled by QT4::QGraphicView. No > more. Code is very simple, but... not very fast. Yes, it cannot be. In fact, you will get bad performance combined with bad quality ;-) d->pixmapItem->setPixmap(QPixmap::fromImage(image)); For digikam, we will use DImg, here it's QImage. Doesn't matter. What happen when "image" is to be painted at zoom 2.0? The image is converted to a pixmap. Depending on the underlying graphics engine, this implies color format conversion (in the best case to ARGB32_Premultiplied, in worse cases e.g. to ARGB8565_Premultiplied or RGB16) and, for the case of X.org, transport by Xlib protocol to the server. For scaling, in the case of X.org, the data need to be tranferred from the X server to the application, converted to a QImage, scaled by a factor of 2.0, converted back to QPixmap, and again transferred to the X server, where it is finally blitted to the window surface. What should be done? Never scale a pixmap. Scale the DImg and only convert to pixmap the data that will 1:1, unscaled, be painted on screen. For caching to improve painting performance, cache only this pixmap data, do not cache pixmap data which still needs scaling. (You can scale the original image, but that's not for painting performance) QGraphicsView can give us a lot to have items on the preview, as needed for some image plugins, but - I tried to say that during the coding sprint - I dont believe its scaling facilities can be used out of the box. As soon as the painter has a transform, like calling scale() on the view, painting image data will be slower. I would experiment with a custom item which is ItemIgnoresTransformations and the DeviceCoordinate cache mode, or resetting the painter transform before painting. We must also keep in mind that in the case of scale()ing the view, items on preview, like handles for perspective adjustment, will grow and shrink as well. Perhaps they need ItemIgnoresTransformations. They may be other, better approaches as well. Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
| Free forum by Nabble | Edit this page |
