feature: shrink factor

[Uncle808]

I've seen some thumpnail fuckery (shows text when shrunk by a certain algorithm, enlarged shows something else) that makes me think I'd like to decide the resize factor as exchange for runspeed.

Yes, I know it is required to avoid running out of time counting pixels, but from 75% it should be reducable to 25%~33% instead. For example why, sometimes I have a glowing red room with blue illuminated objects or people on the screen and the lights turns blue instead of red.

[Kakifrucht]

I've had instances in which the colors seemed odd too. If changing the shrink value would make these issues go away than it would be a nice feature to have.

[kershner]

I've been meaning to experiment with the resize factor for a while.

ScreenBloom resizes the image grabbed from the desktop for purely performance reasons, and you could achieve a similar result by not resizing at all and instead just sampling every N number of pixels, stuff like that. Surely there are other ways as well.

I don't think it will produce the results you're thinking it will, though. The "weird" or "unexpected" colors sometimes produced by the ScreenBloom algo will still be evident on any size image, since it's just averaging the pixels from the image. Sometimes the reds of a very red room will be skewed blue by the presence of a lot of random blue in the image, etc.

However it'd be awesome to get a lot more data about it. I'll be doing some of my own testing whenever there is time but if you want to get your hands dirty it's a pretty easy thing to tweak: https://github.com/kershner/screenBloom/blob/master/app/modules/img_proc.py#L84

There the image is being resized down to 16x9. Let me know if you make any discoveries!

[Uncle808]

I've been meaning to ask, watching an electric light orchestra performance that turned the lights to glaring white despite the video being a black room performance with primarily blue illuminated costumes - do you do anything with black colored pixels?

If not, that'd explain why bloom sets the light to an really uncomfortable blueish-white hue when my black desktop background is displayed

[kershner]

Yeah both extremely dark and extremely light are not counted toward the color average, but instead used to produce a scaled brightness value.

Hues are not capable of producing a "black" color. It's also not feasible to turn the lights full off and on again during ScreenBloom's extremely fast loop.

The way these issues are addressed is to use the scaled brightness value to dim your lights if the overall screen image is very dark. If your lights aren't dimming like you think they should (sounds like it), then either your global minimum brightness, or the minimum brightness for your individual selected bulbs is set to a high value. If you set it to 0 you'll see the full range of brightness.