Planning Issue for the Image Sequencer GSoC Project

[ccpandhare]

This is my plan for the summer. Please suggest any suggestions which you may deem fit @jywarren @ebarry. There is still a lot to be written here, will keep adding more points with time. This is by no means, exhaustive.
Link to my proposal

Phase 1 : Core functionality and JSON Input Support

In this phase I will build upon the core fuctions of Image Sequencer (addSteps, removeSteps, insertSteps, loadImage)

• Create function addSteps which accepts data in many formats (JSON and otherwise) as described in the development wiki (PR Phase - 1 Completion #24)
• Create the system to be used for handling images : Instead of choosing Sharp or Jimp or lwip, I stuck to plain old DataURIs in custom Image objects. As the mentioned modules have huge functionalities which are not relevant to Image Sequencer. (PR Phase - 1 Completion #24)
• Create the framework for using multiple images : Finally enables Image Sequencer to handle multiple images at once. (PR Phase - 1 Completion #24)
• Similarly, create removeSteps, insertSteps, loadImages and modify run (PR Phase - 1 Completion #24)
• Update Usage Instructions in Readme.md

Phase 2 : Unit Tests, Modularization, Unified Input Parsing

• Unit Tests for the methods addSteps, removeSteps, insertSteps, run (PR More Tests, Unified Input Parser, Modularization #28)
• Image Based Unit Tests : Double Inversion Test, NDVI Test (PR Double Inversion Test #30)
• Unified Input Parser : A Single Module to parse inputs in different formats - reduces source size and helps manage code. (PR More Tests, Unified Input Parser, Modularization #28)
• Modularization of large functions which were earlier a part of src/ImageSequencer.js (PR More Tests, Unified Input Parser, Modularization #28)

Phase 3 : Module Logs, custom I/O, headless testing, Chaining, replaceImage

• Headless Browser Testing using the tape-run module. (PR Headless Browser testing using tape-run #55)
• Method Chaining (PR Improved Docs, Chainable Methods #44, Added a 'Domain' in Chaining #53)
• Added Invert Module (PR Double Inversion Test #30)
• replaceImage Created, and along with it, its gh-pages demo. (PR replaceImage method as requested in #32 #35)
• Create a module log. This will store logs from various modules. Useful for debugging. (PR Module Logs #37)
• Allow modules to interact with the user, accept and output data apart from images. (example: data of a QR Code)

Phase 4 : User Interface, Support external Images

• Create Module Interface (PR Implemented UI Methods #67 ISS Rework UI Handling #85)
• Create the User Interface for node based and browser based implementations of Image Sequencer. (Across various PRs)
• local image support on Browser (PR Support External Images #81)
• URL image support on Browser (PR Support External Images #81)
• URL image support on Node.JS (PR Support External Images #81)

Phase 5 : Additional New Features

• Added method .exportBinary() to export images as binary (NodeJS) (PR Added exportBin method #90)
• Image testing using pixel-by-pixel comparison with a tolerance level (PR Image Diff based testing for PNG images #89)
• Describing module requirements using an info.json file for every module. (PR Added Image Sequencer Demo #92)
• Implemented Complete demo (PR Added Image Sequencer Demo #92)
• Added Basic Command Line Interface (CLI) (PR Added Basic CLI #95)
• Publish demos to GH-Pages (PR Add gh-pages branch #96)

Phase 6 : Module Implementation & NPM

This phase involves implementing the various modules as mentioned in the Readme.md and my project proposal.

• Publish to NPM
• FisheyeGl (PR Added FisheyeGl Module #61)
• Crop (PR Revived Crop Module #56)
• Invert
• Segmented Colormap (PR Added segmented-colormap Module #57)
• QR Code Module (PR Added DecodeQr Module, Test #72)

[jywarren]

Hi, this looks super -- I'd like to request some more explicit mention of when tests will be added, and encourage adding a really clear test that processes an NDVI image and does a diff comparison between a "before" and a known "after" image, that we can visually confirm. I think this should be done in the phase 1 and be clearly documented in the readme too -- this'll be a really clear way to explain the system, and ensure its basic functions are legible and concrete. Make sense?

…

On Jun 3, 2017 10:55 AM, "Chinmay Pandhare" ***@***.***> wrote: This is my plan for the summer. Please suggest any suggestions which you may deem fit @jywarren <https://github.com/jywarren> @ebarry <https://github.com/ebarry>. There is still a lot to be written here, will keep adding more points with time. Link to my proposal <https://publiclab.org/notes/ccpandhare/03-18-2017/developing-image-sequencer-as-a-library> Phase 1 : Core functionality and JSON Input Support In this phase I will build upon the core fuctions of Image Sequencer (addSteps, removeSteps, insertSteps, loadImage) - Create function addSteps which accepts data in many formats (JSON and otherwise) as described in the development wiki <https://github.com/publiclab/image-sequencer/wiki/Development> - Create the system to be used for handling images : Instead of choosing Sharp or Jimp or lwip, I stuck to plain old DataURIs in custom Image objects. As the mentioned modules have huge functionalities which are not relevant to Image Sequencer. - Similarly, create removeSteps - Similarly, create insertSteps - Similarly, create loadImages Phase 2 : Multiple Image Support and GPU.js integration - Create the framework for using multiple images. - Integrate GPU.js Phase 3 : Module Logs and custom I/O - Create a module log. This will store logs from various modules. Useful for debugging. - Allow modules to interact with the user, accept and output data apart from images. (example: data of a QR Code) Phase 4 : User Interface - Create the User Interface for node based and browser based implementations of Image Sequencer. Phase 5 : Module Implementation This phase involves implementing the various modules as mentioned in the Readme.md and my project proposal. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ5esv9Jw9A9103sf9rTBA4TUcWIHks5sAXPdgaJpZM4NvG0y> .

[ccpandhare]

Okay, I will look into it and let you know if I face any issues.

[ccpandhare]

encourage adding a really clear test that processes an NDVI image and does a diff comparison between a "before" and a known "after" image, that we can visually confirm.

I am not sure on how this is to be done. Please help me out @jywarren

[jywarren]

Well, I think we could run a test on a test image, and visually confirm (like you did with the saturation problem) that the output is correct. Then document that example in the readme too to show how it works!

…

On Jun 24, 2017 9:44 AM, "Chinmay Pandhare" ***@***.***> wrote: encourage adding a really clear test that processes an NDVI image and does a diff comparison between a "before" and a known "after" image, that we can visually confirm. I am not sure on how this is to be done. Please help me out @jywarren <https://github.com/jywarren> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ_MQ4Kyez4MkFrDZGfBtYigLwJYVks5sHRKwgaJpZM4NvG0y> .

[ccpandhare]

Okay, Thanks! Will do that.

[jywarren]

Ok! Now let's find, on the public lab site, a clear before/after NDVI image and get ImageSequencer to reproduce it. Ask Ned Horning or Chris Fastie!

[jywarren]

Also, can you merge to gh-pages branch so we can update the online demo?

[ccpandhare]

Ok! Now let's find, on the public lab site, a clear before/after NDVI image and get ImageSequencer to reproduce it. Ask Ned Horning or Chris Fastie!

Can I generate one from Infragram?

[ccpandhare]

I had a quick check. The results from Image Sequencer are very different from those of Infragram

[jywarren]

OK - can you post them all in an issue, both before/after pairs? Let's work on this!

…

On Fri, Jun 30, 2017 at 11:47 AM, Chinmay Pandhare ***@***.*** > wrote: I had a quick check. The results from Image Sequencer are very different from those of Infragram — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJyFQWr2SmdUZUdwoDFbU9oTuipc_ks5sJRitgaJpZM4NvG0y> .

[jywarren]

Really coming along here!

The fisheye module really starts to dig us into user interface and options setting stuff.

Another thing we may want to add is -- can modules access information from previous modules? Say, if we had a module that produced a certain output, could we pass that information on to later modules to use? I don't know -- say, a decoded QR code, or... extracted EXIF data?

[jywarren]

For example, what if we included a QR code in an image and it generated metadata available to the sequencer modules? I'm thinking about for example a colored backdrop with a qr code which, when you photo it, runs a particular module automatically or something.

This is probably thinking too far ahead :-) let's think interface for now!

[ccpandhare]

Well that sure is a possibility, and I am sure it can be done!
But yes, UI should be implemented first :D

[ccpandhare]

Another thing we may want to add is -- can modules access information from previous modules? Say, if we had a module that produced a certain output, could we pass that information on to later modules to use? I don't know -- say, a decoded QR code, or... extracted EXIF data?

Well yes! I think I can add this after the UI

[jywarren]

I think we can close this out now! But let's clean up the issues a bit as well. Congrats!