Hey Steve,
It indeeds gives conflicts because you have used in your clone the same node identifier as the original node.
BTW a few months ago, @dceejay and I have been pimping the original node-red-contrib-image-output node quite heavily:
it also accepts jimp images
it automatically resizes images to the size they will be displayed, to reduce data traffic
it has a button (similar to the debug node) to pause the image streaming at server side
...
But it is indeed a pity that now both nodes can't be installed together, because I want to use your image-tool nodes and the original image-output node. But don't know how to achieve that...
Hi Bart, i spent a lot of time mulling over how best to handle this when I included it in image-tools (I discussed it on here)
In the end, after much agonising, I decided to keep it inside as it handled a number of things the original didnt e.g. it didnt work on IE11, didnt know what to do with a jimp image, couldnt handle certain base64 images without mime specifier etc etc. I did ask for advice (like how to support handling a jimp image without the lib installed) etc but information (and my knowledge at the time) were not forth coming - it ended in this situation.
I think another part of my logic was that if you are doing image modification - you get a built in viewer.
With my hindsight glasses on, I should have gave it a different name (this was written before I understood those types of implications)
If I remove it now & users update, then it (kinda) breaks what they have.
HOWEVER...
If we come together and combine the capabilities of the two, I would consider removing or renaming the internal image viewer - thoughts on how I would mitigate disruption to existing users Major version number change? some means of detecting and changing existing old name image-viewer nodes? optional dependency to other node?
Yes I think we definitely should do that in the near future ( in a separate discussion), at least if @dceejay agrees. Because he has become the new master of Riku's image-output node...
Yes they need to be either de-conflicted or merged. I don't think I'm the master but do have the power to update it. I think it should be a stand alone node (that can be required by Steve's package of course) - so users that don't need it all can just use it stand-alone. I don't mind whomever wants to take on the task of blending them. Must admit I've not used Steve's so I don't know how much it differs.
Hi @BartButenaers / @dceejay , so as discussed, I have been evaluating both image viewer nodes in both contribs -image-tools and -image-output with a view to removing the built in viewer in favour of the stand alone node.
I might be able to align with this lib but I am concerned the dev might not stay up to date with base jimp lib - thoughts?
-image-tools does not have an output enable button
-image-output has no pass though (no output pin), (-image-tools has a pass though for inline / chained operations (output pin))
this was introduced to reduce msg cloning (i.e. msg passes straight through instead of branching off)
-image-output doesn't work with a full data URL (spec / mdn) e.g. data:[<mediatype>][;base64],<data>
however, before displaying the image data in the viewer, it goes on to assume the base64 data will be png and prepends it (regardless of type) - this causes issues with regular Image URLs and Data URLs (see images below)
-image-tools viewer accepts everything image-output does + filename + Image URL + (complete) data URLs
-image-tools also infers actual image data type by 1st 5 chars of data portion if mime type is missing
image-output resizes image at server-side to reduce traffic back to node-red editor
These are partly the reasons I initially added the viewer (I'll try to find original conversation for reference - if necessary) but mostly the image-output did not have Jimp as a dependency at the time of development - and seemed a lot to ask devs to add
Demo...
Here's a demo to try and put the above words into a picture...
note the deliberate typo in the image - base62
What are your thoughts on aligning our 2 viewer nodes in order for me to consider removing the internal viewer?
NOTES
I have modified the original image viewer node to make this demo work (some bug fixes in image-tools viewer I happily happened upon!) + there was another conflict I had to resolve before I could test these side-by-side (both image viewers subscribed to the same comm (RED.comms.subscribe('image'...) so events were occurring twice at client side.
Thanks for the time you have spent on comparing both nodes!
Looks like a very professional comparison!!
Jimp vs Jimp-compact: you are completely right that this library indeed might stop following jimp in the future. However the viewer only needs the most basic jimp functionality: we only need to be able to resize and load a Jimp object. All other (new) Jimp functionality won't be needed for the viewer, so don't think it is a problem if that gets upgraded in the future. Is that correct?
output enable button: that is one of my favorite features, because now I can keep my image viewer nodes in the flow, even when I don't need them at the moment. No data will be transferred anyway ...
no output pin: Oh what a bummer... That is indeed VERY useful to avoid cloning. However I don't think this can be combined with the output enable button. Damn. Don't know a solution for this
full data url and missing mime type: Ok that indeed should be fixed.
Am I correct that the output pin is the major bottleneck to be able to merge both nodes?
Or do you see other major problems to merge them?
This is true but its not the problem. If I were to switch image-tools to jimp-compact and jimp-compact fell behind Jimp, I would want to switch back to original Jimp - so I prefer to keep image-tools with original Jimp version.
That basically means if a user has both image-tools and image-output -AND- we dont use same library, then the installation is larger (jimp and jimp-compact wont be de-duplicated by NPM)
Not a huge problem.
I agree - a good feature.
Actually, you can have a button AND an output (it isn't pretty - but it works)
Must be able to handle full Image URLs (you get this for free when you fix No.1)
Must be able to handle filenames (easy now you have Jimp) (All of this is handled in image-tools if you wish to save on dev time)
Current sticky point (but not a problem for me personnaly)
I greatly prefer NOT to switch to jimp-compact so either image-output changes to jimp OR we do nothing (NPM doesnt dedupe, user has larger install - but everything continues to work)
Steve thanks for the great analysis work - great summary.
when installed - jimp-compact is 482k... vs jimp is 24MB... I think I know which I prefer for something I don't use every day. Smaller every time. Re getting behind... what are you thinking may be needed ?
wire and button ... uuuurgh - please god no... I would get it banned if you do that... (OK maybe not - but there will be words!!!) . You could have an option instead... if configured in passthrough mode then remove the button and add the pin... and vice versa.
Re full data url and missing mime type - I guess I 'm not quite up to speed on the subtlety of that - but I'm sure you guys can enlighten me or Bart can fix it
I think we have managed to stop them blocking each other (thanks to Nick) so I think they can now both co-exist if required.
I had considered that (and it aligns with my original musings when debating whether to include/exclude the image viewer inside image-tools)
Definitely food for thought.
Haha - yeah, crack on Bart
I agree its fugly - BUT - there are valid reasons for having INPUT + BUTTON or OUTPUT + BUTTON
Perhaps an alternative button placement would be a good in these cases?
something like a toggle button (depressed/non depressed style) where the image is shown?
Some of the plugins like threshold for example. Not sure if jimp-compact supports the plugins. My main concern though is this compact version becomes neglected.
I should probably explore this option
Yes that is indeed another option. Because I see that already other nodes are being developed to show images in the flow editor ...
But still would be nice to have a single node with all features. Seems a bit user unfriendly that I need to use one node for feature X, and another node for feature Y. That feels so non-professional ...
The only thing that bothers me: I would like to have a node which has an output (for chaining without cloning) AND (not OR) a disable button. Then you can use such a node inside a chain AND you can disable it at runtime. But it isn't possible to have both features at the same time
Ok, let's have a quick look in my calendar.
Seems I have again free time available to do this, starting from 12 april:
Agreed a single node would be nice - this is supposed to be a simple image debug/display node - leaving Steve's other nodes for the manipulations so I really don't want 24MB of cruft just for that.
Also don't forget these nodes are all using an undocumented / unsupported API that may well change as we move forward so I wouldn't want them to get too invested with functionality.
Great - looking forward to the 13th ! Happy Easter !
