Wrapper for VCSM library (for lens shading)

[rwb27]

I'm keen to be able to tweak my lens shading parameters via python. I think I have learned my way around the MMAL stuff well enough to do this (for example, I've successfully controlled analog and digital gain) but looking at 6by9's lens shading example in C it looks like I'll need the VideoCore shared memory library which is not currently wrapped by picamera.

I would happily give this a go if what's required is someone to wrap it - but I thought I'd ask here first in case it's already done elsewhere or it would be a bad idea for some reason I've not thought of...

[waveform80]

Lens shading (at least a straight-forward enable/disable switch) was definitely one of the things I wanted to include in 1.14. Looks like this does considerably more, but makes lens-shading seriously useful. Thanks for the link; I'll mark it for 1.14 for now but I can't promise I'll have time to include everything!

[waveform80]

P.S. if you fancy bunging together a PR for a VCSM translation, that'd certainly save me some time!

[rwb27]

Do you mean just user_vcsm.py and vcsmobj.py? I think it's just a matter of adding those two files, so that's done in #514. I'll put together a documentation page in the style of mmalobj as well, as I guess that's probably needed. I'll follow the example of the mmal header conversion and not add API docs for that, unless I should?

By the way, are those header conversions done automatically somehow? I did mine by hand, I'd be curious to know if I missed a handy tool somewhere!

[waveform80]

Heh - I hadn't realized at the time of writing my initial response above that you'd actually provided a huge PR (#470) with basically everything necessary in it :) And then completely forgot to correct myself on this ticket!

Anyway, I'm going to review that but given it's quite large I'm just ploughing through all the small fry I can first before getting to the seriously big stuff like this. I do promise it'll be going into 1.14 though - it was the major goal I had in mind (before being amazed that most of the stuff I'd wanted to do was just sitting in PRs for me!)

I'll put together a documentation page in the style of mmalobj as well, as I guess that's probably needed. I'll follow the example of the mmal header conversion and not add API docs for that, unless I should?

If you really want to, that'd be fabulous - I'm planning on adding quite a few mmalobj examples in this cycle as it seems to be garnering some interest. And yes, no need to document the actual header conversion - my attitude there is "if you need the raw header ... why not just use C?". There'll probably wind up being some documentation of certain constants (where they get used in mmalobj) but I've no particular ideas where yet.

By the way, are those header conversions done automatically somehow? I did mine by hand, I'd be curious to know if I missed a handy tool somewhere!

I wish! My original MMAL translation was helped by judicious use of some vim macros, but was basically a hand-cranked effort (took a few hours as I recall). Now that there's the odd minor change to keep up with I just diff the upstream headers during each release cycle and tweak the bits that need it (usually one or two constants need adding and that's about it).

[rwb27]

Ah, sorry, I got a bit mixed up between the PRs and the issues - I had actually forgotten I'd raised this, I should have referenced my PR here and saved the confusion! All the code in #514 is included in #470 but I'll finish the documentation (I'm about halfway through it) and add it in to both. Let me know whether you'd prefer bite-size PRs or if it will be easier just to pull in the lot at once!

[rwb27]

I do have a couple of style/convention questions though, which I may as well ask before you trawl through the code in case it saves some time:

1. Currently, the shared memory is allocated in the __init__ method of my wrapper class, and freed in the __del__ method. This seems to me to be a very sensible way of doing it. However, it does mean that the memory is only freed when the object gets garbage collected. I doubt very much this will be an issue when used for lens shading, but if it gets used more widely, perhaps a context manager that explicitly frees the block when you're done would be safer? I don't think that's a big change, but I thought I'd ask first - using a context manager to do memory management feels a bit like it misses the point of a high level language like Python!

2. The VCSM library needs to be initialised and closed, I think this should only happen once. I have not found a consensus on how to do this in Python, so my slightly kludgy solution (tested with some print statements and seemingly OK) is to initialise and shut down the library in an object - this object is created the first time it's needed and stored in a module-level global, and the library is shut down by the garbage collector in the __del__ method of the object. Again, I think this is OK but I would love to know if there is a better, more reliable, or neater way to do it.

[rwb27]

Having just re-Googled these two issues, I should probably correct myself, I realise that, if everything goes correctly, it's technically not the garbage collector's job, but should be handled by reference counting. Nonetheless, it's not infallible, and several folk on stack overflow think a context manager is the neatest way to do this.

Also, I now remember that I looked at atexit and was somewhat put off by the warnings on the Python 2 version of the module, that it might not work. These aren't present in the Python 3 version, and as the world is fast abandoning 2, maybe I should get rid of my class, and use atexit instead. I suspect that would be neater, though I'll probably still end up using a variable to check the module has been initialised.