Version: 1.6.0 (using KDE KDE 3.5.5) Installed from: Fedora RPMs OS: Linux Load an image. Deselect all. Make a rectangular selection. Pick Filter -> Blur -> Blur.... Hit 'OK'. Notice that no blur is applied. If you add to the selection and then Blur -> Blur... it works.

Curious -- I cannot reproduce this, but then, I have trouble at the second step: when I load an image there is no selection active, so I cannot deselect. I'll investigate further. Thanks for your bug report!

I can't reproduce either, but on the other hand, I have made quiet a few changes to the convolution code since 1.6 was released.

Ah, that will be it. Karl, could you retest with 1.6.1 once that goes into beta?

I installed the x86_64 version of 1.6.0 on Fedora 4 and I don't have any problems. It was definitly *not* working correctly on my Fedora 6 machine at work.

Weird, can you give us your Qt version for both machine ? It try on FC4 and I confirm that it works here, I will try on FC5 tomorrow at work to see if it works there.

I tryed on FC5, which confirm that it is a FC6 bug. As there is nothing we can do about it, I close the bug as INVALID, and strongly suggest you to report it to Fedora Core.

So quick to foist the problem onto others, eh? I sincerely doubt the Fedora people could solve what is certain to be a Krita/Qt bug. After some more experimentation it seems the problem only occurs when I load a PNG file with an alpha channel. It happens on both FC4 & FC6. Often I can simply load the file, make a selection, pick Blur..., and hit OK. The problem is intermittent, but by repeatedly making a clean selection (deselect, select region) hopefully you will see the problem.

Sorry to seems to quicly dismiss the problems into others, but so far the description of the problem looked like it was a fedora problem, and it wouldn't be the first time that a qt patched by a distribution cause weird problems in krita. Hum, I still can't reproduce, but until 1.6.1 krita wasn't convolving the alpha channel when bluring, so maybe it is what you see wrong ?

It is logically impossible that the file type has anything to do with this bug happening, since there is no difference anymore internally once a file is loaded. Despite having spent considerable time trying to reproduce your issue, I have never seen it happen. Some quick questions: do you see the blur happen in the preview dialog? Does this ever happen with other filters? (Btw, please do not reopen bugs that application developers or maintainers have closed.)

The preview is blurred (though the entire image is blurred, not just the selection). The other filters seem to work fine. I'll be installing Kubuntu soon and can try it there.

Alright folks, I am running Kubuntu 6.10 now and the blur function still does not work reliably. My test image is a 48x48 icon with transparency. I've spent enough time with this bug. I would really like to ditch GIMP, but Krita continues to be a bug-ridden mess. I wish you better luck with your next release.

Ha! With a small image, I can reproduce this. (Also, I can get a crash if I turn up the radius with the scroll wheel (ie, very fast). Its the famous assert in ~KisTile, though, which is not too helpful. #5 0xb7c85a97 in raise () from /lib/tls/libc.so.6 #6 0xb7c87329 in abort () from /lib/tls/libc.so.6 #7 0xb7c7f006 in __assert_fail () from /lib/tls/libc.so.6 #8 0xb5f14c4b in ~KisTile (this=0x8929938) at /home/boud/koffice/1.6/koffice/krita/core/tiles/kis_tile.cc:97 #9 0xb5f16cc3 in KisMemento::deleteAll (this=0x8a39ca0, tile=0x0) at /home/boud/koffice/1.6/koffice/krita/core/tiles/kis_memento.cc:86 #10 0xb5f16d45 in ~KisMemento (this=0x8a39ca0) at /home/boud/koffice/1.6/koffice/krita/core/tiles/kis_memento.cc:48 #11 0xb5ef34f0 in ~KisTransaction (this=0xbf9009d4) at ksharedptr.h:68 #12 0xb6029eee in KisFilterManager::refreshPreview (this=0x87dee68) at /home/boud/koffice/1.6/koffice/krita/ui/kis_filter_manager.cc:409 #13 0xb6029fd9 in KisFilterManager::slotConfigChanged (this=0x87dee68) at /home/boud/koffice/1.6/koffice/krita/ui/kis_filter_manager.cc:388 #14 0xb602ad89 in KisFilterManager::qt_invoke (this=0x87dee68, _id=3, _o=0xbf900adc) at kis_filter_manager.moc:92 #15 0xb71cc051 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #16 0xb71ccaec in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #17 0xb5eb1736 in KisFilterConfigWidget::sigPleaseUpdatePreview ( this=0x8da2c30) at kis_filter_config_widget.moc:82 #18 0xb51ecd38 in KisWdgBlur::spinBoxHalfHeightChanged (this=0x8da2c30, v=0) at /home/boud/koffice/1.6/koffice/krita/plugins/filters/blur/kis_wdg_blur.cc:111 #19 0xb51ed263 in KisWdgBlur::qt_invoke (this=0x8da2c30, _id=48, _o=0xbf900c08) at kis_wdg_blur.moc:97 #20 0xb71cc17e in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #21 0xb71cc960 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #22 0xb6be9856 in KIntNumInput::valueChanged () from /usr/lib/libkdeui.so.4 #23 0xb6be989b in KIntNumInput::spinValueChanged () from /usr/lib/libkdeui.so.4

SVN commit 603215 by rempt: Fix the layout of a preferences panel, remove spurious includes, fix the layout of the blur filter and fix bug 136685. (I'll be checking Krita for similar bugs, I'm sure there are other places where we use selection->extent or selection->exactBounds where we should use selection->selectedRect.) Funny, though, that I couldn't reproduce 136685 on an image larger than a single tile. BUG: 136685   M +5 -5 core/kis_convolution_painter.cc M +0 -3 core/kis_strategy_move.cc M +90 -141 plugins/filters/blur/wdgblur.ui M +0 -1 ui/kis_controlframe.cc M +0 -1 ui/kis_controlframe.h M +0 -1 ui/kis_filters_listview.h M +159 -187 ui/wdgcolorsettings.ui