Thinking about what needs to be done to wrap up the C code changes for 1.4 release. This is a long post and is partly just to get my own thoughts in order, but any feedback would be appreciated.
Code organizationCurrently, the code is built into the Lua script module. It depends on the scripts hooks, which are also built into the same module.
Originally, I was going to put the raw manipulation code in it's own module, but currently a large fraction of code is Lua interface "glue".
The glue can't be in a separate .flt, because there's no convenient way to export the Lua API from the main Lua module to another. This is something I'd like to address in the future, but not for 1.4
The rawop code adds a few kb to the Lua module, which I think is acceptable. If significantly more non-glue code is added, it should probably be split out. There are also possible uses for raw manipulation outside of script, which would also argue for splitting it out.
Error handlingCurrently, the code doesn't check if you are in the raw hook, or if a valid raw buffer is available in the current mode (IE cameras that don't have raw in auto, or binned modes with low res raw).
* IMO it should, since writing outside of these conditions could be fatal
* OTOH the hook could time out while a long running call is in progress so it will never be completely safe.
* If a function is called when raw is not valid, should it error(), or just ignore the call? I'm inclined to use error. This means scripts will terminate if the hook timeout is too short, but script writers should use generous timeouts.
* The overhead of error checking itself could be a concern for functions like get_pixel and set_pixel. My current plan is to set / clear a flag on hook entry / exit
* a related question is how to handle invalid coordinates etc. The current code clamps/ignores calls that would fall outside the frame buffer, and I'm inclined to leave it this way.
G1x blacklevel issueI don't really want to change the code a lot to deal with quirks in the one camera, especially since the ISO issues aren't really resolved. However, we will probably run into other cameras with quirks later.
* values associated raw "neutral" needs to be re-calculated when black level changes.
* a callback on entry into the hook could be used to re-calculate the values.
* scripts will no longer be able to pre-calculate values before shooting, which is inconvenient
* fb_info is not well suited to values changing on the fly. It's possible that other values could change at runtime in the future so this should probably be converted to individual calls. This may make it less convenient to write efficient lua code, but C calls shouldn't be worse than a table lookup.
meter interfaceThe valid meter step and count values are limited by overflow, and the limits depend on sensor bit depth. It would be possible to make a higher level function that makes multiple meter calls and averages them, but in practice I haven't found it to be a problem.
shot_histogram vs rawop histogramSince shot_histogram is now a module, and is also available in ubasic, I'm inclined to leave it alone.
combined meter and histogramIf you want both a histogram and average value from a given area of the screen, getting the average from the histogram could be much more efficient, since reading large numbers of pixels is slow. However, I haven't come up with a good way to do this without either risking integer overflow, or using FP or 64 bit math.
Additional drawing functionsSome things I originally had in mind were
* arbitrary lines
* ellipses
* text
I'm inclined to skip the first two for 1.4, since I haven't found myself needing them. If someone *really* wants they could implement them in lua with set_pixel, and if there is demand, they can be added for 1.5
Text seems potentially more useful.
* People have requested things like date stamps before, and putting text on the image could be convenient for debugging.
* Adding date stamp functionality implies that some of the code must be outside of the script module
* Reusing the CHDK font infrastructure looks like it would be complicated, especially if you don't use the current OSD font.
* For numbers, you could a 7 segment display style output pretty easily with the current code.
* It would be possible to do simple text entirely from Lua too.
Other functionsSome other stuff I've thought about, but am not planning to implement for 1.4
* some kind of color matrix interface, to allow scripts to work in roughly correct RGB
* allow script to efficiently load/save chunks of the raw buffer
rawops in binned modesA long time ago, srsa_4c investigated the the raw buffer for some half-res low light modes:
http://chdk.setepontos.com/index.php?topic=10648.10At the time, we concluded that it wasn't worth pursing since the quality was low, but having it available for rawops could be quite useful. Metering and histogram don't depend on quality, and these modes typically shoot very fast, so people making timelapse for find the quality vs speed trade acceptable. If your final output is significantly smaller than the binned resolution, the quality loss is probably not a big deal. I'm not planning to pursue this for 1.4, but it argues for structuring the code to support varying raw size in the future.
