Gaussian filter bounds problems

Ed . schumifer at hotmail.com
Mon May 3 12:48:20 CEST 2010


Hi,


I'll reply back regarding the PNG issue when I arrive home.


Regarding the second issue, I know about it. I'm not entirely sure it is caused by the second convolution. 
Try this out:
Use the new motion blur filter with a large Length value and Angle set 90 degrees. You will see the border effect, but as you decrease the angle, the border effect starts vanishing. The motion blur filter only performs a single convolution.

Date: Mon, 3 May 2010 10:28:06 +0400
Subject: Gaussian filter bounds problems
From: dimula73 at gmail.com
To: schumifer at hotmail.com
CC: kimageshop at kde.org

Hi, Edward!

I tried to reproduce the bug with png image bounds today and i failed. Everything seems to work with Blur and Gaussian Blur filters added as masks and adjustment layers. Could you describe  how to reproduce it here?



Btw, i found a bug in Gaussian Blur filter. Try to apply it to an image that is bigger than 512x512 pixels. You get a border effect.
The cause is this code, i think:
 if ( (horizontalRadius > 0) && (verticalRadius > 0) )
    {        KisPaintDeviceSP interm = new KisPaintDevice(src->colorSpace());
        KisConvolutionKernelSP kernelHoriz = KisConvolutionKernel::fromMatrix(horizGaussian, 0, horizGaussian.sum());
        KisConvolutionKernelSP kernelVertical = KisConvolutionKernel::fromMatrix(verticalGaussian, 0, verticalGaussian.sum());
        KisConvolutionPainter horizPainter(interm, dstInfo.selection());
        horizPainter.setChannelFlags(channelFlags);        horizPainter.setProgress(progressUpdater);
        horizPainter.applyMatrix(kernelHoriz, src, srcTopLeft, srcTopLeft, size, BORDER_REPEAT);
        KisConvolutionPainter verticalPainter(dst, dstInfo.selection());        verticalPainter.setChannelFlags(channelFlags);
        verticalPainter.setProgress(progressUpdater);        verticalPainter.applyMatrix(kernelVertical, interm, srcTopLeft, dstTopLeft, size, BORDER_REPEAT);
    }

The problem is, when you convolve the second time, there is no needRect prepared for the convolution. src device has this additional data (it is prepared by walkers), while interm doesn't. I see the only way out in bitBlt'ing src into interm, but this will be very inefficient. Or writing a special RepeatIteratorFactory that might be too complex task...



-- 
Dmitry Kazakov
 		 	   		  
_________________________________________________________________
Hotmail: Trusted email with Microsoft’s powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20100503/8c9b27ef/attachment.htm 


More information about the kimageshop mailing list