extragear/graphics/digikam/uti
Locked
extragear/graphics/digikam/uti
 
|
SVN commit 649987 by cgilles:
digiKam from trunk : Image Editor : severe bug fix in canvas : With implementations <= 0.9.1, the canvas doesn't work properly using high zoom level (> 500). The real image <==> canvas pixmap interface do not compute properlly the tile area values. This provide a lots of "tile" artefacts over the image. Look the example here: http://digikam3rdparty.free.fr/Screenshots/editorhighzoomartefact.png Note than these "tile" artifacts are not the real tiles of canvas and of course not the JPEG artifact (the image is PNG in this screenshot) The new implementation fix this problem to handle properly the areas to use from the source image to generate the canvas pixmap tiles. Note to users : i need your feedback to check if all work fine on your computer (to be sure if my patch do not give side effects (:=)))). Thanks in advance... CCMAIL: [hidden email] M +11 -7 canvas.cpp --- trunk/extragear/graphics/digikam/utilities/imageeditor/canvas/canvas.cpp #649986:649987 @@ -480,6 +480,7 @@ QPixmap pix(d->tileSize, d->tileSize); int sx, sy, sw, sh; + int step = (int)floor(d->tileSize / d->zoom); for (int j = y1 ; j < y2 ; j += d->tileSize) { @@ -512,15 +513,18 @@ pix->fill(d->bgColor); } - // FIXME : Marcel, there is a serious problem here with high zoom level (> 500). - // The sx, sy, sw, sh values aren't computed properly and a tile artefact appear - // over the image. Look the exmaple here: + // NOTE : with implementations <= 0.9.1, the canvas doesn't work properly using high zoom level (> 500). + // The sx, sy, sw, sh values haven't be computed properly and "tile" artefacts been appears + // over the image. Look the example here: // http://digikam3rdparty.free.fr/Screenshots/editorhighzoomartefact.png + // Note than these "tile" artifacts are not the real tiles of canvas. + // The new implementation below fix this problem to handle properly the areas to + // use from the source image to generate the canvas pixmap tiles. - sx = (int)floor(i / d->zoom); - sy = (int)floor(j / d->zoom); - sw = (int)floor(d->tileSize / d->zoom); - sh = (int)floor(d->tileSize / d->zoom); + sx = (int)floor(((double)i / d->zoom) / (d->tileSize / d->zoom)) * step; + sy = (int)floor(((double)j / d->zoom) / (d->tileSize / d->zoom)) * step; + sw = step; + sh = step; if (d->rubber && d->pressedMoved && !d->pressedMoving) { _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
Dnia środa 04 kwiecień 2007, Gilles Caulier napisał:
> SVN commit 649987 by cgilles: > > Note to users : i need your feedback to check if all work fine on your > computer (to be sure if my patch do not give side effects (:=)))). > Thanks in advance... WOW! Latest patches really improved IE! It feels much faster now and no mismatches in tiles. I always blamed it on Qt smoothing not working on big zoom but all problems vanished now. Thanks. m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
Thanks Mikolaj for this report. Very appreciate...
Gilles 2007/4/4, Mikolaj Machowski <[hidden email]>:
Dnia środa 04 kwiecień 2007, Gilles Caulier napisał: _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Bugzilla from mikmach@wp.pl
2007/4/4, Arnd Baecker <[hidden email]>: GillesOn Wed, 4 Apr 2007, Mikolaj Machowski wrote: yes However, I think it would be nice if the time for "Loading ..." yes. This part have been written by Marcel. But maybe this is because I compiled from svn Yes. --enable-debug=full will post a lots of debug messages in the console witch take a while. Also --enable-final will optimize binary for speed and remove all debug info witch reduce the memory fingerprint. > I always blamed it on Qt smoothing not working on big zoom but all (:=))) Next implementation in canvas is to provide new selection tool like Bezier, circle, spline, etc. The current code hardcode the rectangle selection. I must create a new implementation witch externalize the selection tool outside. All is in my mind but nothing is yet done. I need more time to do it, certainly later 0.9.2 during this summer Also actually the image editor plugin can only handle rectangle selection. I need to fix it. in fact it's very simple : I continue to use rectangle (for ex. with a circle selection a compute the rectangle witch include the circle area). The plugin continue to work on the rectangle but when i draw the result in preview or i compute the final image (for ex. with Red eyes tool), i use a pixels mask to restitute the original pixels outside the circle area. gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
Dnia środa 04 kwiecień 2007, Gilles Caulier napisał:
> Next implementation in canvas is to provide new selection tool like > Bezier, circle, spline, etc. The current code hardcode the rectangle > selection. I must create a new implementation witch externalize the > selection tool outside. All is in my mind but nothing is yet done. I > need more time to do it, certainly later 0.9.2 during this summer Free selection? *All* plugins working on selection only? Will it be possible? m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Gilles Caulier-4
Hi Gilles,
Gilles Caulier wrote: > SVN commit 649987 by cgilles: > > digiKam from trunk : Image Editor : severe bug fix in canvas : > > With implementations <= 0.9.1, the canvas doesn't work properly using high > zoom level (> 500). The real image <==> canvas pixmap interface do not > compute properlly the tile area values. This provide a lots of "tile" > artefacts over the image. Look the example here: > > http://digikam3rdparty.free.fr/Screenshots/editorhighzoomartefact.png > > Note than these "tile" artifacts are not the real tiles of canvas and of > course not the JPEG artifact (the image is PNG in this screenshot) > > The new implementation fix this problem to handle properly the areas to > use from the source image to generate the canvas pixmap tiles. > > Note to users : i need your feedback to check if all work fine on your > computer (to be sure if my patch do not give side effects (:=)))). Thanks > in advance... thanks for fixing the tile artifacts, but there is one side effect with that commit: http://bugs.kde.org/show_bug.cgi?id=139790 (Viewer / editor: the center of the photo is moving when zooming in or out) has recently been fixed by you, but since this new commit, it's not fixed anymore. The center is moving again, before this commit it was "stable". -- Frank _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
Frank,
Checkout agian source code. it's fixed now.... Gilles 2007/4/4, Frank Siegert <[hidden email]>: Hi Gilles, _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Bugzilla from mikmach@wp.pl
2007/4/4, Mikolaj Machowski <[hidden email]>: Dnia środa 04 kwiecień 2007, Gilles Caulier napisał: sure... *All* plugins working on selection only? Not all : Red Eyes, Inpainting, and RainDrops But extend to all is not a problem. Best candidate are : Blur, Sharpen/Unsharp/Refocus. yes Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
Am Donnerstag 05 April 2007 schrieb Gilles Caulier:
> 2007/4/4, Mikolaj Machowski <[hidden email]>: > > Dnia środa 04 kwiecień 2007, Gilles Caulier napisał: > > > Next implementation in canvas is to provide new selection tool like > > > Bezier, circle, spline, etc. The current code hardcode the rectangle > > > selection. I must create a new implementation witch externalize the > > > selection tool outside. All is in my mind but nothing is yet done. I > > > need more time to do it, certainly later 0.9.2 during this summer > > > > Free selection? > > sure... > > > *All* plugins working on selection only? > Not all : Red Eyes, Inpainting, and RainDrops and for filters like Inpainting its exactly a mask so a painting-like selection tool would also be great, where you can create with some strokes such a mask/selection. And having some auto-selection tools opens the world to e.g. HDR generating filter. :-) Bye Thorsten _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Bugzilla from mikmach@wp.pl
Mikolaj,
Look my commit #650706 : http://websvn.kde.org/trunk/extragear/graphics/digikam/utilities/imageeditor/canvas/canvas.cpp?revision=650706&view=markup I don't know why KDE mail server claim than it cannot sent the mail to your mail box... Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Gilles Caulier-4
Gilles Caulier wrote:
> Checkout agian source code. it's fixed now.... Thanks, it works fine again. :-) -- Frank _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Gilles Caulier-4
Dnia czwartek 05 kwiecień 2007, Gilles Caulier napisał:
> Mikolaj, > > Look my commit #650706 : > > http://websvn.kde.org/trunk/extragear/graphics/digikam/utilities/imageed >itor/canvas/canvas.cpp?revision=650706&view=markup > > I don't know why KDE mail server claim than it cannot sent the mail to > your mail box... Don't know why too. :( Thanks for this improvement :) m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Gilles Caulier-4
Dnia czwartek 05 kwiecień 2007, Gilles Caulier napisał:
> Not all : Red Eyes, Inpainting, and RainDrops > > But extend to all is not a problem. Best candidate are : Blur, > Sharpen/Unsharp/Refocus. Levels, Curves, Mixer. > Will it be possible? > > yes Thanks. m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Bugzilla from mikmach@wp.pl
> However, I think it would be nice if the time for "Loading ..." > would be shorter (even on a Core 2 Duo with 2 GHz and 2 GB RAM > it is about 1s to go from one image to the next). > This is also true when going back-and-forth between two images > (wasn't there some caching supposed to be active?) Yes there is caching. Going back to the previous image is fast here. There is no preloading currently in the editor - it is not enabled. Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
2007/4/6, Marcel Wiesweg <[hidden email]>:
And I would just said one word about my experimental implementation here : Since i have works hard into canvas implementation, especially to speedup rendering of image, I have used editor canvas to render preview image on Preview Mode from Album GUI. It work nice. Now we can zoom in zoom out into preview. It's fast. This way will solve this B.K.O file : http://bugs.kde.org/show_bug.cgi?id=140131 And Marcel, what news about this one : http://bugs.kde.org/show_bug.cgi?id=132047 It's can be closed ? Also, to give an easy comparing tool, Canvas will be the best solution : http://bugs.kde.org/show_bug.cgi?id=135048 It's easy to do : two canvas instance on the same QMainWindow, with scroollin synchronized... Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
Dnia piątek 06 kwiecień 2007, Gilles Caulier napisał:
> > Also, to give an easy comparing tool, Canvas will be the best solution : > > http://bugs.kde.org/show_bug.cgi?id=135048 > > It's easy to do : two canvas instance on the same QMainWindow, with > scroollin synchronized... > Why limit of two? :) My cast: when selecting many files in album add option to context menu: "Compare images" and open IE with construction mentioned above but not limited to two. m. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
In reply to this post by Gilles Caulier-4
> 2007/4/6, Marcel Wiesweg <[hidden email]>:
> > > However, I think it would be nice if the time for "Loading ..." > > > would be shorter (even on a Core 2 Duo with 2 GHz and 2 GB RAM > > > it is about 1s to go from one image to the next). > > > This is also true when going back-and-forth between two images > > > (wasn't there some caching supposed to be active?) > > > > Yes there is caching. Going back to the previous image is fast here. > > There is no preloading currently in the editor - it is not enabled. > > > > Marcel > > And I would just said one word about my experimental implementation here : > > Since i have works hard into canvas implementation, especially to speedup > rendering of image, I have used editor canvas to render preview image on > Preview Mode from Album GUI. It work nice. Now we can zoom in zoom out into > preview. It's fast. This way will solve this B.K.O file : > > http://bugs.kde.org/show_bug.cgi?id=140131 Do you need DImg objects from the preview then? This way, we could also experiment with faster scaling algorithms. Problem is loading from memory. If necessary, we still need to load using a QImage, it supports loading from memory... > > And Marcel, what news about this one : > > http://bugs.kde.org/show_bug.cgi?id=132047 > > It's can be closed ? Yes, there is nothing I can think of right now that we have left to implement to make loading faster. > > Also, to give an easy comparing tool, Canvas will be the best solution : > > http://bugs.kde.org/show_bug.cgi?id=135048 > > It's easy to do : two canvas instance on the same QMainWindow, with > scroollin synchronized... > > Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Re: extragear/graphics/digikam/uti
|
|
2007/4/6, Marcel Wiesweg <[hidden email]>:
> 2007/4/6, Marcel Wiesweg <[hidden email]>: no, and if you take a look in my patch, i don't use it. Preveiw loading still used... This way, we could also Tested. It's work. It's more faster than QImage::smothScale() but similar than QImage::scale(). Backport is here : http://digikam3rdparty.free.fr/misc.tarballs/smooth-bresenham/ of course result is smothed with this algo insteas QImage::scale() is not... Problem is loading from memory. If necessary, we still need to load using a Ok, i close it... 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 |