Key images are resampled with FilterType::Nearest, discarding their antialiasing

[constrictor]

convert_image_with_format resamples every key image to the device's key size with nearest-neighbour:

https://github.com/OpenActionAPI/rust-elgato-streamdeck/blob/main/src/images.rs#L29

let image = image.resize_exact(ws as u32, hs as u32, FilterType::Nearest);

This discards the antialiasing of whatever the caller drew. On a Stream Deck + the ratio is 144 → 120, i.e. 6:5, so it drops every sixth row and column and point-samples soft edges rather than averaging them. The result on the panel is stair-stepped diagonals, strokes whose width visibly alternates along their length, and small text that turns to mush.

I ran into this writing an OpenDeck plugin that draws its key faces as SVG. Rendering the same source image through the pipeline twice — once with Nearest and once with Lanczos3, everything else identical, including both JPEG passes — the Nearest output matches what my hardware shows, and the Lanczos3 output is clean. Nothing about the artwork changed between the two.

Key images are at most 200×200, so a proper filter is not worth optimising away here:

-    let image = image.resize_exact(ws as u32, hs as u32, FilterType::Nearest);
+    // Nearest-neighbour discards the antialiasing on every key image. At the
+    // Stream Deck +'s 6:5 ratio (144 -> 120) it drops every sixth row and column
+    // and point-samples soft edges into stair-steps.
+    let image = if image.width() == ws as u32 && image.height() == hs as u32 {
+        image
+    } else {
+        image.resize_exact(ws as u32, hs as u32, FilterType::Lanczos3)
+    };

FilterType::Triangle would also be a large improvement if Lanczos3 is considered too heavy. The equality guard keeps the call free for callers that already hand over a correctly-sized image, which is the case worth optimising for.

Happy to open a PR if you'd like it in that shape.

[Terrorwolf01]

May I ask where you get the Number that Key Images are at maximum 200x200? Did you account here for non Elgato Devices too?

[constrictor]

Good catch — that number was sloppy of me, and the second question is the sharper one. Let me correct both.

Where 200×200 came from: nowhere defensible. I eyeballed it as a loose upper bound rather than deriving it. The actual sizes in Kind::key_image_format() are 72×72 (Original, OriginalV2, Mk2, Mk2Scissor, Mk2Module), 80×80 (Mini family), 96×96 (Neo, Xl, XlV2, XlV2Module) and 120×120 (Plus, PlusXl), with Pedal at ImageFormat::default(). So the real ceiling for key images is 120×120.

But that is the wrong bound for this function anyway. convert_image_with_format is public and takes an arbitrary ImageFormat, not just a key format. It is used for LCD strips too — lcd_image_format() goes up to 800×100 (Plus) and 100×1200 (PlusXl), and OpenDeck calls it that way in elgato.rs. Saying "key images" understated the scope of my own patch.

And the cost is driven by the source size, which is unbounded. That is the real version of your concern: the destination is bounded by the format, but a caller can hand over any resolution it likes, and a separable resize scales with source area. Numbers on this machine, image 0.25.10, release build, mean over 200–500 iterations:

case	source → dest	Nearest	Triangle	Lanczos3
Plus key	144×144 → 120×120	133 µs	188 µs	320 µs
Mk2 key	144×144 → 72×72	54 µs	88 µs	182 µs
XL key, large source	512×512 → 96×96	148 µs	597 µs	1507 µs
key, very large source	1024×1024 → 120×120	286 µs	2078 µs	6852 µs
Plus LCD strip	900×112 → 800×100	746 µs	1006 µs	1674 µs
PlusXl LCD	112×1400 → 100×1200	1088 µs	1512 µs	2573 µs

For the case that actually matters — a host rendering at roughly key size — Lanczos3 costs about 190 µs more than Nearest per update. The largest declared format costs 1.5 ms more. The outlier is a large source: 1024×1024 → 120×120 is 24× Nearest, 6.9 ms.

So on the substance of your question: no, I had not accounted for callers outside the sizes this crate's own Kind enum produces, and the patch as written does expose them to a cost that scales with whatever they pass in.

Two things soften it, and one change might be worth making:

• The early-out in the PR means a caller that pre-scales to the target size pays nothing at all, where today it pays for a full nearest resample to get its own pixels back. OpenDeck already pre-scales for the Neo infobar (elgato.rs:58), so that path gets strictly faster.
• Triangle may be the better default. It is ~3.3× cheaper than Lanczos3 on the large-source case and ~1.7× on a typical key. Visually, at the 6:5 ratio that motivated this, the two are nearly indistinguishable — Lanczos3 is a touch crisper on small text, and both are night and day against Nearest, which is the actual problem.

I am happy to switch the PR to Triangle, or to make the filter a parameter with a sensible default if you would rather callers choose. Your call — say which and I will push it.

[nekename]

I reckon that since this is a library potentially consumed by others, we should go with Triangle rather than Lanczos3 since the Stream Deck's displays are small enough that you won't notice the difference, and introducing 7ms of extra latency may make or break some cases.

Adding the check for whether the image is already the correct size is good, too.