Re-construction for ImageSequencer

by yachao | 24 Mar 01:24

Name: Yachao Lu

**GitHub: **https://github.com/lvyachao

Affiliation: Department of Computer Science, George Washington University

Location: Washington, DC

Email: lvyachao@gmail.com

Project description

Image Sequencer is a image processing systems which is non-destructive: instead of modifying the original image, it creates a new image at each step in a sequence. This project not only provide a simple image processing service but also providing many possibility from its modularization. The idea of "module" can make every single function work separately and work as library. Also it shade light on lots of extension for this application.

Problem

This application is on the early stage and it indeed need a lot improvement in five aspects: UI, Modularization, Testing, Use Cases and Bugs. The core functionality (progress/step control functions) is not completed yet. Among them, I think UI part and Modularization (Making modules API-ify) can be set to priority.

What I am planning:

1. Add a "State-Machine" framework to front-end

JavaScript State Machine (https://github.com/jakesgordon/javascript-state-machine) is one of the best state machine libraries now. The idea of state machine can help the logic of our structure (NO MATTER BACK-END OR FRONT END) even more clear and readable since about all core function is related to the "state" (steps).

Another mission of this project is want to making modules(functions) work alone without GUI but can works individually. The idea of "state" (steps) can also helps. I will take about more detail for modules "API-ify" in next subsection.

Following is a example code for state machine:

Var view = StateMachine.create({
events: [
{ name: 'NDVIEvent', from: 'uploaded', to: 'NDVI' },
{ name: 'threholdEvent', from: 'NDVI', to: 'threhold' },
{ name: 'downloadPage', from: ['uploaded', 'NDVI', 'threhold'], to: 'final' }
],
callbacks: {
onentermenu: function() { $('#menu').show(); }, onenterNDVI: function() {$('#NDVIPic').show(); },

fsm.transition(); //handing some render event
});
return StateMachine.ASYNC; // tell StateMachine to defer next state until we call transition (in fadeOut callback above)
},
... //Other codes appear here
}
});

Following is a rough structure I want to make this project be like:

2. For "Modularization", I will focus on two things: 1.rearrange of structure of modules following the "states" structure, letting whole structure of the application more clear; 2. Make all modules has an "output" (API-ify). Actually, making modules API-ify is quite easy to be deployed with the help of some tools like WebPack, which "export" a API for every functions.

3. Adding a Progressive JavaScript Framework handling all the front-end events; data-binding system and form-rendering: Vue.JS. (https://github.com/vuejs/vue) (optional)

Vue.JS is a powerful and light-weight front-end javascript framework, it can set up controller functions handling all the current needs for our UI(e.g., insert, remove, form rendering). By the help of Vue.JS, I can easily finish all the "to-do-lists" on UI parts quickly and the codes for Vue.JS is so light-weight and much more readable than similar frameworks like Angular. Another benefit of setting up such a library is easy to maintain: no matter which event we want to create in the future, it will be quick and readable by the help of such library.

4. Develop core functions for UI parts, like adding, removing, next steps, etc. (discard if not necessary)

5. For Testing, I will designed unit tests and add my own modules that I think that will help.

Schedule of Deliverables

29 May -- 11 June

Add Vue.js environment and JS state machine and set up all the data-binding system, redesign the front-end interface.

12 -- 23 June

Write down all state control functions and core functions for controlling the image process.

Community review for works above

24 -- 30 June

Test and document existing code.

1 -- 7 July

Investigate all the existing modules code and provide solutions. I will write a list for each solution or just quick fixed them if necessary.

8 -- 18 July

Develop codes for modules parts and test.

Community review for works above

19 -- 28 July

Test and document existing code. Deployed finished demo online and collect feedbacks for existing works.

29 July -- 11 Aug

Write more modules that fits for this system

12 -- 18 August

Test all remain codes and handle unexpected bugs/problems.

Open Source Development Experience

Developed and deployed Project Timbr with more than two years developing. (Now it is stored as private repository as research privacy purpose and been offline). Now I can only show two early-stage codes (https://github.com/lvyachao/timber_prototype) and Timbr Version 1 (https://github.com/lvyachao/Timbr_V1).

Open tickets on questions/issues on repository like Graphlib, NightmareJS.

Actively forked and use 10s repositories.

Work/Internship Experience

Research Assistant on department of Computer Science, GWU, Dec 12 - Present;Web Master of JKA Karate Club of GWU, May 14 - Present

#

@warren pls take a look and kindly leave some suggestions if possible! :)

Reply to this comment...

@warren I saw that you mention you are in vacation...Can you pls take a look at mine when you free? Been posted for a while...

Is this a question? Click here to post it to the Questions page.

Reply to this comment...

Hi, I was traveling for work, and got back yesterday (and took a day of rest :-P) but am reading through all of these now. Thanks!

Reply to this comment...

@warren Yeah... I saw everybody is seeking u lol... Appreciated a lot have time checking our proposals!

Reply to this comment...

Hi, the finite state machine idea is interesting. How would that look in an image-sequencer implementation? Can you illustrate this with some example code, imagining that you've integrated the finite state machine concept, to show me how image-sequencer would work with that model?

Is this a question? Click here to post it to the Questions page.

Reply to this comment...

Could you also link to anything you've already done on the image-sequencer project, even comments and issues, just so I can see how you've started to look through the code? Thank you.

Is this a question? Click here to post it to the Questions page.

Reply to this comment...

Vue.js also seems really interesting, thanks for suggesting it! Would it be (i'd prefer) an optional UI implementation for the project, alongside direct commandline (nodejs) use and (for example) a flow-based visual UI? Is there any way you could provide a kind of diagram of how the UI might be architected, a bit like the diagram here: https://publiclab.org/notes/mridulnagpal/03-01-2017/map-of-projects and/or a mockup of how it might look?

Thanks for your proposal and apologies for my slowness in replying!

Is this a question? Click here to post it to the Questions page.

Reply to this comment...

@warren Since the deadline is almost approaching and I'm quite busy this week...:( I don't think I can have time to write down any codes within deadline... While I'll draw an UI graph to give more detail about how VUEJS and state-machine works. I'll also include my old project link later for showing my experience with VueJS and State-machine(That one is actually a private one but I might can dig them out for a while...) Thank you for advice!

Reply to this comment...

Vue.js is great!

Sorry to interrupt, but isn't Image Sequencer supposed to handle the Image Processing? The front end which was written was a demo (a demonstration of Image Sequencer's functioning).

So is it okay to prioritise the UI Creation over the actual Image Sequencer Library, which is under construction rather than the modules themselves and Image Sequencer's core functioning, especially when we are more interested in the Node.js implementation?

Is this a question? Click here to post it to the Questions page.

Reply to this comment...

@ccpandhare Well, I'm afraid I don't agree with what you say. Based on the description and after I read whole code base, there is a lot of logic and design needs contained on UI part of the whole application. Based on my point of view, this application is a early stage application and still need improvement of building a better structure. I'm saying that I'm gonna rebuild whole web application structure not only the UI part. I think what I can bring useful contribution is what I'm writing above and it does covers requirement of the topic, also shade a light for flexible and manageable for future development. :)

Reply to this comment...

@warren Can u double check my revised proposals.

Reply to this comment...

Hi, I guess I still think a diagram of sorts would help explain exactly what functions and states would be encapsulated in each component, and perhaps would help me understand the distinctions you're making -- I'm especially interested in which parts manage the "state" of the system and which are required for running. Notice we are trying to make:

1. the system runnable without a gui (in nodejs)
2. the modules as simple as possible so they can be written in a short and standard way by anyone
3. the whole system usable as a library in​multiple applications

So another thing to talk about is what specifically Vue.js and the state machine library would make possible that is am improvement (beyond just optimization) and what possible drawbacks they might have.

Thanks for your extra work to articulate your proposal, it's much appreciated.

Reply to this comment...

@warren Hi, sry I'm a little busy recently... Let me re-state my very immature and personal thoughts with this updated diagram.(I also rewrite some of my proposal) The target of my proposals is to make this project a mature and "complete" projects that not only providing a excellent web application instead of a incomplete demo but also provide all modules API-ify -- At least I think that's most complete open source project do for their Phase 1. For current stage of this project, we don't have much modules, we don't have a complete demo, not to say we have any "multiply applications". We just say at least we providing so many modules that can make people use? Like a NPM library? people nowadays rare trust any start up NPM libraries, and making server side module API-ify usually is not in early stage of startup projects do. Even your aim for this project is indeed just want to building some libraries contributing to NPM community and making a lot people building their applications leverage your modules... I will still say I think rearrange whole structure and give a perfectly demo is more important. (Make modules API-ify is so easy to done, but make them competitive is hard)

Is this a question? Click here to post it to the Questions page.

Reply to this comment...

Thank you for the diagram and for sharing your thoughts -- much appreciated!

Reply to this comment...