Speed of new filters
Locked
 
|
Gilles,
Did you notice the speed of the new threaded filters (hsl for instance) ? it seems to me that they are far slower than they used to be. Did the old implementation computed the preview on the downscaled version of the picture ? Julien _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
2010/2/13 Julien Narboux <[hidden email]>:
> Gilles, > > Did you notice the speed of the new threaded filters (hsl for instance) > ? it seems to me that they are far slower than they used to be. > Did the old implementation computed the preview on the downscaled > version of the picture ? yes, it is. This is relevant of imageguidewidget to imageregionwidget port. If you fit to window preview with imageregionwidget as imageguidewidget do, you compute on whole image. Imageguidewidget use a downscaled version of preview, in fact the screen size of widget. This is why it's very fast. But of course zoom/pan is not possible here. Note : with imageregionwidget, the computation is done on visible preview area, not always on whole image. If you zoom down on, the computation will be done on visible part of image. In this case it's fast. Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Another comment : The histogram on the top right side is computed with
image area data visibile on preview. In case of you zoom to fit, whole image data are used. See this entry for details : https://bugs.kde.org/show_bug.cgi?id=163286 Gilles Caulier 2010/2/13 Gilles Caulier <[hidden email]>: > 2010/2/13 Julien Narboux <[hidden email]>: >> Gilles, >> >> Did you notice the speed of the new threaded filters (hsl for instance) >> ? it seems to me that they are far slower than they used to be. >> Did the old implementation computed the preview on the downscaled >> version of the picture ? > > yes, it is. This is relevant of imageguidewidget to imageregionwidget > port. If you fit to window preview with imageregionwidget as > imageguidewidget do, you compute on whole image. > > Imageguidewidget use a downscaled version of preview, in fact the > screen size of widget. This is why it's very fast. But of course > zoom/pan is not possible here. > > Note : with imageregionwidget, the computation is done on visible > preview area, not always on whole image. If you zoom down on, the > computation will be done on visible part of image. In this case it's > fast. > > Gilles > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Gilles Caulier-4
Gilles Caulier a écrit :
> 2010/2/13 Julien Narboux <[hidden email]>: > >> Gilles, >> >> Did you notice the speed of the new threaded filters (hsl for instance) >> ? it seems to me that they are far slower than they used to be. >> Did the old implementation computed the preview on the downscaled >> version of the picture ? >> > > yes, it is. This is relevant of imageguidewidget to imageregionwidget > port. If you fit to window preview with imageregionwidget as > imageguidewidget do, you compute on whole image. > > Imageguidewidget use a downscaled version of preview, in fact the > screen size of widget. This is why it's very fast. But of course > zoom/pan is not possible here. > > Note : with imageregionwidget, the computation is done on visible > preview area, not always on whole image. If you zoom down on, the > computation will be done on visible part of image. In this case it's > fast Ok Gilles I understand why it is slower. It would be nice if imageregionwidget had an option such that the preview is computed on the visible image (the downscaled version). Indeed for many filter f, downscale (f (image) ) ~= f (downscale (image)). I think this would work for all filters which operate locally on pixels. I did it "by hand" for the vignetting effect but it would be better to factorize that in the imageregionwidget. Julien _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
The solution is to pass a downscaled version here :
http://lxr.kde.org/source/extragear/graphics/digikam/utilities/imageeditor/widgets/imageregionwidget.cpp#84 as 1/4 size is the usual way: Dimg* img = d->iface->getOriginalImg(); d->image = img->copy().smoothScale(img->with()/4, img->height()/4, Qt::KeepAspectRatio) The problem now is about zoom and 1:1 level which is now 100% zoom of course. Some code need to be added in EditorToolsIface to adapt zoom tools from status bar. But in theory, it must work as well, especially to test speed. Let's me hear if 1/4 version is fine. Gilles 2010/2/13 Julien Narboux <[hidden email]>: > Gilles Caulier a écrit : >> 2010/2/13 Julien Narboux <[hidden email]>: >> >>> Gilles, >>> >>> Did you notice the speed of the new threaded filters (hsl for instance) >>> ? it seems to me that they are far slower than they used to be. >>> Did the old implementation computed the preview on the downscaled >>> version of the picture ? >>> >> >> yes, it is. This is relevant of imageguidewidget to imageregionwidget >> port. If you fit to window preview with imageregionwidget as >> imageguidewidget do, you compute on whole image. >> >> Imageguidewidget use a downscaled version of preview, in fact the >> screen size of widget. This is why it's very fast. But of course >> zoom/pan is not possible here. >> >> Note : with imageregionwidget, the computation is done on visible >> preview area, not always on whole image. If you zoom down on, the >> computation will be done on visible part of image. In this case it's >> fast > > Ok Gilles I understand why it is slower. > It would be nice if imageregionwidget had an option such that the > preview is computed on the visible image (the downscaled version). > Indeed for many filter f, downscale (f (image) ) ~= f (downscale (image)). > I think this would work for all filters which operate locally on pixels. > I did it "by hand" for the vignetting effect but it would be better to > factorize that in the imageregionwidget. > > > Julien > _______________________________________________ > 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 |
|
|
I implemented it differently, not using 1/4 size but using screen size,
adding an option to the getImageRegion. I seems to work as expected. Julien Gilles Caulier a écrit : > The solution is to pass a downscaled version here : > > http://lxr.kde.org/source/extragear/graphics/digikam/utilities/imageeditor/widgets/imageregionwidget.cpp#84 > > as 1/4 size is the usual way: > > > Dimg* img = d->iface->getOriginalImg(); > d->image = img->copy().smoothScale(img->with()/4, img->height()/4, > Qt::KeepAspectRatio) > > The problem now is about zoom and 1:1 level which is now 100% zoom of > course. Some code need to be added in EditorToolsIface to adapt zoom > tools from status bar. > > But in theory, it must work as well, especially to test speed. Let's > me hear if 1/4 version is fine. > > Gilles > > 2010/2/13 Julien Narboux <[hidden email]>: > >> Gilles Caulier a écrit : >> >>> 2010/2/13 Julien Narboux <[hidden email]>: >>> >>> >>>> Gilles, >>>> >>>> Did you notice the speed of the new threaded filters (hsl for instance) >>>> ? it seems to me that they are far slower than they used to be. >>>> Did the old implementation computed the preview on the downscaled >>>> version of the picture ? >>>> >>>> >>> yes, it is. This is relevant of imageguidewidget to imageregionwidget >>> port. If you fit to window preview with imageregionwidget as >>> imageguidewidget do, you compute on whole image. >>> >>> Imageguidewidget use a downscaled version of preview, in fact the >>> screen size of widget. This is why it's very fast. But of course >>> zoom/pan is not possible here. >>> >>> Note : with imageregionwidget, the computation is done on visible >>> preview area, not always on whole image. If you zoom down on, the >>> computation will be done on visible part of image. In this case it's >>> fast >>> >> Ok Gilles I understand why it is slower. >> It would be nice if imageregionwidget had an option such that the >> preview is computed on the visible image (the downscaled version). >> Indeed for many filter f, downscale (f (image) ) ~= f (downscale (image)). >> I think this would work for all filters which operate locally on pixels. >> I did it "by hand" for the vignetting effect but it would be better to >> factorize that in the imageregionwidget. >> >> >> Julien >> _______________________________________________ >> 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 > _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Yes, but i think it's not enough. It option is enable, and you zoom
in, when you back in editor canvas, you must zoom/pan at the same place than preview widget (without this option this is done in fact) Also, the zoom factor on zoom tool from status bar is wrong. Go to 100% and compare with editor canvas in the same case : it's not the same result. We must adjust a size ratio in this case to adjust zoom factor, else people will crying again (i fix 2 bugs recently about this problem. I don't know yet the right way to do it (:=))), but use EditorToolIface api must be fine. Gilles 2010/2/14 Julien Narboux <[hidden email]>: > I implemented it differently, not using 1/4 size but using screen size, > adding an option to the getImageRegion. > I seems to work as expected. > > Julien > > Gilles Caulier a écrit : >> The solution is to pass a downscaled version here : >> >> http://lxr.kde.org/source/extragear/graphics/digikam/utilities/imageeditor/widgets/imageregionwidget.cpp#84 >> >> as 1/4 size is the usual way: >> >> >> Dimg* img = d->iface->getOriginalImg(); >> d->image = img->copy().smoothScale(img->with()/4, img->height()/4, >> Qt::KeepAspectRatio) >> >> The problem now is about zoom and 1:1 level which is now 100% zoom of >> course. Some code need to be added in EditorToolsIface to adapt zoom >> tools from status bar. >> >> But in theory, it must work as well, especially to test speed. Let's >> me hear if 1/4 version is fine. >> >> Gilles >> >> 2010/2/13 Julien Narboux <[hidden email]>: >> >>> Gilles Caulier a écrit : >>> >>>> 2010/2/13 Julien Narboux <[hidden email]>: >>>> >>>> >>>>> Gilles, >>>>> >>>>> Did you notice the speed of the new threaded filters (hsl for instance) >>>>> ? it seems to me that they are far slower than they used to be. >>>>> Did the old implementation computed the preview on the downscaled >>>>> version of the picture ? >>>>> >>>>> >>>> yes, it is. This is relevant of imageguidewidget to imageregionwidget >>>> port. If you fit to window preview with imageregionwidget as >>>> imageguidewidget do, you compute on whole image. >>>> >>>> Imageguidewidget use a downscaled version of preview, in fact the >>>> screen size of widget. This is why it's very fast. But of course >>>> zoom/pan is not possible here. >>>> >>>> Note : with imageregionwidget, the computation is done on visible >>>> preview area, not always on whole image. If you zoom down on, the >>>> computation will be done on visible part of image. In this case it's >>>> fast >>>> >>> Ok Gilles I understand why it is slower. >>> It would be nice if imageregionwidget had an option such that the >>> preview is computed on the visible image (the downscaled version). >>> Indeed for many filter f, downscale (f (image) ) ~= f (downscale (image)). >>> I think this would work for all filters which operate locally on pixels. >>> I did it "by hand" for the vignetting effect but it would be better to >>> factorize that in the imageregionwidget. >>> >>> >>> Julien >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > 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 |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |