It is currently September 23rd, 2020, 3:01 pm

Plugin: Chameleon

Plugins and Addons popular with the Community
User avatar
Cariboudjan
Posts: 93
Joined: May 12th, 2019, 8:55 am

Re: Plugin: Chameleon

Post by Cariboudjan »

The next update will get support for some command line arguments to control the program while it's running and I think I could also add some query commands.

The way that this would work is that you specify a window handle which will receive the response via WM_COPYDATA. So one of them could return the current wallpapers in JSON format from which you could get the path to the project and preview files to read.
One of the WPE devs has been chatting, and he's figuring out a way to get this working.

https://steamcommunity.com/app/431960/discussions/0/1697221160916833027/

Rainmeter should be able to control WPE through commandline, and also get color data via a preview image. Chameleon should be able to use the preview image to get the data. I'll create a test skin as soon as the update comes out.
User avatar
Socks the Fox
Posts: 99
Joined: August 25th, 2015, 6:40 pm

Re: Plugin: Chameleon

Post by Socks the Fox »

Well... I have an initial build of Chameleon that samples the desktop directly instead of going through the image file, but...

It's after all the icons and windows and everything gets drawn on top of the background. Not before, like I was hoping it would be. I'm going to go back and keep researching on it, I'm *sure* there's a way to get the data I need. Could be a neat option though.

All I can say is Windows does NOT make it easy to read the contents of a window into a simple to use data format. It insists on having me copy the entire desktop "window" contents to a device-specific buffer, then use another function to convert it to a device independent format in another buffer, and even that still has the possibility probability to be in a format that doesn't play nice with the rest of the plugin (the plugin is coded to expect 8-bit-per-channel RGBA, windows likes to pass back 8-bit-per-channel BGRx, or possibly 5-bit RGB, or maybe just 8-bit BGR, and it's not impossible for it to decide to give back 5-6-5-bit RGB).

Anyway, once I've gotten that working it should be super easy to then grab a subsection of that image and get the brightness of the area under the skin.

EDIT: Oh of course after I post this I find it's literally just "call GetShellWindow() instead of GetDesktopWindow()" haha.

Well, I still need to fix a few things but at least now it's only looking at the background.
Author of Chameleon :: Like my plugin? Consider donating! I don't need much :3
User avatar
Socks the Fox
Posts: 99
Joined: August 25th, 2015, 6:40 pm

Re: Plugin: Chameleon

Post by Socks the Fox »

Okay! Chameleon v1.6 is out now! This release
  • Fixes the issue where the Crop values don't update
  • Samples the shell desktop window directly, so Chameleon sees what you see
  • Enables Chameleon to shuffle the colors to better match the area of the desktop the skin covers (which is enabled by default but has a measure value to disable it, by setting ContextAwareColors=0)
It will resample the image every time the cropping values change; or if you have context aware colors enabled, after the user stops moving the skin for at least one update cycle (as well as if the image file changes such as moving between desktops).

There may be some little issues here and there, as I had to change a lot of things to get the new features and methods of doing things to fit in, but hopefully they should be few and far between, and generally easy fixes.

The download is available at https://software.socksthefox.net/chameleon/ inside the provided .rmskin as usual.

Possible To Do List:
Probably give a value to tell if ContextAwareColors would have changed things around if it's disabled.
** Rework how the internal Chameleon library chooses and presents colors to allow more color selections. **
Allow ContextAwareColors to use a custom position/size instead of only the skin windows'.
Author of Chameleon :: Like my plugin? Consider donating! I don't need much :3
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin: Chameleon

Post by jsmorley »

Wow... This is a VAST improvement!
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin: Chameleon

Post by jsmorley »

A skin like this:

Code: Select all

[Rainmeter]
Update=100
DynamicWindowSize=1
AccurateText=1

[Variables]

[ChameleonDesktop]
Measure=Plugin
Plugin=Chameleon
Type=Desktop
CropX=#CURRENTCONFIGX#
CropY=#CURRENTCONFIGY#
CropW=#CURRENTCONFIGWIDTH#
CropH=#CURRENTCONFIGHEIGHT#
DynamicVariables=1

[Background1]
Measure=Plugin
Plugin=Chameleon
Parent=ChameleonDesktop
Format=Dec
Color=Background1

[Foreground1]
Measure=Plugin
Plugin=Chameleon
Parent=ChameleonDesktop
Format=Dec
Color=Foreground1

[Luminance]
Measure=Plugin
Plugin=Chameleon
Parent=ChameleonDesktop
Format=Dec
Color=Luminance

[MeterBackground]
Meter=Image
W=140
H=140
SolidColor=[Background1]
DynamicVariables=1

[MeterForeground]
Meter=Image
X=20
Y=20
W=100
H=100
SolidColor=[Foreground1]
DynamicVariables=1

[MeterLumin]
Meter=String
MeasureName=Luminance
X=70
Y=70
StringAlign=CenterCenter
NumOfDecimals=5
FontSize=12
FontWeight=400
FontColor=[Foreground1]
SolidColor=[Background1]
Padding=5,5,5,5
AntiAlias=1
DynamicVariables=1

Will work really well on the primary monitor, but won't do so well if dragged to a second monitor. The skin position/size variables in Rainmeter are based on a "virtual screen" combining both monitor values, and I suspect that your measurements are based on each monitor being a distinct entity.

Starts spewing out "Cropping out of bounds of image! Check your parameters." errors in the log, and I gather just falls back to not using cropping.

I guess this is how it must be, or at least probably should be for the image-based "Crop" to work right. I'll have to chew on some calculations to turn Rainmeter's "virtual screen" values into distinct values by monitor for position. Perhaps you could create a Debug=1 option that spits out what measurements it is using for the image(s) and the cropping in the log. That would help with figuring out what static values to change to for the cropping on a second monitor. This is more complicated to just "guesstimate" if the two monitors are not the same size and resolution.

It's remarkable how well it works on the primary monitor though. I love how it automatically adjusts to where on the desktop background you drag the skin. This plugin is like magic...
User avatar
Socks the Fox
Posts: 99
Joined: August 25th, 2015, 6:40 pm

Re: Plugin: Chameleon

Post by Socks the Fox »

I was originally going to preprocess the crop values since I already have to do that for when figuring out where the skin is on the virtual monitor/desktop for the background matching, but I realized that things get complicated when it comes to what the user actually wants vs what I make available. Right now if you specify a cropping value for a desktop measure it reverts to cropping and sampling based on the original image file, but I was considering changing it to either base it off the monitor desktop (with preprocessing the cropping values), or the overall desktop (i.e. what Windows gives you when you use the Print Screen key; would not require changing the cropping values but also might give odd colors for cropping that goes out of a specific monitor's boundary but still within the virtual desktop).
Author of Chameleon :: Like my plugin? Consider donating! I don't need much :3
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin: Chameleon

Post by jsmorley »

Socks the Fox wrote: December 15th, 2019, 6:26 pm I was originally going to preprocess the crop values since I already have to do that for when figuring out where the skin is on the virtual monitor/desktop for the background matching, but I realized that things get complicated when it comes to what the user actually wants vs what I make available. Right now if you specify a cropping value for a desktop measure it reverts to cropping and sampling based on the original image file, but I was considering changing it to either base it off the monitor desktop (with preprocessing the cropping values), or the overall desktop (i.e. what Windows gives you when you use the Print Screen key; would not require changing the cropping values but also might give odd colors for cropping that goes out of a specific monitor's boundary but still within the virtual desktop).
When used with "Desktop", I'm not sure Crop is of all that much value if based on the original image file. Since you are almost certainly going to be using "Fit" with the desktop, the wallpaper image very often isn't going to line up with what is displayed on the screen.

I don't know what the complexities are, although I'm sure they are significant, but it seems to me that from a user point of view the logical thing is that Crop is based on what is being displayed in the context of the monitor the skin is on. That seems to be to be the only hope anyone has of using the Luminance function to determine what the lightness / darkness of a particular area under the skin is, so you can use that to determine which of the foreground and background colors to use.

What I would likely do is to use two Chameleon "Desktop" parent measures. The first one would be the entire monitor contents, and that would be used with several child measures to select the colors, based on the entirety of the colors on the screen. I wouldn't want to limit this to just what is under the skin, as depending on the size, that might end up pretty boring in the context of the entire screen. The second would be a parent measure that is "cropped" to the size and position of the skin. That would be used with just one child measure to get the Luminance of this particular area. Then I would use IfConditions on this child to determine if a "light" or "dark" color scheme is best for the skin, at THIS place on the wallpaper. Since Luminance is based on a double value from 0.0-1.0, anything 0.49999 or less is tending toward "dark" and anything from 0.5 to 1.0 is tending toward "light". It's not quite that simple, since anything about 0.4 to 0.6 is really not either dark or light, but it gives you your best shot at it.


1.png

With this example, I have the skin on my primary monitor, which is 1920 x 1080, and the image is 1920 x 1080, so the "Crop" is able to figure things out pretty well when I use the approach I outlined above. This won't be true when I move the skin to my second monitor, which is 1600 x 900, but is still using the same wallpaper image with "Fit".
You do not have the required permissions to view the files attached to this post.
User avatar
Socks the Fox
Posts: 99
Joined: August 25th, 2015, 6:40 pm

Re: Plugin: Chameleon

Post by Socks the Fox »

Okay, I think what I'll do is release 1.6.1 so that cropping on a desktop measure will apply to the overall virtual monitor so that cropping coordinates will work like one would expect without having to math it out manually. Cropping bounds that go off screen but are still within the bounds of the virtual monitor will end up getting filled with black rather than limited to the screen size (because that's what Windows gives for those areas) but that's on the skin maker because anything more will make things more complicated than I want.

It will however allow a skin maker to force Chameleon to read from multiple screens at once if they play their cards right (and the user's monitor arrangement allows)...

Hopefully I'll get that up in the next few days or so.
Author of Chameleon :: Like my plugin? Consider donating! I don't need much :3
User avatar
jsmorley
Developer
Posts: 21386
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin: Chameleon

Post by jsmorley »

That sounds about right!

I think if a skin author uses #CURRENCONFIGX# / #CURRENTCONFIGHEIGHT# and such, there should be no way get get outside the bounds of the virtual screen, assuming the entire skin stays on the monitors. This would be an issue of height more than width in any case, as a second monitor can be smaller than the first or visa versa.
User avatar
Socks the Fox
Posts: 99
Joined: August 25th, 2015, 6:40 pm

Re: Plugin: Chameleon

Post by Socks the Fox »

Whew, almost done! I'll admit I got a little distracted, but other than that it's just about ready. I want to streamline the code a little bit, and then I have some additional config stuff I want to add regarding the context aware colors (namely, being able to set an area other than the actual skin area to avoid adjacent skins having wildly different colors simply because of where they are) and then it'll be ready!

Other than fixing the cropping oddity I did find a minor mistake when trying to release resources that I fixed for this release. I don't think it'll be a huge issue for 1.6.0 users since I'm pretty sure Windows already accounts for these kinds of errors (supplying the wrong window handle when trying to release a device context handle) but I fixed it for 1.6.1 so it's all moot anyway.
Author of Chameleon :: Like my plugin? Consider donating! I don't need much :3