extragear/graphics/digikam
Locked
 
|
SVN commit 488426 by cgilles:
Digikam from trunk : - Removing old image histogram constructor. - Copy selection from IE work with 16 bits image. You can copy and paste image selection from IE to Krita. data are converted to 8 bits because 16 bits isn't supported by clipboard. - blended histogram on IE canvas no support 16 bits images CCMAIL: [hidden email] M +0 -6 libs/histogram/imagehistogram.cpp M +0 -3 libs/histogram/imagehistogram.h M +26 -25 utilities/imageeditor/canvas/canvas.cpp --- trunk/extragear/graphics/digikam/libs/histogram/imagehistogram.cpp #488425:488426 @@ -57,12 +57,6 @@ setup(i_data, i_w, i_h, i_sixteenBits, parent); } -ImageHistogram::ImageHistogram(uint *i_data, uint i_w, uint i_h, QObject *parent) - : QThread() -{ - setup((uchar*)i_data, i_w, i_h, false, parent); -} - void ImageHistogram::setup(uchar *i_data, uint i_w, uint i_h, bool i_sixteenBits, QObject *parent) { m_imageData = i_data; --- trunk/extragear/graphics/digikam/libs/histogram/imagehistogram.h #488425:488426 @@ -80,9 +80,6 @@ public: - // FIXME : remove this cpnstructor when all digiKam core will be ported to DImg. - ImageHistogram(uint *i_data, uint i_w, uint i_h, QObject *parent=0); - ImageHistogram(uchar *i_data, uint i_w, uint i_h, bool i_sixteenBits, QObject *parent=0); ImageHistogram(const DImg& image, QObject *parent=0); --- trunk/extragear/graphics/digikam/utilities/imageeditor/canvas/canvas.cpp #488425:488426 @@ -276,13 +276,14 @@ p.fillRect(QRect(0, 0, wWidth, wHeight), QBrush(qRgba(0xff, 0xff, 0xff, 127))); - // logic stolen from histogramwidget.c + // logic stolen from histogramwidget.cpp + for (x = 0 ; x < wWidth ; ++x) { double value = 0.0; int i, j; - i = (x * 256) / wWidth; + i = (x * histogram->getHistogramSegment()) / wWidth; j = i + 1; do @@ -301,19 +302,20 @@ QColor hiscolor; - switch (type) { - case ImageHistogram::RedChannel: - hiscolor = qRgba(0xFF, 0, 0, 127); - break; - case ImageHistogram::GreenChannel: - hiscolor = qRgba(0, 0xFF, 0, 127); - break; - case ImageHistogram::BlueChannel: - hiscolor = qRgba(0, 0, 0xFF, 127); - break; - default: - hiscolor = qRgba(0, 0, 0, 127); - break; + switch (type) + { + case ImageHistogram::RedChannel: + hiscolor = qRgba(0xFF, 0, 0, 127); + break; + case ImageHistogram::GreenChannel: + hiscolor = qRgba(0, 0xFF, 0, 127); + break; + case ImageHistogram::BlueChannel: + hiscolor = qRgba(0, 0, 0xFF, 127); + break; + default: + hiscolor = qRgba(0, 0, 0, 127); + break; } p.setPen(QPen::QPen(hiscolor, 1, Qt::SolidLine)); @@ -520,11 +522,13 @@ d->imageHistogram = 0; } - if (d->imageHistogram == 0) { + if (d->imageHistogram == 0) + { d->histogramReady = false; - d->imageHistogram = new ImageHistogram(d->im->getData(), + d->imageHistogram = new ImageHistogram(d->im->getImage(), d->im->origWidth(), d->im->origHeight(), + d->im->sixteenBit(), this); // paint busy drawHistogramPixmapBusy(); @@ -1428,15 +1432,12 @@ return; QApplication::setOverrideCursor (Qt::waitCursor); - uint* data = d->im->getSelectedData(); - - QImage selImg; - selImg.create(w, h, 32); - memcpy(selImg.bits(), data, selImg.numBytes()); - + uchar* data = d->im->getImageSelection(); + DImg selDImg = DImg(w, h, d->im->sixteenBit(), d->im->hasAlpha(), data); + delete [] data; + + QImage selImg = selDImg.copyQImage(); QApplication::clipboard()->setData(new QImageDrag(selImg), QClipboard::Clipboard); - - delete [] data; QApplication::restoreOverrideCursor (); } _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
On Wed, 14 Dec 2005, Gilles Caulier wrote:
> SVN commit 488426 by cgilles: > > Digikam from trunk : > > - Removing old image histogram constructor. > - Copy selection from IE work with 16 bits image. You can copy and paste image selection from IE to Krita. data are converted to 8 bits because 16 bits isn't supported by clipboard. Is this something we could work on? It would be cool... Boudewijn _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
Le Mercredi 14 Décembre 2005 13:23, vous avez écrit :
> On Wed, 14 Dec 2005, Gilles Caulier wrote: > > SVN commit 488426 by cgilles: > > > > Digikam from trunk : > > > > - Removing old image histogram constructor. > > - Copy selection from IE work with 16 bits image. You can copy and paste > > image selection from IE to Krita. data are converted to 8 bits because 16 > > bits isn't supported by clipboard. > > Is this something we could work on? It would be cool... > Hi Boudewijn, how are you (:=)))... Sure, in the future, we need to improve krita/digiKam interoperability. I adding this task in my TODO list, because i had any other stuff to do before... But, there is one point that we can talking now : a common ICC profiles repository between krita and digiKam. Like you have see certainly, digiKam now support ICC profiles to render image in editor (printing coming soon). We have started a repository of digital still camera profiles at this url : http://digikam3rdparty.free.fr/ICCPROFILES/ In kde svn, krita provide any common ICC profiles : http://websvn.kde.org/trunk/koffice/krita/data/profiles/ Questions : 1 / Perhaps we can merge these places ? 2 / Are you sure that includes ICC profiles in svn is the better place ? 3 / ICC profiles are (c). Are you sure that you can includes by default krita profiles with koffice packages without any problems with commercial compagnies ? (This is why digiKam team have copied ICC camera profiles in a simple web space, not svn) Any viewpoints/suggestions welcome -- Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
On Wed, 14 Dec 2005, Gilles Caulier wrote:
> Hi Boudewijn, how are you (:=)))... No laptop, so not hacking as much as I would like. > Sure, in the future, we need to improve krita/digiKam interoperability. I > adding this task in my TODO list, because i had any other stuff to do > before... > > But, there is one point that we can talking now : a common ICC profiles > repository between krita and digiKam. > > Like you have see certainly, digiKam now support ICC profiles to render image > in editor (printing coming soon). I noticed from the logs, but haven't had the hd space to build digikam recently. > We have started a repository of digital > still camera profiles at this url : Adobe has released its high qualit profiles under a quite liberal license that allows bundling with applications. The openicc project has determined a standard location for icc files: /usr/share/icc (and subdirs, but not following links) and ~/.icc (and subdirs, but not following links) Krita already supports the former, not the latter, but that's a matter of adding a little code. We don't let the user select icc files, but build a list of them and present the product names to the user. We also allow people to choose a profile that will be applied on paste of clipboard image data and so on and read the icc profile X Atom in case it's set (otherwise we use the configured icc profile). > http://digikam3rdparty.free.fr/ICCPROFILES/ > > In kde svn, krita provide any common ICC profiles : > > http://websvn.kde.org/trunk/koffice/krita/data/profiles/ > > Questions : > > 1 / Perhaps we can merge these places ? > 2 / Are you sure that includes ICC profiles in svn is the better place ? > 3 / ICC profiles are (c). Are you sure that you can includes by default krita > profiles with koffice packages without any problems with commercial > compagnies ? (This is why digiKam team have copied ICC camera profiles in a > simple web space, not svn) The profiles we bundle are all free as in public domain (and of none too good a quality). I explicitly wanted to avoid having people download profile separately, because Krita simply does not function without profiles. We've decided that a color isn't a color unless it has a profile associated with it. Camera profiles are a different issue, and one I hadn't realized existed until I started working on our RAW importer. Boudewijn _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
In reply to this post by Gilles Caulier
Oh, before I forget: the basic color management library with
the colorspace plugins has recently been separated from Krita and koffice (although it's still in the krita svn tree). It works on just arrays of Q_UINT8, so should be very reusable. Boudewijn _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
Le Mercredi 14 Décembre 2005 13:58, Boudewijn Rempt a écrit :
> Oh, before I forget: the basic color management library with > the colorspace plugins has recently been separated from Krita > and koffice (although it's still in the krita svn tree). It works > on just arrays of Q_UINT8, so should be very reusable. > > Boudewijn Hum Too late (:=)) We have already a suitable implementation and i'm not sure that to add another depency in digikam is a good choise actually. gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
In reply to this post by Boudewijn Rempt
Le Mercredi 14 Décembre 2005 13:56, vous avez écrit :
> On Wed, 14 Dec 2005, Gilles Caulier wrote: > > Hi Boudewijn, how are you (:=)))... > > No laptop, so not hacking as much as I would like. > > > Sure, in the future, we need to improve krita/digiKam interoperability. I > > adding this task in my TODO list, because i had any other stuff to do > > before... > > > > But, there is one point that we can talking now : a common ICC profiles > > repository between krita and digiKam. > > > > Like you have see certainly, digiKam now support ICC profiles to render > > image in editor (printing coming soon). > > I noticed from the logs, but haven't had the hd space to build digikam > recently. > > > We have started a repository of digital > > still camera profiles at this url : > > Adobe has released its high qualit profiles under a quite liberal > license that allows bundling with applications. The openicc project > has determined a standard location for icc files: > > /usr/share/icc (and subdirs, but not following links) > and > ~/.icc (and subdirs, but not following links) > ok. We take a care about this point when we will update digiKam handbook > Krita already supports the former, not the latter, but that's a matter of > adding a little code. We don't let the user select icc files, but build > a list of them and present the product names to the user. We also allow > people to choose a profile that will be applied on paste of clipboard > image data and so on and read the icc profile X Atom in case it's set > (otherwise we use the configured icc profile). > > > http://digikam3rdparty.free.fr/ICCPROFILES/ > > > > In kde svn, krita provide any common ICC profiles : > > > > http://websvn.kde.org/trunk/koffice/krita/data/profiles/ > > > > Questions : > > > > 1 / Perhaps we can merge these places ? > > 2 / Are you sure that includes ICC profiles in svn is the better place ? > > 3 / ICC profiles are (c). Are you sure that you can includes by default > > krita profiles with koffice packages without any problems with commercial > > compagnies ? (This is why digiKam team have copied ICC camera profiles in > > a simple web space, not svn) > > The profiles we bundle are all free as in public domain (and of none too > good a quality). I explicitly wanted to avoid having people download > profile separately, because Krita simply does not function without > profiles. We've decided that a color isn't a color unless it has a profile > associated with it. sure. > > Camera profiles are a different issue, and one I hadn't realized existed > until I started working on our RAW importer. Ah, the famous RAW importer. Have you progressed in your current implementation ? Personally, RAW loader in digikam work fine. I use an external dcraw instance to decode RAW files, but i'm not satisfied by it. For any performance reasons, including dcraw source code in digikam core will be better, but... dcraw if a sad C ansi implementation, not a clean C/C++ library. To identify and extract thumbnails from RAW files, parse.c source file from dcraw project is already included to digikam core. If i trying to add dcraw source code, i will have any method conflics between these implementations. I need to create a pure C++ class regrouping all dcraw/parse methods and create a dedicaced lib (in digiKam core). This is not a trivial task, because there is a risk to break dcraw implementation (and future dcraw source code backport). - Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
On Wed, 14 Dec 2005, Gilles Caulier wrote:
> Ah, the famous RAW importer. Have you progressed in your current > implementation ? No, because I haven't had a decent development machine for the past month. My laptop broke down and now I'm making do with an old powerbook which is just too slow. > Personally, RAW loader in digikam work fine. I use an external dcraw instance > to decode RAW files, but i'm not satisfied by it. For any performance > reasons, including dcraw source code in digikam core will be better, but... > dcraw if a sad C ansi implementation, not a clean C/C++ library. So do we: call dcraw in an external process and catch the output from stdout. I've taken a look at ufraw, which has a kind of programmable api around dcraw, but it's very obscure C code and I couldn't untangle it enough from its glib dependencies to re-use. > To identify and extract thumbnails from RAW files, parse.c source file from > dcraw project is already included to digikam core. If i trying to add dcraw > source code, i will have any method conflics between these implementations. I > need to create a pure C++ class regrouping all dcraw/parse methods and create > a dedicaced lib (in digiKam core). This is not a trivial task, because there > is a risk to break dcraw implementation (and future dcraw source code > backport). It'll be hell to maintain, that's for sure. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
In reply to this post by Boudewijn Rempt
Le Mercredi 14 Décembre 2005 13:56, Boudewijn Rempt a écrit :
> Camera profiles are a different issue, and one I hadn't realized existed > until I started working on our RAW importer. I had an advanced question about image loader technics for you... In digikam, i would fork to a dedicaced thread all loading/saving image files process. Actually, loading and saving an image is done to the GUI thread. This way froze the GUI and do not give any progress informations. This problem exist also in krita i think... I have identified 2 methods to do it : 1/ Using a KIOSlave (prefered) : This is the most powerfull method but not trivail solution because data will be shared between digikam and kioslave using a simpe bytes array. An image in digikam is not a simple pixels array but a complex class instance (DImg) including pixels, metada, ICC profiles, properties, etc... 2/ Using a children thread using QThread. This is complex to do because file descriptors are shared between GUI thread and loader thead. image loader methods must be tradesafe too (this is not the case actually). This will complex and long to finalize. Nota : this method is used by Kimdaba, Gwenview and showimg to load images using QImage. but digiKam do not use QImage to load/save image by a dedicaced API named DImg... Please fix me if something is wrong. Any viewpoints welcome (:=))) Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
In reply to this post by Boudewijn Rempt
Le Mercredi 14 Décembre 2005 15:07, vous avez écrit :
> On Wed, 14 Dec 2005, Gilles Caulier wrote: > > Ah, the famous RAW importer. Have you progressed in your current > > implementation ? > > No, because I haven't had a decent development machine for the past > month. My laptop broke down and now I'm making do with an old powerbook > which is just too slow. Yes, i have read your blog in the past (:=)))... > > > Personally, RAW loader in digikam work fine. I use an external dcraw > > instance to decode RAW files, but i'm not satisfied by it. For any > > performance reasons, including dcraw source code in digikam core will be > > better, but... dcraw if a sad C ansi implementation, not a clean C/C++ > > library. > > So do we: call dcraw in an external process and catch the output from > stdout. I've taken a look at ufraw, which has a kind of programmable api > around dcraw, but it's very obscure C code and I couldn't untangle it > enough from its glib dependencies to re-use. forget ufraw (:=))) The implementation is completly weird... Take a look in my current implementation... http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/rawloader.cpp?rev=487108&view=auto Have you used Kprocess to do it. It will take a while like this... > > > To identify and extract thumbnails from RAW files, parse.c source file > > from dcraw project is already included to digikam core. If i trying to > > add dcraw source code, i will have any method conflics between these > > implementations. I need to create a pure C++ class regrouping all > > dcraw/parse methods and create a dedicaced lib (in digiKam core). This is > > not a trivial task, because there is a risk to break dcraw implementation > > (and future dcraw source code backport). > > It'll be hell to maintain, that's for sure. Not sure if i can building a clean C++ code without broken all dcraw methods. I will study dcraw/parse source code indeep... This way have been used certailny by biblepro program... http://users.tkk.fi/~stanhua/rawcomp/ -- Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
On Wed, 14 Dec 2005, Gilles Caulier wrote:
> Yes, i have read your blog in the past (:=)))... I would have received my new laptop today, but the reseller appears to be unable to deliver. > http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/dimg/loaders/rawloader.cpp?rev=487108&view=auto I will. > Have you used Kprocess to do it. It will take a while like this... Actually, I have forgotten by now :-). I hadn't checked in yet when my laptop broke down, but I think I used QProcess. > http://users.tkk.fi/~stanhua/rawcomp/ Thanks for the link. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
In reply to this post by Gilles Caulier
Dnia środa, 14 grudnia 2005 13:47, Gilles Caulier napisał:
> > Sure, in the future, we need to improve krita/digiKam interoperability. > I adding this task in my TODO list, because i had any other stuff to do > before... Nice thing for Krita interoperability would be preloading of Krita for faster start. m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam
|
|
In reply to this post by Gilles Caulier
> I have identified 2 methods to do it :
> > 1/ Using a KIOSlave (prefered) : This is the most powerfull method but not > trivail solution because data will be shared between digikam and kioslave > using a simpe bytes array. An image in digikam is not a simple pixels array > but a complex class instance (DImg) including pixels, metada, ICC profiles, > properties, etc... KIO has some mechanisms, but it might be a real pain to serialize such a complex class. IMO serializing is bad and multi-threaded programming is fun :-) > > 2/ Using a children thread using QThread. This is complex to do because > file descriptors are shared between GUI thread and loader thead. image > loader methods must be tradesafe too (this is not the case actually). This > will complex and long to finalize. Nota : this method is used by Kimdaba, > Gwenview and showimg to load images using QImage. but digiKam do not use > QImage to load/save image by a dedicaced API named DImg... Some thoughts on this. - the more public the Dimg objects will be and the more threads, the more locking must be installed. Easiest case is some Dimg objects private to IE and one loading thread private to IE. In this case, only the communication with the thread must be locked, see below for an example. If there are other threads accessing the objects, there must probably be a mutex per object. With a mutex per object, you can (with care for pixmap conversion of course) extend that to a heavily multithreaded environment, stuff like locking for reading and writing, but we probably don't need that. - There is no fundamental difference between DImg and QImage for threads. In the end, there is a chunk of data. - File loaders (and thus libjpeg, libpng etc.) must be reentrant. If they are not, the one simple solution is one mutex per loader. Note that in Qt4, the relevant classes all are reentrant, so they have solved this. (in the world of multi-core CPUs, I think non-reentrant libs are anachronisms) PreloadedThread::checkLoaded(DImg &img, Object *notify) { QMutexLocker lock(mutex); if (!img.isLoaded()) todo.push_back(new LoadingTask(img, notify)) } PreloadThread::run() { while(running) { Task *task=0; { QMutexLocker lock(mutex); if (!todo.isEmpty()) task=todo.pop(); } if (task) { task.Execute(); //loads image, sends QCustomEvents to GUI thread delete task(); } } } IE::nextImage() { ... preloadImage(nextImage, this); // No lock on this object - knows not too touch this object, // somehow stores or knows which object(s) are being preloaded } > > Please fix me if something is wrong. Any viewpoints welcome (:=))) > > Gilles > _______________________________________________ > 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 |
Re: extragear/graphics/digikam
|
|
Le Mercredi 14 Décembre 2005 20:48, Marcel Wiesweg a écrit :
> > I have identified 2 methods to do it : > > > > 1/ Using a KIOSlave (prefered) : This is the most powerfull method but > > not trivail solution because data will be shared between digikam and > > kioslave using a simpe bytes array. An image in digikam is not a simple > > pixels array but a complex class instance (DImg) including pixels, > > metada, ICC profiles, properties, etc... > > KIO has some mechanisms, but it might be a real pain to serialize such a > complex class. IMO serializing is bad and multi-threaded programming is > fun :-) > > > 2/ Using a children thread using QThread. This is complex to do because > > file descriptors are shared between GUI thread and loader thead. image > > loader methods must be tradesafe too (this is not the case actually). > > This will complex and long to finalize. Nota : this method is used by > > Kimdaba, Gwenview and showimg to load images using QImage. but digiKam do > > not use QImage to load/save image by a dedicaced API named DImg... > > Some thoughts on this. > > - the more public the Dimg objects will be and the more threads, the more > locking must be installed. > Easiest case is some Dimg objects private to IE and one loading thread > private to IE. In this case, only the communication with the thread must be > locked, see below for an example. > > If there are other threads accessing the objects, there must probably be a > mutex per object. With a mutex per object, you can (with care for pixmap > conversion of course) extend that to a heavily multithreaded environment, > stuff like locking for reading and writing, but we probably don't need > that. > > - There is no fundamental difference between DImg and QImage for threads. > In the end, there is a chunk of data. > > - File loaders (and thus libjpeg, libpng etc.) must be reentrant. If they > are not, the one simple solution is one mutex per loader. Note that in Qt4, > the relevant classes all are reentrant, so they have solved this. (in the > world of multi-core CPUs, I think non-reentrant libs are anachronisms) > > > PreloadedThread::checkLoaded(DImg &img, Object *notify) { > QMutexLocker lock(mutex); > if (!img.isLoaded()) > todo.push_back(new LoadingTask(img, notify)) > } > > PreloadThread::run() { > while(running) { > Task *task=0; > { > QMutexLocker lock(mutex); > if (!todo.isEmpty()) > task=todo.pop(); > } > if (task) { > task.Execute(); //loads image, sends QCustomEvents to GUI thread > delete task(); > } > } > } > > IE::nextImage() { > ... > preloadImage(nextImage, this); > // No lock on this object - knows not too touch this object, > // somehow stores or knows which object(s) are being preloaded > } > > > Please fix me if something is wrong. Any viewpoints welcome (:=))) > > Ah marcel, you is a thread guru. I'm not one (:=))) Thanks for these informations. Perhaps you can help me to implement a Thread Image Loader for DImg ? -- Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |