Image Library API endpoint

[ChadJeffreyAnderson]

Is this a feature relevant to companion itself, and not a specific module?

• I believe this to be a feature for companion, and is not specific to a module

Is there an existing issue for this?

• I have searched for similiar existing issues

Describe the feature

An API endpoint, e.g. for HTTP /api/image-library/<name>/png64, that gets the named image's png64 string and, more importantly, has a ?png64= parameter that accepts posted strings.

This is related to the remote images discussion in #4226 but marginal enough I think to warrant a separate thread. Feel free to close if this should be brought there instead.

Usecases

I rely heavily on the (admittedly undocumented) /style?png64= parameter to update button thumbnails via external scripts. In the current v5 beta, this parameter still updates a button's bottommost image element, but only for buttons created pre-v5. I'll get by as long as that continues to function, but if I could instead point the script to an item in the Image Library, I'd just have the buttons reference that instead.

I don't know what the plans are for the /style resource going into v5, so maybe something like this is already being considered along with its parameters for text and color

[Julusian]

I don't know what the plans are for the /style resource going into v5, so maybe something like this is already being considered along with its parameters for text and color
this parameter still updates a button's bottommost image element, but only for buttons created pre-v5

Under the options tab you now have to enable a toggle to allow the old mutation over the api endpoints. That defaults to true for existing buttons, and false for new ones

[thedist]

The main issue with a querystring ?png64= param is that it's not really appropriate due to URL length limitations. For example I just got the png64 string from an image I have in my image library and tried to use that as a querystring param and it immediately failed due to the length, so I think sending png64's like this is a non-starter for any new API endpoints, but sending it in the body of a request would be much more suitable.

[ChadJeffreyAnderson]

Under the options tab you now have to enable a toggle to allow the old mutation over the api endpoints. That defaults to true for existing buttons, and false for new ones

Oh, that's what that does. I hadn't looked to see that it was off on the newly created buttons. Great to know.

sending it in the body of a request would be much more suitable.

This sounds like the direction to go. Right now, my scripts compress the image to fit within an assumed header limit. Sending in the body would reduce the need for that.

[Julusian]

I'm pretty sure we support doing it in the body currently

^ from the docs inside companion. they dont mention png64, but its just another one of those properties

[Julusian]

Something else you could do, is to use custom variables for this. They can be updated over http, can contain a image data uri, and any variable can be used in the image field

[ChadJeffreyAnderson]

I'm pretty sure we support doing it in the body currently

Oh! That's huge. I hadn't made that connection. I only knew about the png64 property from stumbling across it in a different thread, and that was only in context of the query string. I've already updated my scripts. Thanks for enlightening!

Something else you could do, is to use custom variables for this. They can be updated over http, can contain a image data uri, and any variable can be used in the image field

Totally. In my case, that would require over 200 variables, which I guess wouldn't be any different than creating 200 image placeholders, aside from the added preview and download button. What I actually do currently is send the images to some buttons outside the Stream Deck's visible range in a sort of pseudo-library and then use reference elements to pull the images mathematically.