Closed bartbutenaers closed 4 years ago
Nice idea Bart. But.... just wondering... given that the user currently have a choice of viewing size at the client end (once fixed) - why not resize server side all the time ? Is there a performance benefit to letting the browser do it (eg browser in laptop vs poor old pi server) ? Or maybe it's just the checkbox words should be "rescale image server side" or similar ? Just worth a 5 minute think. (and yikes - just another 3.6MB to the stack...!)
Morning @dceejay, So you suggest to remove the checkbox and resize the image always at server-side. I had added the checkbox in case you want to send the images with original dimensions to the flow editor, so the browser (which is most probably running on another machine) can resize them. Because I can imagine that you don't want to do the resizing on a poor Raspberry PI, but instead you want to do it on a labtop with i5 core (where the dashboard is viewed) ;-)
Perhaps I could do it like this:
Sounds that better? Or just remove the checkbox?
Both options are fine for me!
Good points - I think... leave the checkbox - default should be client side (as is)... Maybe just change the words so it tells the user which side is doing the work rather than saying sending thumbnails which doesn't really explain what is happening.
Dave,
I made following adjustments:
The checkbox label has been updated:
The info panel has been extended:
The readme page has been extended:
Hopefully it is now more clear to users, what we want to offer with this new functionality... Thanks for reviewing!!
Looks good. Thanks
Hi Riku (@rikukissa) and Dave (@dceejay),
This node is still one of my favorite nodes. But a disadvantage is that the images are pushed via the Node-RED websocket channel, which starts choking very easily when too much data is being pushed through it. And then my flow editor becomes unresponsive.
And since the images will be showed very small inside the flow editor, it has not much use to push the large (original) image through the websocket channel. Indeed they will be resized by the browser anyway, to show it as a small thumbnail image...
To workaround this, I have added a new checkbox to the config screen:
This option is deactivated by default (to keep the original behaviour). But when it is activated, the image will be rescaled at server side. I use the width specified on the config screen, and the height is automatically calculated (to keep the same aspect ratio as the original image).
Example input base64 image:
Which is being resized to a much smaller string:
You will gain more for larger images of course ...
The readme page has been expanded with a "Node configuration" section, that explains that lower bandwith will result in higher cpu usage (due to resizing):
The info panel also has been extended:
BTW I have used Jimp to resize the images. Perhaps that might be a bit overkill, but I have tried some other image resizing npm libraries: those were based on C++ libraries (like e.g. sharp), which caused a lot of compilation troubles on my Raspberry. So now we have a full Javascript solution. Perhaps not as fast as C++, but then at least nobody has troubles installing it ...
Hope you like this change! Bart