[pydc1349] Jordens Branch

[SirVer]

Hi all,

I want to post my impressions of jordens branch here. I think that I
will essentially go through his code and copy & paste back the stuff
that I like about it into camera.py. There is some stuff that makes me
reluctant to merge it right away, so I start with them. Hera are my

Cons)
* Something is broken with my cameras. All of the examples only
produce garbage and the display_qt.py program displays a broken image.
I can't say what the problem is atm.
* The test suite no long runs. It seems as if jordens switched the
image dimensions from height as dimension 0 (numpy style) to width is
dimension 0.
* The camera2.py wrapping is more complete than camera, but less
pythonic (imho). There is nearly a one-to-one mapping between setters/
getters and pydc functions. While I agree that this is desirable, I
still feel that we lost something in the process.
* I was unable to acquire frames (even broken ones) in free running
mode. What I like to do is have a camera running inside a ipython
process, then tweak the settings and take a look at
camera.current_image. This is no longer possible with camera2 if I am
correct. The threaded_camera.py module does not work, it seems like
some function got a new name while this was changed.
* decorator properties destroy compatibility, but I am unsure to which
version. I'd like to keep >= python 2.6 supported.

Okay, the new stuff is nice in some other areas. Here is the stuff
that I liked particularly:

* Frame class as returned by dequeue. It is very similar to the Image
class though.
* Feature class and the subclassing for specialized features.
* Mode class + Format 7 subclass. I found it a bit cumbersome to use
(esp. Mode.rates), but I have no better idea how to handle it.
* Sphinxdoc documentation. Actually, I just added a basic one to
trunk. Jorden is way ahead here.
* Refactoring.

okay, so as stated, I will likely not merge jordens work, but copy &
paste or replay commits on top of the main trunk. I will try to
directly add tests to all the feature that I add into the camera as
far as my cameras support it.

So, these are my plans. Good work jordens!

Cheers,
Holger

[Tomio]

A couple questions/notes, which are bothering me here:

1.) breaking up the code brings in plenty of python function calls
over the C calls. Is there any speed cost we have to pay for this?

2.) one of the nice simplifications to the end user was the
unification of the video modes with the FORMAT7 modes, as long as no
ROI was involved. Now this is again pulled apart, transfering this
work to be done in all implementations. I pretty unhappy about this,
since it only complicates life, though it is the same as the dc1394 C
lib worked. Should we stick to dc1394 functionwise or do we implement
the functionality of it?

3.) as far as I remember (I may be wrong): the Frame.corrupt() needs
the frame still dequeued, which may give a bit of time cost. And to
me, fast data streaming is important to some applications.

4.) in the Frame class:
- the init swaps height and width, which may cause problems; For me,
so far the other way around worked fine.
- the _cam can be used to see if the library is still opened. Though
the conversion may throw an exception for a couple of other reasons...
8)
- the __array_finalize is indeed nicer this way 8)
- __array_wrap__ is missing, which may be needed / or not, but if we
drop it, we need a good reason... (it inherits the extra parameters
after ufunc calls of numpy)
- why to take away the enqueue from the camera capture? I think it
is safer to do it there than here, and also it sounds more logical to
me.