Summary: | magic wand selection is broken for 16 bit/integer images | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | kalia24 |
Component: | Tools | Assignee: | Dmitry Kazakov <dimula73> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | halla, kwadraatnope |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Microsoft Windows | ||
OS: | Microsoft Windows | ||
URL: | http://i60.tinypic.com/2dljazm.png | ||
Latest Commit: | http://commits.kde.org/calligra/d6b43848e24a833304e4670d3212a1ce4cfc34ff | Version Fixed In: | |
Sentry Crash Report: |
Description
kalia24
2015-01-27 11:40:30 UTC
Could you attach your original .kra file for me to play with? (In reply to Boudewijn Rempt from comment #1) > Could you attach your original .kra file for me to play with? Sent via mail. Okay, something weird is going on. I've checked in Photoshop CS2, and if you limit the magic wand to the current layer, you won't get a nice, sharp selection either, for that you need to sample all layers. If you enable that in krita, you get the same result as in photoshop. With sampling only the current layer, photoshop definitely has a kind of fringe around the yellow image. Interesting, too, is that the blue background is a bit transparent after converting to psd, but that's another thing. If I convert your image to 8 bit/channel, I get the same result as with magic wand/limit to current layer as photoshop, which suggests to me that photoshop actually converts the pixels to 8 bits/channel when creating a selection, which means that Krita might just be more accurate. Okay, I can also confirm that 2.8 doesn't have the problem, so it's a regression. (In reply to Boudewijn Rempt from comment #3) > Interesting, too, is that the blue background is a bit transparent > after converting to psd, but that's another thing. That's my fault when making the image in fact - I didn't look at the set-up of new image and for some reasons default for me was 90% opacity for new image background... Realised that when exporting this one after finishing and making new one. Ah, right, I see that in the kra file too, now. I'm now trying to find out when we regressed. Okay, this behaviour was introduced with 12f7d13838da7a02504ff621a7243c9b740520ae "Connect the Scanline Fill algorithm to KisFillPainter" -- though at that exact commit, I cannot reproduce the bug because the algorithm gave an error: Error FATAL: The backward interval cannot fully reside inside the forward interval sending event 2 to object *** Bug 343285 has been marked as a duplicate of this bug. *** Reproduced it. The fix will be tomorrow. Git commit d6b43848e24a833304e4670d3212a1ce4cfc34ff by Dmitry Kazakov. Committed on 02/02/2015 at 11:24. Pushed by dkazakov into branch 'calligra/2.9'. Fixed flood fill in 16 bit mode Well, 'reinterpret_cast<quint32*>(pixelPtr)' in a templated code was obviously wrong :( M +1 -1 krita/image/floodfill/kis_scanline_fill.cpp M +3 -2 krita/sdk/tests/testutil.h A +- -- krita/ui/tests/data/flood_fill_16bit.kra A +- -- krita/ui/tests/data/selection_manager_test/scanline_16bit_thres_20.png A +- -- krita/ui/tests/data/selection_manager_test/scanline_8bit_thres_20.png M +63 -0 krita/ui/tests/kis_selection_manager_test.cpp M +2 -0 krita/ui/tests/kis_selection_manager_test.h M +5 -4 plugins/colorengines/lcms2/LcmsColorSpace.h http://commits.kde.org/calligra/d6b43848e24a833304e4670d3212a1ce4cfc34ff I'll make a new windows test build now :-) Builds: http://files.kde.org/krita/windows/krita_x64_2.8.91.3.msi http://files.kde.org/krita/windows/krita_x64_2.8.91.3.zip *** Bug 335102 has been marked as a duplicate of this bug. *** |