I think it might be possible to work on a simple calibration process that could be used to get decent NDVI values. I don't think there is much a user can modify with these cameras regarding settings and if that's the case we could come up with a formula tuned for the Mobius Action Cam.

In the next couple weeks I hope to break out my cameras again to pick up calibration tests where I left off last year and would be happy to work with the Action Cam if someone has one they can send me for a week or two.

It looks like you've done a good job matching the NDVI index from the two cameras. It's hard to evaluate the meaningfulness of the NDVI images because 1) there is no RGB photo so I don't know what is healthy green plant and what is not, and 2) the color gradient used is not displayed.

I don't know whether finding a way to display plant health information with the HSV color wheel can be translated into applying a standard look up table for colors. Will each NDVI image created use a slightly different arc of the color wheel? That would make it hard to compare images.

I don't think the zero threshold between non-plant and plant NDVI values is important. Without a rigorous calibration procedure, consumer cameras will never put the NDVI values on the correct absolute numbers, and never scale them correctly. So stretching and sliding the values will usually be part of the process (that's part of what the custom white balance is doing). The key is having a device that allows quantifying the difference between NIR and visible light with some usable dynamic range. I can't tell if you have that or not.

What is the order of operations for javascript? I though division happened before addition. If so, your formulas are not like NDVI. So addition must come first (this is why I have to use so many parentheses).

Mathew only sent me one raw image:

Corrections made re: order of operations, thank you Chris for a sharp eye and a clearer memory of how to do basic arithmetic! And you said you couldn't code.

It's not AS good as it was. But I think it still works, and that I could've worked harder to get the images to match by using different stretches. Perhaps if we build a really solid levels-stretching interface, this can work. Thoughts?

Regarding HSV color wheel -- it's an imperfect way to do color mapping for a variety of reasons. Here, i used it because we can quickly get color within an Infragrammar approach. I think an Infragrammar version of linear colormapping, where you can map it to a lookup table, perhaps selected from a dropdown of different LUTs, would be much better and we should code that up pronto.

Is the levels stretching you are referring to the same thing as histogram stretching? If so, it should be high priority.

If the look up table feature gets incorporated into Infragrammar, maybe we should revisit the lut I have been using and promoting. To make it possible to interpret and troubleshoot everybody's NDVI results, it would be good to have a single lut. Otherwise, the NDVI images have limited meaning, especially because few people post a key to their NDVI images.

If there will be a single lut, it should be a good one. One shortcoming of the one I have been using is that it is not friendly to those with protanopia. Green represents low plant vigor and red represents high plant vigor, so the images are pretty useless to those with red-green color blindness.

Also, I wonder if making the threshold between plant and non-plant, which is currently at NDVI=0, closer to NDVI=0.1 would be better. With the current lut, green can be low vigor plant (0.1 to 0.2) or it can be non-plant (0.0 to 0.1).

Another useful thing is to have the 0 and 255 values distinct colors so you know if your protocol is producing lots of those values (which usually means there is a serious artifact creeping in). Here is a similar lut as above with white or black for the end members.