Base64 in image source

fixed

#1

I’m not sure if this is a bug or an intended behavior. I wrote a PHP file to generate Base64 encoded images based on JSON data sent to it via POST. Webcore makes the web request, sends the JSON data, and my PHP responds back with a working image. I have tested the image in a browser.

My Piston concatenates "data:image/jpeg;base64, " with the base64 response from the server. At some point, when the Image tag is written, Webcore chops off the comma and space and everything after them. If I remove the comma and space, the Base64 data is included, but of course the browser can’t parse it without the comma.

Here is my piston:

Here, you can see where the image source does not include the comma or the base 64 data:

And here, you can see that I get a blank image:
screenshot2

Here is the base64 data for my sample image:
data:image/jpeg;base64, /9j/4AAQSkZJRgABAQAAAQABAAD//gA+Q1JFQVRPUjogZ2QtanBlZyB2MS4wICh1c2luZyBJSkcgSlBFRyB2NjIpLCBkZWZhdWx0IHF1YWxpdHkK/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgATgBOAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A9/ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACuT8ZaxJplxpcP8AaslhBcu6t9kaA3bvlAuyOYESIAW3KitIWMYUHJB6yigDg774h3Ntrk+mQaLHI4fyoTNcvES/2qC3xIPKIQHz1kG1nJjKMVXetGk/EW51bxY2hx+HLuMwpA9y0hffCJlLpuHl7FKptLh3Qg71TzCo3d5UYghW4e4WKMTuio8gUbmVSSoJ6kAsxA7bj60Aef3Xj8aJD4mk+1R6u9lrC2sKNNHElurwowWWRFxGnm+bEHcfewrMMMw7iCcato0VxbyyW4u7cPHJG0btHvXIII3oxGc5+ZT7irlFAHma+M7zwvp0Nzql3d6sbzU7u0V7uS3tYoUguJI8CQRonmsi7gsjKG8t8MpwramreLtUubPxJYaJp/8AxM7C0uGtpvM3LcOpwDbjYfNZM4dcDbJtj53bh3FFAFPSr9dU0u3vUMZEqZzEzMhPQlGZVLoSPlfADDDDgirlFFAH/9k=


#2

Here, you can see that I am getting good data from the server:


#3

Try escaping the special characters with \

Use the replace function:

replace(your_string, “,” , “,” , “ “ , “\ “)


#4

@Robin, thanks for the reply. I have tried escaping at the server, escaping locally, etc. To double check, I tried escaping with your replace() function. To be clear, I can completely leave out all of the base64 coding and just try to populate with "data:image/jpeg;base64, " and the comma is still removed. If I try "data:image/jpeg;base64, " the comma is included, but the slash makes it to the dashboard.


#5

Hate to bear bad news but I found a few things that will prevent this from working reliably. The code to handle this [...] markup is just… sketchy.

The first thing done when processing that markup is to replace all spaces with commas, then split the expression at each comma. Not great if your data included commas or spaces to begin with.

A little more off-the-wall, your particular image happens to have a number followed by the lowercase letter x (.../2qC3xIPK...). This triggers interpretation of the entire value as a font size rather than a generic src option (a font size would normally look like [2x|big text]). That font size pattern is poor enough to demand a fix.

We have a big release coming up and I think these fixes might be worth including since they lead to behavior that is incredibly difficult to debug and inconsistent (may occasionally work) based on the data.


#8

@ipaterson

The only bad news is no news at all!

Thanks for the update. I will table the on-the-fly generation for now, and store the images on the server until there is a workable solution. At least I’m not wracking my brain any longer trying to find a non-existent syntax error. I’m not disappointed, because I’m only in the testing stages with the PHP file, so it’s only about 5 minutes worth of coding. Now that I know I can’t use that, I’ll find a new solution.

Thanks guys!


#14

The fix for this will be in the next release later this week. I had to be careful about how to address it since there is a possibility that people have used commas rather than spaces to separate their [...] expressions. It will now look specifically for a comma in the src= attribute and make sure the image uri does not get split.

The font size pattern is also more explicit, matching only expressions that start with a number to avoid finding the 3x inside your image data.

You will just need to remove the space between the comma and the image data.


#15

@jcox are you still using the encoded images and if so would you please check whether this is properly resolved? Based on your original piston you will just need to remove the space between the comma and the image data and the bug fixes should take care of the rest.


#16

I do still have them coded into the php, all I need to do is hit a switch. I have been focused on other aspects of the coding, so I haven’t checked it yet. Soon as I get home today, I’ll do a test and let you know how it goes.


#17

Update, we re-enabled the base64 output now that everything is updated, and it’s working like a charm! Only thing of note for anyone else using base64 image src, is to make sure to not put a space in the code (it’s customary to have one after the comma behind the header).

The working base64, in cause you’re interested:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIwAAABOCAIAAAB9gmnWAAAChElEQVR42u2bu23DMBCGaUZ9+iyQBbxEAG2QBbJBWrXeIAtkAwNZwgt4AZUBXKUynIIwQZPiQ0+L9PfDMKwXdbrv7ihR9ObwexGDdDydX5+fxGpUsD1SoNULSEBCQAISAhICEpAQkBCQgIRmhrTd7fHIClUdT2dz2VoMq9fOC6hUeyprpDZ94JZR8MXsoU/K88aBnom7OwSkIiGp4kaJI5MQkICEgISABCQEJAQkICEgAQkBCQEJSOgeqsR1voT7HRUTUZaxpxLXySfud9QCJqIsYw/lLuc+iXe13DggIAEJAQkBCUgISEC6h3gaWykkwGSTSaBaESTzDwGA4cYBSAhICEhFQxrW1XObUGwmAdWn0ESU6KSU6KbE7/evn++PN9Fz5oY6Sh8rHnMiSueklO1uf/isRWyiRUqbwybA+M7CRBS7HK25NJVXNuXaHJQyQuGuL7s/k2Ncn0tukUmUshwgkUNkEuGSA6Rh4xcljXowdpdBjsrHcfGYcchpHyr6vgiV5MQcePqGRXjPBy13w17qp+TEeLRAmhjbMpZs2r8LhLi7Q9NBemlucjy8aK7Xn86dfQdG5TbbuU+v1kaaNPhCUnzlWqXXSL3cNnU6MHNN29Tq07lz29SDnaKaDRxu2hx2U7Sp+QhpIy1H6a0+q/QmGb14i184SNMdNz633OSIMjAjyQpnvcZtKnDekdjCnuzXJ1l2m+Ggo2OOIFVGq3PpbPBFQzgqAznqtmw2pbeaZsxUM32elNGipO3rDMOordFETAn8lE4o5SyBw9OLgQs1fAlWUqZ7Q+8sfSUuMViUEea53bQbGVyqKfVjKiPdrT479bHajL4VL+CB6KnVD56TMtA/0V/6hurz5J4AAAAASUVORK5CYII=

Thanks guys, for all your help. I appreciate you considering this as part of the update.


#18

Well, I really like the improved capability of using base64 images in a tile, but I am having an issue getting the image to refresh. I have tried changing from refresh=600 all the way to refresh=10, and even with the piston running every minute (during testing) the tile will NOT update. Although, if I hit F5 in my browser, or go to the Fuel Streams page then return, the new image loads instantly.

Here is the way I am calling the image:

trash

Any thoughts or guidance?

Just to clarify, the piston works perfectly but the image tile will continue to show old data, and not refresh ever unless I manually hit F5 to refresh. I leave this browser tab open 24/7, so this won’t work for me. Also, for the record, the old method pointing to a JPEG with a refresh of 600 updated flawlessly within ten minutes of the piston being ran.

During my tests, I tried both setting base64 as a variable, and calling that variable as the src, and also calling the $response.data.base64 directly into the src, with the same results.


#19

Does the base64 value from the response already include the content type prefix, like data:image/png;base64, or just the encoded data?


#20

Yes @ipaterson. Here is the beginning of the response:

trash

And for clarity, the image refreshes beautifully if I hit F5 or refresh…
It just won’t ever refresh manually.

Can anyone refer me to some online documentation explaining the parameters I can use when I
Set piston tile
I am especially interested in parameters when displaying images embedded in my tile.


#21

Here is the response verbatim if you want to test in a browser:
(Although the forecast is clear skies the next 3 days, so the image isn’t very exciting)

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAIwAAABOCAIAAAB9gmnWAAAB90lEQVR42u2aMU7EMBAAfYaeng/wAZ5xj0rLQ/jBPYMPUNGlRKKiAR2FJWu1tjdO7OhiMVOgJE42a4+9Fqec3j6vTvD+9fv0cOcOA/k457yDw4MkJAGSkARIAiQhCZAESEISIOlfcnr9+GEUDs69+k2XX50PmA/ljj0JkIQkQBIgCUmAJEASkgBJSAIkAZKQBEgCJCEJkAR8iDICfIgyQD6UO/YkQBKSAEmAJCQBkgBJSAIkIQmQBEhCEiAJkIQkQBLwIcoI8CHKAPlQ7tiTAElIAiQBkpAESIKhJT2/XLJX0utIuoEYqaEk5raqZFZ9M/FrX1z6u0cnj7Y+1o5Ae/4hgu819PU695bRnknfDNvfeJq/r+zM7EnQT9LjdJHH8lS1KtTN6em2zEIc+/H64DLU5pQ2d0T1KDs+aVbxio/n83SWx/N0Lj2vOixvTp+Vx2tRobI3VA7TYqj9DMUkQw4y59Bayio2+ZqeG2MRmmIqIa7MrG+H1fxQ02jRgZyI6eqXQUqt2TKzWZtdk5b3JCOWmg7Sed85K33HyKWpY89KY42mkWWo2Kqm4x6LsjR0PluU7KWwqr63rKr0wcbSZ++slaFSqXYX6ge2NHQ+Wwrqi4mqb2m5a6x7sZPhQM33yhltF+E0cvbZmMbaimdvFvar+T9pGP4AkVO7XiMn6cIAAAAASUVORK5CYII=


#22

Ah, you’ll need to do the refreshing with a time trigger in your piston that updates the tile. The image tag will refresh like a normal image URL, but it’s just “refreshing” the last base64 encoded image provided by the piston which will never change until the piston runs again and sets a new title. If your piston is updated to fire on a timer every 10 minutes to make the web request and update the tile title with the new base64 encoded image you should be in good shape here.


#23

I have this code at the very beginning of the piston.

trash

Basically it runs itself every 10 minutes… Yet even after 4 hours (24 runs), the tile still showed the old data. It seems to require manually hitting refresh in the browser for the image to be updated, for some reason.

Is there some code I can add to that piston to force the tile to refresh once the piston has run?


#24

ipaterson, it is of note that each time this piston, the data returns a different base64 code, so the src attribute of the image tag is changing each time the piston runs. When we were running the pistons with an image file saved on the server, the src was the same each time, and we were having the same problem with the image not updating. Assuming it was caching, we ended up giving the image a refresh interval to force it to update. I also sent a random token as a URL parameter for the source from the PHP response to try to force a cache update. Somehow wcmore ended up figuring out how to get them to update, but neither of us is sure what did it.

I realize this function was designed for cameras, but we are trying to better understand the underlying code for images to try and get it to work. So currently, wcmore is both running the piston on a 10 minute interval AND using a refresh command on the image, and I am sending different data each time, but nothing seems to force the image tag itself to update with the new src, despite that the variable itself is updated. Using the other technique (image saved on the server, EDIT> and a ‘refresh=300’), the tile image updates EDIT> after 5 minutes.
I can’t, for the life of me, figure out what the difference is!


#25

I understand, I’ll take a look at why the image is not refreshing even with the piston updating it.


#26

Just to clarify, here is a screenshot of my original piston on the left (working with jpeg as src), and my new test piston on the right (never refreshing with base64 as src)

wc_RainChanceCompare5

On the left, the src points to a JPEG, it’s running every 30 minutes, and refresh=300…

On the right is the exact same piston except it uses the base64 as the source, and runs every ten minutes during testing…

My last F5 was around 11:21, and I have intentionally not touched this page since then.

Notice the time stamps. The original on the left updates within 5 minutes after it runs, but the base64 on the right has not refreshed the image even once in 6 hours. (but if I hit F5 in my browser, they would both update the graphics instantly

Can anyone refer me to some online documentation explaining the parameters I can use when I
Set piston tile
I am especially interested in parameters when displaying images embedded in my tile.


#27

There’s no documentation on this in the wiki but I pulled the following @ady624 quote from an old private thread back in the development days:

for image, (should work with text too)

[img refresh=30 src=http://url-goes-here|]

supported options:

refresh=X where X is a number of seconds
full - makes the image cover the whole area, by default it scales to fit, adding borders of the back color’s color

for video:

[video muted=1 src=https://www.w3schools.com/html/movie.mp4|]

available options:

autoplay=0|1, defaults to 0
controls=1|0, defaults to 1
loop=0|1, defaults to 0
muted=0|1, defaults to 0 so people don’t complain they hear no audio
full - makes the image cover the whole area, by default it scales to fit, adding borders of the back color’s color

This last point may be most relevant to your issue (I think):

Please note that the image/video options do NOT refresh automatically if you change the values in the piston tile - a refresh of the page (or view piston and come back) is required for new options to come into effect - also applies to the refresh period, it seems