Bug 469184 - 23.04 version lost "blur factor" feature
Summary: 23.04 version lost "blur factor" feature
Status: RESOLVED FIXED
Alias: None
Product: Spectacle
Classification: Applications
Component: General (show other bugs)
Version: 23.04.0
Platform: Arch Linux Linux
: NOR minor
Target Milestone: ---
Assignee: Noah Davis
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2023-04-30 09:57 UTC by Daniel
Modified: 2024-04-19 06:38 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 24.05


Attachments
Example of effect of using different blur factors + use of the number thingy (427.39 KB, image/jpeg)
2023-04-30 09:57 UTC, Daniel
Details
viewer window number count (12.17 KB, image/png)
2023-04-30 18:50 UTC, Noah Davis
Details
rectangle capture number count (15.95 KB, image/png)
2023-04-30 18:50 UTC, Noah Davis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel 2023-04-30 09:57:44 UTC
Created attachment 158560 [details]
Example of effect of using different blur factors + use of the number thingy

SUMMARY
Previously available settings like changing Blur Factor or changing count for the number thingy are no longer available


STEPS TO REPRODUCE
1. Take a rectangular area screenshot
2. Show Annotation Tools
3. Blur, Pixelate or use the number thingy

OBSERVED RESULT
Cant select blur factor, can't change count

EXPECTED RESULT
Settings for the tools like older versions or Gwenview

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9
Kernel Version: 6.2.12-arch1-1 (64-bit)
Comment 1 Noah Davis 2023-04-30 18:50:08 UTC
Created attachment 158573 [details]
viewer window number count

You can still change the number count.
Comment 2 Noah Davis 2023-04-30 18:50:31 UTC
Created attachment 158574 [details]
rectangle capture number count
Comment 3 Nate Graham 2023-05-02 17:48:41 UTC
Indeed. And I'm not sure it's worth re-adding the "blur factor" feature. Seems like quite niche, and you can just draw a blur area on top of an existing blurred area to make it blurrier. That's what I do. I think it's your call, Noah.
Comment 4 Daniel 2023-05-02 18:13:27 UTC
Not sure how I missed the number count selector

The blur factor though would be pretty important, especially as pixelating multiple times does not change anything and with blurring it's just annoying to have to do this

I usually use this to pixelate number plates, I find that the pixelate tool looks nicer, but now I can't use it for bigger number plates, as they will still be readable.
Comment 5 Noah Davis 2023-05-02 18:45:04 UTC
(In reply to Nate Graham from comment #3)
> Indeed. And I'm not sure it's worth re-adding the "blur factor" feature.
> Seems like quite niche, and you can just draw a blur area on top of an
> existing blurred area to make it blurrier. That's what I do. I think it's
> your call, Noah.

It being pretty niche was my first thought, but needing larger pixel blocks/blur factors for screenshots of higher resolution images is a good point, plus there are literally no other options for these tools. The annotation options toolbar in the viewer window is just blank for them.
Comment 6 Nate Graham 2023-05-05 09:17:09 UTC
> needing larger pixel blocks/blur factors for screenshots of higher resolution images is a good point
That's not a thing that should need to be configured; we should automatically scale the blur radius/factor/etc/whatever when using scaling.
Comment 7 Noah Davis 2023-05-05 09:26:21 UTC
(In reply to Nate Graham from comment #6)
> > needing larger pixel blocks/blur factors for screenshots of higher resolution images is a good point
> That's not a thing that should need to be configured; we should
> automatically scale the blur radius/factor/etc/whatever when using scaling.

This is a separate issue. Imagine you have some very large text that you need to censor on a screen with 1x scaling. Regardless of what your UI scale is, the blur or pixelate effects may not be powerful enough to properly obscure it if the content is large to begin with.
Comment 8 Nate Graham 2023-05-05 11:11:32 UTC
I guess that makes sense, but would adjusting the blur factor really be easier or more intuitive than just drawing multiple blur rectangles on top of one another? That's what I currently do.
Comment 9 Noah Davis 2023-05-05 11:38:33 UTC
(In reply to Nate Graham from comment #8)
> I guess that makes sense, but would adjusting the blur factor really be
> easier or more intuitive than just drawing multiple blur rectangles on top
> of one another? That's what I currently do.

If you want the blur effect to look neat, you'd need to perfectly draw multiple blur rectangles over the same spot. That would be very tedious.

As for the pixelate effect, there is no way to apply multiple levels of pixelation the way you can with blur. The lack of ability to layer pixelate effects is currently semi-intentional because the current implementation makes it easy to draw pixelate effects efficiently and without the pixels moving around as you expand the rectangular area of the pixelate effect.
Comment 10 nazDridoy 2024-02-17 14:18:16 UTC
This is probably the only reason (missing 'blur factor') why I can't use Spectacle.
Comment 11 Bug Janitor Service 2024-04-11 07:57:22 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/344
Comment 12 Noah Davis 2024-04-18 22:34:14 UTC
Git commit e19222a86627c8ba5678e3d0c505a59bbe810212 by Noah Davis.
Committed on 18/04/2024 at 22:31.
Pushed by ndavis into branch 'master'.

Add blur/pixelate strength settings and slider for adjusting them

The strength values are floating point numbers that go from 0 to 1, like percents.
I chose to make them like percents instead of a scale factor for the pixelate effect
and a standard deviation (sigma) for the blur effect for the following reasons:

- Making the settings match the internal values used would make them too dependent on the implementation.
- It would be hard to explain how the values work to users.
- It would be harder to represent the settings in the UI in a reusable way.

I chose a slider instead of a spinbox for the following reasons:

- 0% in a spinbox would imply no effect, but no effect would be useless.
- The minimum position of a slider only implies the minimum value, making it more semantically flexible.
- The exact values aren't very meaningful, so there's no need to type an exact percent.
- Sliders are a bit easier to interact with than spinboxes.
- There was plenty of space.

M  +58   -19   src/Gui/AnnotationOptionsToolBarContents.qml
M  +39   -2    src/Gui/Annotations/AnnotationDocument.cpp
M  +5    -0    src/Gui/Annotations/AnnotationDocument.h
M  +68   -0    src/Gui/Annotations/AnnotationTool.cpp
M  +15   -4    src/Gui/Annotations/AnnotationTool.h
M  +91   -54   src/Gui/Annotations/Traits.cpp
M  +24   -16   src/Gui/Annotations/Traits.h
M  +13   -0    src/Gui/SettingsDialog/spectacle.kcfg

https://invent.kde.org/graphics/spectacle/-/commit/e19222a86627c8ba5678e3d0c505a59bbe810212