If someone composes a sequence and tweaks the settings, they have a process which is really useful.
And if we can concisely store that in the URL itself, then they can share that workflow (sequence + settings) with other people, or bookmark it, and we don't have to use a database to save it. We do this now, though we don't save the settings, just the sequence:
https://publiclab.github.io/image-sequencer/examples/#steps=invert,crop
(@ccpandhare -- i think we had a partial implementation of settings, do you remember? Ah -- https://github.com/publiclab/image-sequencer/issues/127)
We wouldn't save images, just the workflow itself. But we might want to start collecting these too -- they could in theory become "meta modules" with names of their own. Maybe that's a feature in its own right?
Another aspect of this is that if we have a consistent string-based way to save a sequence and its settings, that's a good format to use for remote REST commands down the road when we decide to do that -- #198 -- and also we could base a "meta module" system around such a string.
A meta module could be a module which contains a string describing a set of modules and their configurations, that can itself be re-used.
Meta, but very powerful!
We could even, if the UI is good enough, have this prompt people to save their sequences as a module -- to propose a module based on the current state of their sequencer! This could help with #190 as well.
GitMate.io thinks the contributors most likely able to help are @ccpandhare, and @tech4GT.
Possibly related issues are https://github.com/publiclab/image-sequencer/issues/108 (Math Module), https://github.com/publiclab/image-sequencer/issues/112 (Scale module), https://github.com/publiclab/image-sequencer/issues/5 (image cropping module), https://github.com/publiclab/image-sequencer/issues/122 (Simplify module requirements?), and https://github.com/publiclab/image-sequencer/issues/157 (Add a Contrast module).
@jywarren this is so cool, i will start working on this for the node using a meta.json and i will try to implement region extraction with that only, super excited😀
@jywarren if #203 is a good enough approach then maybe we can start working on an option in the CLI for defining meta-modules so that user can dynamically define and these according to needs, So that is one user uses a particular combination a lot in a specific sequence they can define a meta-module for it. This will also be in sync with what we are planning to do with modules in the summer, what say?
@jywarren
here is a simple checklist of my view on how we should go about things for this
What is a Metamodule?: A Sequence of steps which can be represented as a string or as a json and can override some values of some steps while letting others fallback to default. The metamodule can be called with custom values just like a normal module
[ ] Metamodules.json for backend and importing them like normal modules with default presets of its constituent modules but possible to override(#203 )
[ ] Implement a .getString and getJSON function on the ImageSequencer instance which enables interconversion of json and string metamodules.
[ ] Make it possible to include the string based metmodule in the url( #127 )
[ ] Allow for storage of these metamodules as metamodules.json for node and IndexDB(tentative) for browser
@jywarren actually there is one more thing, we want to allow user to make and store metamodule in node but that will not be possible unless we load modules dynamically as i suggested in my summer proposal so if we want to go down this route then we should first allow dynamic loading and creation of modules.( #190 ) coz if we are going to drastically change the module system then it's better we make met-modules on top of that, what say?
@jywarren we had to discuss #190 as well, this maybe a good time since we are making important architectural choices...
This is awesome, good planning! A few responses:
sequencer.import(string|json) -- what do you think?Finally, sequencer.import() and sequencer.toString() and .toJSON() could all be unit tested independently of their different use cases, which is GREAT.
What do you think???
Er, wait! I'm mixing up sequencer.toString with metaModule.toString, aren't I? How should we approach this? Should metamodules have a toString and import method just like a sequencer, that's kind of what makes them meta, right? What do you think?
@jywarren i did not get the sequencer.import(), can you please explain it a little more, Thanks!
Also I think lets not do toString() we can do a sequencer.getStringMetaModule(metamodule) and sequencer.getJsonMetaModule(metamodule) functions..
@jywarren Are you talking about importing these modules into image sequencer...if that's so then that will actually be handled in dynamic modules so for that can you please have a look at #190, I posted a nice diagram explaining the flow for dynamic modules there, Thanks :)
@jywarren And yeah metamodule should surely have every function a normal module has.. I'll keep that in mind 👍
So for metaModule.import(string) it would read a string, and construct the metamodule based on that string. For a sequencer, it could reconstruct a sequence from the string passed to sequencer.import(string). Sorry, not that we would import new modules like Dynamic, but just that we'd import a sequence of modules which had been saved as a string.
So like we could then do:
string = metaModule.toString();
...
metaModule2.import(string);
Make sense?
sequencer.getStringMetaModule() could work but why don't we build this method into the module itself, because we could call it on any given module, like:
metaModule = sequencer.images.image1.steps[0];
string = metaModule.toString();
console.log(string);
metaModule.import(string + ',invert');
... does this make any sense to you?
@jywarren Yes!! This is very clear to me now. Thanks a ton for the explanation.
metaModule = sequencer.images.image1.steps[0];
But I think this won't work as it is, since this line would assign metaModule to a step, and then calling .toString() will be calling toString on a step.
Instead what we can do is:
sequencer.createMetaModuleFromString(sequencer.images.image1.steps[0] + ',invert');
How does this sound @jywarren
@jywarren Option 2: Actually sequencer.importString( MetaModuleString ) feels more natural to me than anything else, also I was thinking if we define functions on the metaModule itself then we would have to wrap it up in an object but if we keep the import on sequencer then metaModule can be just a String.
Thanks :)
calling .toString() will be calling toString on a step.
I think this is partly a matter of paradigm. We could, in theory, build .toString() into each step -- i mean, it's an instance of a module, right? Can you explain about having to wrap it in an object?
Thanks!!!
@jywarren Yeah that's right, it's an instance of a module but it feels kind of unnatural that we are doing
metaModule = sequencer.images.image1.steps[0];
Here we assign a step into the metaModule variable.
Then where we import the metaModule, I want to ask one thing, Does the metamodule appear as an option in the list of modules to chose from or it gets applied right away??
Aah it's so difficult to explain this on text, It'll be so cool if we can have a chat in realtime, what say??
I think a metamodule could be used in two ways:
They're pretty similar, you know, but does this make sense?
One advantage of building toString() and importString() into the module itself is that you could "reprogram" a metamodule, and also because the code for all of this could live in the module itself, rather than in the sequencer core, which seems cleaner. Sequencer doesn't even really need to know how it works, you know?
@jywarren actually I had a little different idea in mind, I thought maybe we can have an option in the ui where after the user builds his sequence it says save as meta-module which will store it locally and now user will see this in drop-down like a normal module. Maybe we can do all these 3 ?
This has many parts now -- i'm going to start breaking it up by making a new one for a toString() method:
We should now be able to implement metamodules using sequencer.importStringtoJson()!! from #276
This is great!! @jywarren but we need to keep a discussion session before implementing this
OK! Can you write out your questions here? Maybe this issue needs a little
clean-up as we discuss, too. Thanks!
On Sun, Jun 3, 2018 at 10:42 AM, Varun Gupta notifications@github.com
wrote:
This is great!! @jywarren https://github.com/jywarren but we need to
keep a discussion session before implementing this—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/image-sequencer/issues/200#issuecomment-394174689,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABfJ8gexLVmrViv3SHWbtdcJDerw4xnks5t5BHmgaJpZM4Sm4Ys
.
@jywarren Sure I'll gather everything we have discussed so far and write questions tomorow after fixing the run optimization.
Thanks Good night!!😁
good night!
On Sun, Jun 3, 2018 at 10:59 AM, Varun Gupta notifications@github.com
wrote:
@jywarren https://github.com/jywarren Sure I'll gather everything we
have discussed so far and write questions tomorow after fixing the run
optimization.
Thanks Good night!!😁—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/publiclab/image-sequencer/issues/200#issuecomment-394175745,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABfJzSBRHRGAVNxQgNCi0DHdYB9nuiPks5t5BXcgaJpZM4Sm4Ys
.
@jywarren I have been thinking about this and I think best way to tackle this would be having a registerMetaModule function that takes a sequence string and this would add this new meta-module to a json file "meta-modules.json" and image sequencer would have a reload-modules function which would load modules and meta-modules again. This is also consistent with the dynamic modules idea and I think doing it this way implementing that would be much less work
So basically the flow I am suggesting is this
saveAsMetaModule()Now closing this!!
Most helpful comment
@jywarren we had to discuss #190 as well, this maybe a good time since we are making important architectural choices...