IIDC Camera Control Library

Hi Johann, all,

On Tue, 2004-10-05 at 00:00, Johann Schoonees wrote:
> Damien Douxchamps wrote:
>  > I did a major code cleanup of libdc, trying to get rid of the 
> historical
>  > bits that are now making the interface rather complex. The changes 
> break
>  > all compatibility. Obviously this is not a good thing to commit this to
>  > the CVS so you can grab a copy here:
>  >
>  > 
> http://www.tele.ucl.ac.be/PEOPLE/DOUXCHAMPS/ieee1394/libdc1394-cleanup.tar.gz
>  >
>  > The changes detailed below are mostly beautifications but also ease
>  > further developments (e.g. pass structures instead of individual args).
>  >
>  > This is by no means a definitive cleanup but rather a starting 
> point for
>  > further discussions on what version 2.0 should look like. Let's hear
>  > what you think about it.
>  >
>  > Changes:
>  > ...
> 
> Congratulations!  I agree that this is going in the right direction.
> 
> Having a handle for each camera is excellent.  It should be taken 
> further by hiding all the information in dc1394capture_t and other 
> structures inside the handle (the same way as raw1394 hides the 
> internal details of its raw1394handle_t inside a struct accessible 
> only through its pointer).

Hide the handle inside a struct, or hide a struct inside the handle? I
implemented the first solution because it seemed more flexible and less
obscure. What are the advantages of the second option?

> The major advantage of hiding the details of the handle structure and 
> only letting programmers use a pointer to it (together with a 
> comprehensive set of access functions that use the pointer) is that 
> developers are then free to change the implementation as radically as 
> necessary without breaking compatibility with the interface.

That's exactly why I did it. Plus, having fewer arguments helps newbies
and therefore promotes the use of the lib.

> Specifically, we should be looking forward to the day video1394 is 
> replaced by raw_iso.  If we define the interface well and choose 
> access functions that are not video1394-specific, we should be able to 
> slot in raw_iso without any visible changes to the external user.

Yes. But is raw_iso ever gonna come? ;-) 

> For example, a module called dc1394_bus could manage the IEEE 1394 bus 
> with functions like:
> 
> dc1394_handle * dc1394_bus_create(int *num_handles);
> void dc1394_bus_destroy(void);
> void dc1394_bus_reset(void);
> 
> dc1394_bus_create() returns an array of handles to all detected 
> cameras on all hosted IEEE 1394 buses (a broader version of 
> dc1394_get_camera_nodes()).  Other functions in the module can set and 
> get bus speed, etc.
> 
> Each handle is a pointer to a struct which is publicly declared in the 
> header as
> 
> typedef struct dc1394_bus_handle *dc1394_handle;
> 
> The user of the module does not need to know anything else about the 
> contents of the handle.  Just link with the module header and pass the 
> camera's handle pointer to every access function.
> 
> Other modules use the handles provided by the bus:
> 
> int dc1394_cam_create(const dc1394_handle c_handle);
> void dc1394_cam_destroy(const dc1394_handle c_handle);
> int dc1394_cam_reset(const dc1394_handle c_handle);
> 
> dc1394_cam_create() does the sorts of things currently done by the 
> dc1394_...setup_...capture() functions, and dc1394_cam_destroy() 
> includes things like dc1394_dma_release_camera().

Hummm... I still have to code those basic create/destroy functions.

Note that if the trend is to make a really totally big major phatt
rewrite of the structure/interface it would be nice to target
compatibility with the IIDC API specs from the start. I started a
project with a student (http://www.sf.net/projects/iidcapi) to port
libdc1394 to the IIDC API. This could be merged with libdc.

> Various access functions for get and set the number of DMA buffers, 
> image offset and size, pixel colour coding, frame rate, shutter, etc. 
>   For example:
> 
> int dc1394_set_image_size(const dc1394_handle c_handle, const int 
> width, const int height);

This is more or less the interface available in the tgz linked in my
previous email. :-)

> The examples above are from my Camwire interface (which is based on 
> libdc1394).  Camwire successfully insulates the user from lots of the 
> complexity of the IEEE 1394 and IIDC DCAM specs by selectively 
> presenting only generic camera functions like run/stop, frame rate, 
> shutter, etc.  It is therefore not suitable as a low-level library, 
> which is the job of libdc1394.

The best would be of course to have a single lib that would be easy to
use, yet allow tweaking if necessary. For example, node ID 63 is for
broadcast, but you can't pass it as argument with a simplified
interface. However, you can still hardcode camera->node=63 if you wish.
Or better, we could introduce flags somewhere.

Damien

-- 
  _    Damien Douxchamps
 ('-   PhD Student / Research Assistant
 //\   Image Processing Group, Communications Lab, UCL, Belgium
 V_/_  http://www.tele.ucl.ac.be/view-people.php?id=46

Damien Douxchamps wrote:
> On Tue, 2004-10-05 at 00:00, Johann Schoonees wrote:
>>Congratulations!  I agree that this is going in the right direction.
>>
>>Having a handle for each camera is excellent.  It should be taken 
>>further by hiding all the information in dc1394capture_t and other 
>>structures inside the handle (the same way as raw1394 hides the 
>>internal details of its raw1394handle_t inside a struct accessible 
>>only through its pointer).
> 
> 
> Hide the handle inside a struct, or hide a struct inside the handle? I
> implemented the first solution because it seemed more flexible and less
> obscure. What are the advantages of the second option?

Depends what you call the "handle".  In standard usage it is a pointer 
to a struct, the contents of which you may never know or need to know. 
  It is simple object-oriented programming.

For example:

In file mylib.h:
---------------
typedef struct handle *handle_t;  /* Note struct not defined here.*/
handle_t create(void);
void destroy(const handle_t h);
int one_of_many_access_funcs(const handle_t h, const int other_arg);

In file mylib.c:
---------------
#include "mylib.h"
typedef struct handle  /* Note struct defined here.*/
     int member;  /* For example.*/
     /* Define other handle members here.*/
};
handle_t create(void) {
     handle_t new_handle;
     new_handle = (struct handle *) malloc(sizeof(struct handle));
     /* Initialize handle members here, including allocating memory.*/
     return new_handle;
}
void destroy(const handle_t h) {
     /* Free memory allocated in create() here.*/
     free(h);
}
int one_of_many_access_funcs(const handle_t h, const int other_arg) {
     h->member = other_arg;  /* For example.*/
     /* Other low-level object access here.*/
     return 0;  /* Success.*/
}

The idea is that *all* access to the object is through the handle. 
The user need only read and include the header file mylib.h.  The 
access we currently have to structs like dc1394_cameracapture is 
considered poor style by many.

If mylib.c is pre-compiled and the source is not provided then the 
user may never be able to find out what is in the handle struct, nor 
should they need to.  This is a powerful information hiding mechanism 
which encourages stable interfaces.  There is much more support for it 
in C++.

> This is more or less the interface available in the tgz linked in my
> previous email. :-)

Yes, you are obviously already doing the "right thing". :-)  I am just 
making the philosophy explicit.

>>The examples above are from my Camwire interface (which is based on 
>>libdc1394).  Camwire successfully insulates the user from lots of the 
>>complexity of the IEEE 1394 and IIDC DCAM specs by selectively 
>>presenting only generic camera functions like run/stop, frame rate, 
>>shutter, etc.  It is therefore not suitable as a low-level library, 
>>which is the job of libdc1394.
> 
> 
> The best would be of course to have a single lib that would be easy to
> use, yet allow tweaking if necessary. For example, node ID 63 is for
> broadcast, but you can't pass it as argument with a simplified
> interface. However, you can still hardcode camera->node=63 if you wish.
> Or better, we could introduce flags somewhere.

A good way of doing it would be to have two or more libs, from very 
low-level to high-level.  The high-level libs call the low-level libs, 
which in turn talk to the hardware.  The user can then choose which 
level they want to enter on.

It is generally *not* a good idea to try and make one library do 
everything.  The Unix philosophy is for each tool to do one thing only 
and to do it well.  There is a recent tendency towards libs that 
include everything but the kitchen sink.  They tend to be hard to use 
and hard to maintain.

As a suggestion, how about putting all the low-level IIDC register 
access (and perhaps all the 1394 bus things like node 63) in one 
separately compiled library with a nice consistent interface.  Next to 
that put another low-level library which deals with everything to do 
with DMA, buffers and video1394.  Give it a general interface so that 
the innards can be replaced later if necessary.  Then build libdc1394 
on top of those two libraries.

Internally libdc1394 will look a lot cleaner and more organized as it 
calls the low-level functions, and for the user it can offer a 
powerful higher-level interface (perhaps based on IIDC API) 
uncluttered by low-level details.  Let other libraries like Camwire 
take care of higher-level point-and-shoot functionality.  And finally, 
let applications like Coriander provide the highest-level GUI's.

Then a user can (1) talk directly to camera registers, or (2) use 
video1394 DMA to access a non-IIDC device, or (3) talk to DCAM 
registers and control DMA directly [(1)+(2)], or (4) have simple 
control of any 1394 DCAM [libdc1394], or (5) 
I-want-to-use-a-camera-in-my-program [camwire], or (6) 
just-give-me-an-image [Coriander].  Just select the appropriate 
library or app.

Johann

-- 
Johann Schoonees                              Research engineer
Industrial Research Limited, PO Box 2225, Auckland, New Zealand
Phone +64 9 9203679 Fax +64 9 3028106 http://www.is.irl.cri.nz/
Camwire's home:  http://kauri.auck.irl.cri.nz/~johanns/camwire/

Reply to the mail from Johann Schoonees (j.schoonees@...):

> 
> Then a user can (1) talk directly to camera registers, or (2) use 
> video1394 DMA to access a non-IIDC device, or (3) talk to DCAM 
> registers and control DMA directly [(1)+(2)], or (4) have simple 
> control of any 1394 DCAM [libdc1394], or (5) 
> I-want-to-use-a-camera-in-my-program [camwire], or (6) 
> just-give-me-an-image [Coriander].  Just select the appropriate 
> library or app.

I do not see any advantage to the current state: We have libraw1394 for register access, video1394 for DMA and libdc1394 for IIDC camera access. 

To improve this, IMHO the right way would be to dump the video1394 ( which has a lot of problems ) in favor of a more generic raw_iso interface in libraw1394 ( ie.: DMA buffer fill mode with user pointers ), so we have one generic API for 1394 access. 

libdc1394 should provide ( still IMHO ) a flat abstraction to IIDC cameras, so you have get/set functions for the video format, properties and the like. This is for people who know their camera and are willing to write an application solely for an IIDC camera. 

But the main issue that remains is that we now have: libdc1394 for IIDC cameras, v4l and v4l2 for USB cameras and PCI grabbers, dv1394 for DV cameras, something else for DVB devices and maybe some proprietary libs for some specialized proprietary cameras. 
It is just impossible to write an application which interfaces with all of these devices. Every application has to know the devices it uses. Also with APIs which offer functions like "get_brightness" for the brightness property, "get_gain" for the gain property it is hard to impossible to write an application that interfaces with devices which supported set of properties vary a lot. 

We need something like Microsofts DirectShow: Something that completely abstracts from the hardware. If some of you have access to a Windows2000/XP system, you should try the "IC Capture" program which interfaces with DirectShow ( http://www.imagingcontrol.com ) - you can download a trial version to see how it works. 
( CAUTION/NOTE : I work for The Imaging Source so this is prejudiced. I do not want to advertise here but to give you an idea on the advantage of such an generic interface for the user ). If you have a Sony IIDC camera, you can also get a trial version of the driver to see how it works with windows ( again, prejudiced: I wrote the driver ;-) ). 
With this application ( and of course the SDK that was used to develop the app ), it simply does not matter what device you are using: IIDC cameras, PCI framegrabbers, webcams, DV devices... all look exactly likewise to the app. The app does not even have to have knowledge what properties are supported by the device. 

I think, this is something Linux needs to achieve. I try to get this functionality with my "unicap" library ( unicap.sourceforge.net ) - which still has some way to go. 


libdc1394/coriander is great, I use it a lot during development ( I could not imagine developing the firmware for our next generation camera without it ;-) ) but I currently only see it either in the use by other developers or by individuals, mainly at universities. It is still too hard to use for the average user, requires to much knowledge about the IIDC protocol and also the whole thing is too hard to install to the average user. 

I guess we can do little about the last point ( installation ) but if you compare the whole thing to Windows: On windows, you download the application and a driver package, double click the driver installation utility, double click the application setup -- and within a glance you are ready to go. 

With Linux, you need to figure where to get the package for your distro or need to know how to do a "configure && make && make install" and not only that, you need to install "libraw1394" first, then "video1394", then "libdc1394", then "coriander". Then you often have to check the permissions for "/dev/video1394" and "/dev/raw1394" to get it working. Then you need to setup "coriander" correctly for DMA capture sometimes even point it to the right "/dev" file, then eventually you manage to start the live video display ( and with some luck you get it then if you do not come along with some YUY2/UYVY issues like i did ;-) ). 


Ok, that was just my two cents ( and some comments about the daily life of a company who sells the camera and software ). 


 -Arne

On Thu, 2004-10-07 at 00:20, Johann Schoonees wrote:
> Damien Douxchamps wrote:
> > On Tue, 2004-10-05 at 00:00, Johann Schoonees wrote:
> >>Congratulations!  I agree that this is going in the right direction.
> >>
> >>Having a handle for each camera is excellent.  It should be taken 
> >>further by hiding all the information in dc1394capture_t and other 
> >>structures inside the handle (the same way as raw1394 hides the 
> >>internal details of its raw1394handle_t inside a struct accessible 
> >>only through its pointer).
> > 
> > 
> > Hide the handle inside a struct, or hide a struct inside the handle? I
> > implemented the first solution because it seemed more flexible and less
> > obscure. What are the advantages of the second option?
> 
> Depends what you call the "handle".  In standard usage it is a pointer 
> to a struct, the contents of which you may never know or need to know. 
>   It is simple object-oriented programming.

OK, I missed that generic definition of handle. So we're talking about
the same thing :-)

[snip]

> The idea is that *all* access to the object is through the handle. 
> The user need only read and include the header file mylib.h.  The 
> access we currently have to structs like dc1394_cameracapture is 
> considered poor style by many.

Restricting the access to the handle through a limited list of functions
is good, I missed that.

> If mylib.c is pre-compiled and the source is not provided then the 
> user may never be able to find out what is in the handle struct, nor 
> should they need to.  This is a powerful information hiding mechanism 
> which encourages stable interfaces.  There is much more support for it 
> in C++.

Good idea, but I would rather stick to C as my fluency in C++ is very
limited.

> Yes, you are obviously already doing the "right thing". :-)  I am just 
> making the philosophy explicit.

Yep, I was too implicit (and I was also missing some points ;-) )

> A good way of doing it would be to have two or more libs, from very 
> low-level to high-level.  The high-level libs call the low-level libs, 
> which in turn talk to the hardware.  The user can then choose which 
> level they want to enter on.
> 
> It is generally *not* a good idea to try and make one library do 
> everything.  The Unix philosophy is for each tool to do one thing only 
> and to do it well.  There is a recent tendency towards libs that 
> include everything but the kitchen sink.  They tend to be hard to use 
> and hard to maintain.
> 
> As a suggestion, how about putting all the low-level IIDC register 
> access (and perhaps all the 1394 bus things like node 63) in one 
> separately compiled library with a nice consistent interface.  Next to 
> that put another low-level library which deals with everything to do 
> with DMA, buffers and video1394.  Give it a general interface so that 
> the innards can be replaced later if necessary.  Then build libdc1394 
> on top of those two libraries.
> 
> Internally libdc1394 will look a lot cleaner and more organized as it 
> calls the low-level functions, and for the user it can offer a 
> powerful higher-level interface (perhaps based on IIDC API) 
> uncluttered by low-level details.  Let other libraries like Camwire 
> take care of higher-level point-and-shoot functionality.  And finally, 
> let applications like Coriander provide the highest-level GUI's.
> 
> Then a user can (1) talk directly to camera registers, or (2) use 
> video1394 DMA to access a non-IIDC device, or (3) talk to DCAM 
> registers and control DMA directly [(1)+(2)], or (4) have simple 
> control of any 1394 DCAM [libdc1394], or (5) 
> I-want-to-use-a-camera-in-my-program [camwire], or (6) 
> just-give-me-an-image [Coriander].  Just select the appropriate 
> library or app.

This looks like a good approach to me. Stripping video1394 from
libdc1394 would not be difficult (-> libvideo1394). Cleaning libdc1394
is a bit boring but should be done too. The big thing is then to make
the 'middle interface', aka camwire (or libiidcapi).

As there is this IIDC-API specs under way it would be nice (IMHO) to
target compliance with this standard from the start. The specs are
currently undisclosed (I had to sign an NDA) but I can try to open this
if there is a will to go in that direction (i.e. merge camwire and
libiidcapi to form a single IIDC-API middle-lib). 

Damien

-- 
  _    Damien Douxchamps
 ('-   PhD Student / Research Assistant
 //\   Image Processing Group, Communications Lab, UCL, Belgium
 V_/_  http://www.tele.ucl.ac.be/view-people.php?id=46

Hi Arne,

On Thu, 2004-10-07 at 10:05, Arne Caspari wrote:
> Reply to the mail from Johann Schoonees (j.schoonees@...):
> 
> > 
> > Then a user can (1) talk directly to camera registers, or (2) use 
> > video1394 DMA to access a non-IIDC device, or (3) talk to DCAM 
> > registers and control DMA directly [(1)+(2)], or (4) have simple 
> > control of any 1394 DCAM [libdc1394], or (5) 
> > I-want-to-use-a-camera-in-my-program [camwire], or (6) 
> > just-give-me-an-image [Coriander].  Just select the appropriate 
> > library or app.
> 
> I do not see any advantage to the current state: We have libraw1394
> for register access, video1394 for DMA and libdc1394 for IIDC camera
> access. 
> 
> To improve this, IMHO the right way would be to dump the video1394 (
> which has a lot of problems ) in favor of a more generic raw_iso
> interface in libraw1394 ( ie.: DMA buffer fill mode with user pointers
> ), so we have one generic API for 1394 access. 

<common open source lament>
This is of course the best, but who will do it? IIRC the ISO API has
been there for a while now.
</common open source lament>

> libdc1394 should provide ( still IMHO ) a flat abstraction to IIDC
> cameras, so you have get/set functions for the video format,
> properties and the like. This is for people who know their camera and
> are willing to write an application solely for an IIDC camera. 

This is my opinion too.

> But the main issue that remains is that we now have: libdc1394 for
> IIDC cameras, v4l and v4l2 for USB cameras and PCI grabbers, dv1394
> for DV cameras, something else for DVB devices and maybe some
> proprietary libs for some specialized proprietary cameras. 
> It is just impossible to write an application which interfaces with
> all of these devices. Every application has to know the devices it
> uses. Also with APIs which offer functions like "get_brightness" for
> the brightness property, "get_gain" for the gain property it is hard
> to impossible to write an application that interfaces with devices
> which supported set of properties vary a lot. 

If we have a good abstraction level above libdc1394 one could built a
lib that could handle a lot of different hardware. Obvious example:

GetBrightness(camera_t* camera, float* brightness)
{
	switch (camera->type) {
	case IIDC:
	case V4L:
	case ...
	}
}

Each 'case' statement would be filled with simple functions and the lib
would essentially be a big pile of switches. (there's probably a better
idea that this... ;-) )

> We need something like Microsofts DirectShow: Something that
> completely abstracts from the hardware. If some of you have access to
> a Windows2000/XP system, you should try the "IC Capture" program which
> interfaces with DirectShow ( http://www.imagingcontrol.com ) - you can
> download a trial version to see how it works. 
> ( CAUTION/NOTE : I work for The Imaging Source so this is prejudiced.
> I do not want to advertise here but to give you an idea on the
> advantage of such an generic interface for the user ). If you have a
> Sony IIDC camera, you can also get a trial version of the driver to
> see how it works with windows ( again, prejudiced: I wrote the driver
> ;-) ). 
> With this application ( and of course the SDK that was used to develop
> the app ), it simply does not matter what device you are using: IIDC
> cameras, PCI framegrabbers, webcams, DV devices... all look exactly
> likewise to the app. The app does not even have to have knowledge what
> properties are supported by the device. 
> 
> I think, this is something Linux needs to achieve. I try to get this
> functionality with my "unicap" library ( unicap.sourceforge.net ) -
> which still has some way to go. 

The Gran Plan would therefor be:

		APP
                 |
	     VIDEO_LIB
		 |
----------------------------------------------------
iidc-api       v4l      libdv      sane (?)      ...

It's a great thing but it's a huge task. I think the first thing to do
is to clean the libdc subtree (iow our own backyard first :-) ) so that
we can offer a nice interface and talk with other projects about a
common video lib that would provide basic support for every camera.

> libdc1394/coriander is great, I use it a lot during development ( I
> could not imagine developing the firmware for our next generation
> camera without it ;-) ) but I currently only see it either in the use
> by other developers or by individuals, mainly at universities. It is
> still too hard to use for the average user, requires to much knowledge
> about the IIDC protocol and also the whole thing is too hard to
> install to the average user. 

Of course. Just the fact that you have to push min. 3 buttons to get an
image in coriander is plain wrong (my fault here...) 

> I guess we can do little about the last point ( installation ) but if
> you compare the whole thing to Windows: On windows, you download the
> application and a driver package, double click the driver installation
> utility, double click the application setup -- and within a glance you
> are ready to go.

apt-get will give you more or less the same thing, but some stuff is
missing (like creating/setting devices I think)

> With Linux, you need to figure where to get the package for your
> distro or need to know how to do a "configure && make && make install"
> and not only that, you need to install "libraw1394" first, then
> "video1394", then "libdc1394", then "coriander". Then you often have
> to check the permissions for "/dev/video1394" and "/dev/raw1394" to
> get it working. Then you need to setup "coriander" correctly for DMA
> capture sometimes even point it to the right "/dev" file, then
> eventually you manage to start the live video display ( and with some
> luck you get it then if you do not come along with some YUY2/UYVY
> issues like i did ;-) ). 

BTW, some people now have problems with the CVS: their screen is purple!
So it seems you solved your problem but now we have some more. ;-) Any
SDL expert in the room?

Cheers,

Damien

-- 
  _    Damien Douxchamps
 ('-   PhD Student / Research Assistant
 //\   Image Processing Group, Communications Lab, UCL, Belgium
 V_/_  http://www.tele.ucl.ac.be/view-people.php?id=46

Damien Douxchamps wrote:
> On Thu, 2004-10-07 at 00:20, Johann Schoonees wrote:
>>A good way of doing it would be to have two or more libs, from very 
>>low-level to high-level.  The high-level libs call the low-level libs, 
>>which in turn talk to the hardware.  The user can then choose which 
>>level they want to enter on.
>>
>>It is generally *not* a good idea to try and make one library do 
>>everything.  The Unix philosophy is for each tool to do one thing only 
>>and to do it well.  There is a recent tendency towards libs that 
>>include everything but the kitchen sink.  They tend to be hard to use 
>>and hard to maintain.
>>
>>As a suggestion, how about putting all the low-level IIDC register 
>>access (and perhaps all the 1394 bus things like node 63) in one 
>>separately compiled library with a nice consistent interface.  Next to 
>>that put another low-level library which deals with everything to do 
>>with DMA, buffers and video1394.  Give it a general interface so that 
>>the innards can be replaced later if necessary.  Then build libdc1394 
>>on top of those two libraries.
>>
>>Internally libdc1394 will look a lot cleaner and more organized as it 
>>calls the low-level functions, and for the user it can offer a 
>>powerful higher-level interface (perhaps based on IIDC API) 
>>uncluttered by low-level details.  Let other libraries like Camwire 
>>take care of higher-level point-and-shoot functionality.  And finally, 
>>let applications like Coriander provide the highest-level GUI's.
>>
>>Then a user can (1) talk directly to camera registers, or (2) use 
>>video1394 DMA to access a non-IIDC device, or (3) talk to DCAM 
>>registers and control DMA directly [(1)+(2)], or (4) have simple 
>>control of any 1394 DCAM [libdc1394], or (5) 
>>I-want-to-use-a-camera-in-my-program [camwire], or (6) 
>>just-give-me-an-image [Coriander].  Just select the appropriate 
>>library or app.
> 
> 
> This looks like a good approach to me. Stripping video1394 from
> libdc1394 would not be difficult (-> libvideo1394). Cleaning libdc1394
> is a bit boring but should be done too. The big thing is then to make
> the 'middle interface', aka camwire (or libiidcapi).
> 
> As there is this IIDC-API specs under way it would be nice (IMHO) to
> target compliance with this standard from the start. The specs are
> currently undisclosed (I had to sign an NDA) but I can try to open this
> if there is a will to go in that direction (i.e. merge camwire and
> libiidcapi to form a single IIDC-API middle-lib). 

Yes, I think this is worth the discussion.

I am not sure what you mean by "cleaning libdc1394".  If you mean 
retaining only the low-level register access then, yes, we need a 
"middle" API for setting things up and providing some of the functions 
libdc1394 currently does (particularly DMA).

I am a little unsure of what exactly the IIDC-API is (or will be).  My 
initial assumption has been that it will define an interface that 
libdc1394 (or a "middle interface") could offer to higher-level libs 
and apps like Camwire and Coriander.

For me, the critical question is:  Does IIDC-API mention or assume 
things about IEEE 1394?  If it does, then in my opinion it belongs 
inside libdc1394 (or its successor).  If it is more generic (only 
mentions camera functions like start-stop, shutter speed, frame rate, 
etc) then it is on the same level as Camwire.

To get an idea of how Camwire differs from both libdc1394 and perhaps 
the IIDC-API, have a look at the two headers camwirebus.h and 
camwire.h.  There is no mention of IEEE 1394 in them.

For example, to set a shutter speed, the user calls 
camwire_set_shutter() with a float argument in seconds.  Internally, 
Camwire has to translate that (using a config file for the particular 
camera) into a shutter register value which it passes to 
dc1394_set_shutter().

Using the shutter example, if the IIDC-API expects a shutter register 
value, then it belongs in the 1394-IIDC world.  If it expects a time 
in seconds, then it belongs in the camera user's world and I would 
have no objection to merging Camwire with it.  (Of course the shutter 
is only one example.  One would have to look at the whole API to 
decide where it fits in.)

Johann

-- 
Johann Schoonees                              Research engineer
Industrial Research Limited, PO Box 2225, Auckland, New Zealand
Phone +64 9 9203679 Fax +64 9 3028106 http://www.is.irl.cri.nz/
Camwire's home:  http://kauri.auck.irl.cri.nz/~johanns/camwire/

Reply to the mail from Damien Douxchamps (damien@...):

> 
> <common open source lament>
> This is of course the best, but who will do it? IIRC the ISO API has
> been there for a while now.
> </common open source lament>

Maybe I'll start working on the lower level firewire drivers soon. They are way to unstable for production use ( they freeze alot! ).

Depends on how I can shift priorities though... :-P


> 
> The Gran Plan would therefor be:
> 
> 		APP
>                  |
> 	     VIDEO_LIB
> 		 |
> ----------------------------------------------------
> iidc-api       v4l      libdv      sane (?)      ...
> 
> It's a great thing but it's a huge task. I think the first thing to do
> is to clean the libdc subtree (iow our own backyard first :-) ) so that
> we can offer a nice interface and talk with other projects about a
> common video lib that would provide basic support for every camera.

I do not think it is a so big task. Given the short time I have to invest into unicap, it has already come a long way. It can talk to IIDC cameras, the DFG/1394 converter, v4l and v4l2 devices already. And for this I wrote the IIDC code myself ( it does not use libdc1394 ) and the DFG/1394 driver which makes a huge part of the code. The main remaining problems are the different color formats that need conversion to be able to be displayed and the different methods to access v4l. 

And what makes unicap also so difficult to implement are shortcomings in the v4l(2) drivers which do not even conform to the spec in some important points and nasty bugs/shortcomings in the 1394 driver stack.

The whole thing is not as complex as a DirectShow pendandt would be. DirectShow is a lot more but I do not thing the Graph/Filter aproach of DirectShow is that good.


> 
> apt-get will give you more or less the same thing, but some stuff is
> missing (like creating/setting devices I think)

apt-get is Debian, others will "emerge" or "urpmi" or something. At "The Imaging Source", we sometimes already have problems with customers who are not even able to extract a .zip archive. Ask such a guy about what distro he is using...! Yet alone write an installation instruction for every major distro and also test your installation on every major distro...


> > eventually you manage to start the live video display ( and with some
> > luck you get it then if you do not come along with some YUY2/UYVY
> > issues like i did ;-) ). 
> 
> BTW, some people now have problems with the CVS: their screen is purple!
> So it seems you solved your problem but now we have some more. ;-) Any
> SDL expert in the room?

The patch only completed what was already in the coriander code. There is a define, "YUVY" IIRC which switches between UYVY and YVYU for SDL. So people having issues with the display should either define "YVYU" or undefine it. The original code only excluded the byte-swap if "YUVY" was defined/undefined and I also included the creation of the overlay so that it corresponds to the byte swap. 

The correct way would have been to make a switch in the "Display" tab so users can switch the overlay byte order on the fly. I already thought about adding this patch also, but you know, the time...

 -Arne

Hi Johann,

On Mon, 2004-10-11 at 03:11, Johann Schoonees wrote:
> Yes, I think this is worth the discussion.
> 
> I am not sure what you mean by "cleaning libdc1394".  If you mean 
> retaining only the low-level register access then, yes, we need a 
> "middle" API for setting things up and providing some of the functions 
> libdc1394 currently does (particularly DMA).

I just think it's a good time to review the current interface,
structures,... to make the lib better and easier to use. I don't wish to
remove functionalities of libdc at this time. I would prefer a strong
polish and a quick release of an updated version.

> I am a little unsure of what exactly the IIDC-API is (or will be).  My 
> initial assumption has been that it will define an interface that 
> libdc1394 (or a "middle interface") could offer to higher-level libs 
> and apps like Camwire and Coriander.
>
> For me, the critical question is:  Does IIDC-API mention or assume 
> things about IEEE 1394?  If it does, then in my opinion it belongs 
> inside libdc1394 (or its successor).  If it is more generic (only 
> mentions camera functions like start-stop, shutter speed, frame rate, 
> etc) then it is on the same level as Camwire.

Yes it assumes the camera is an IIDC1394 camera. The IIDC capabilities
(like trigger modes,format7...) are too much far-fetched for the highest
level interface. The API keeps a relatively low level to allow all
functionalities.

> To get an idea of how Camwire differs from both libdc1394 and perhaps 
> the IIDC-API, have a look at the two headers camwirebus.h and 
> camwire.h.  There is no mention of IEEE 1394 in them.
>
> For example, to set a shutter speed, the user calls 
> camwire_set_shutter() with a float argument in seconds.  Internally, 
> Camwire has to translate that (using a config file for the particular 
> camera) into a shutter register value which it passes to 
> dc1394_set_shutter().

While this is certainly suitable for general purpose users (e.g.
webcams, simple video grabbing,...) I think libdc or iidcapi should
remain low-level for power users. *But* they should also aim to be as
simple as possible (simple structures and interfaces, only one way to
perform one action,...). I would favor the merge of libdc and iidcapi,
if the official API is flexible like libdc.

> Using the shutter example, if the IIDC-API expects a shutter register 
> value, then it belongs in the 1394-IIDC world.  If it expects a time 
> in seconds, then it belongs in the camera user's world and I would 
> have no objection to merging Camwire with it.  (Of course the shutter 
> is only one example.  One would have to look at the whole API to 
> decide where it fits in.)

The IIDC-API will expect a value, either register or absolute (if such
feature is supported by the camera). There is no will to include
databases of cameras in the API, and I think we should avoid that in
libdc too. I'm afraid such database will be difficult to maintain,
especially because the cameras have different firmware revisions.

It is thus obviously better if camwire remains separated from the
IIDC-API.

Damien

-- 
  _    Damien 'Takahara' Douxchamps
 ('-   Post-doctoral investigator
 //\   Image Processing Group, Nara Institute of Science and Technology
 V_/_  http://chihara.aist-nara.ac.jp/

Hello Arne,

On Tue, 2004-10-12 at 09:48, Arne Caspari wrote:
> Reply to the mail from Damien Douxchamps (damien@...):
> 
> > 
> > <common open source lament>
> > This is of course the best, but who will do it? IIRC the ISO API has
> > been there for a while now.
> > </common open source lament>
> 
> Maybe I'll start working on the lower level firewire drivers soon. They are way to unstable for production use ( they freeze alot! ).
> 
> Depends on how I can shift priorities though... :-P

I see I'm not alone... :-)

> > The Gran Plan would therefor be:
> > 
> > 		APP
> >                  |
> > 	     VIDEO_LIB
> > 		 |
> > ----------------------------------------------------
> > iidc-api       v4l      libdv      sane (?)      ...
> > 
> > It's a great thing but it's a huge task. I think the first thing to do
> > is to clean the libdc subtree (iow our own backyard first :-) ) so that
> > we can offer a nice interface and talk with other projects about a
> > common video lib that would provide basic support for every camera.
> 
> I do not think it is a so big task. Given the short time I have to invest into unicap, it has already come a long way. It can talk to IIDC cameras, the DFG/1394 converter, v4l and v4l2 devices already. And for this I wrote the IIDC code myself ( it does not use libdc1394 ) and the DFG/1394 driver which makes a huge part of the code. The main remaining problems are the different color formats that need conversion to be able to be displayed and the different methods to access v4l. 

Some color conversion functions can be found in coriander, but they
should of course be optimized in MMX/SSE.

> And what makes unicap also so difficult to implement are shortcomings in the v4l(2) drivers which do not even conform to the spec in some important points and nasty bugs/shortcomings in the 1394 driver stack.

Yes, I don't know about the V4L shortcomings but given the complexity of
IIDC I'm not surprised to see they don't plug together very well. Maybe
a way to fix that would be to have separate libs for capture and
control. The video (capture) pipe would be merged but not the control,
which could take the form of a plugin. This is not so far from the
coriander vloopback output, after all...

> The whole thing is not as complex as a DirectShow pendandt would be. DirectShow is a lot more but I do not thing the Graph/Filter aproach of DirectShow is that good.
>
> > apt-get will give you more or less the same thing, but some stuff is
> > missing (like creating/setting devices I think)
> 
> apt-get is Debian, others will "emerge" or "urpmi" or something. At "The Imaging Source", we sometimes already have problems with customers who are not even able to extract a .zip archive. Ask such a guy about what distro he is using...! Yet alone write an installation instruction for every major distro and also test your installation on every major distro...

Hehe, users are users, aren't they ;-)

> > > eventually you manage to start the live video display ( and with some
> > > luck you get it then if you do not come along with some YUY2/UYVY
> > > issues like i did ;-) ). 
> > 
> > BTW, some people now have problems with the CVS: their screen is purple!
> > So it seems you solved your problem but now we have some more. ;-) Any
> > SDL expert in the room?
> 
> The patch only completed what was already in the coriander code. There is a define, "YUVY" IIRC which switches between UYVY and YVYU for SDL. So people having issues with the display should either define "YVYU" or undefine it. The original code only excluded the byte-swap if "YUVY" was defined/undefined and I also included the creation of the overlay so that it corresponds to the byte swap. 
> 
> The correct way would have been to make a switch in the "Display" tab so users can switch the overlay byte order on the fly. I already thought about adding this patch also, but you know, the time...

Yeah, I thought about that too. It seems your patch revealed another
problem. I'll add the button 'ASAP'.

Damien

-- 
  _    Damien 'Takahara' Douxchamps
 ('-   Post-doctoral investigator
 //\   Image Processing Group, Nara Institute of Science and Technology
 V_/_  http://chihara.aist-nara.ac.jp/

Damien Douxchamps wrote:

>>And what makes unicap also so difficult to implement are shortcomings in the v4l(2) drivers which do not even conform to the spec in some important points and nasty bugs/shortcomings in the 1394 driver stack.
>>    
>>
>
>Yes, I don't know about the V4L shortcomings but given the complexity of
>IIDC I'm not surprised to see they don't plug together very well. Maybe
>a way to fix that would be to have separate libs for capture and
>control. The video (capture) pipe would be merged but not the control,
>which could take the form of a plugin. This is not so far from the
>coriander vloopback output, after all...
>  
>
The problem of vloopback is that the setup is only understandable for a 
small elite :-(

I already thought about a kernel mode driver for IIDC cameras ( should 
not be too hard taking the video converter driver ( 
sf.net/projects/video-2-1394 ( as a base because this way it would be 
loaded by hotplug, it would be seen by all mayor apps and ( a real 
benefit! ) it would be able to handle bandwidth allocation correctly - 
something almost impossible using raw1394.

But OTOH, soon it is possible to write a complete video capture 
application with a GUI etc. in less than 100 lines using unicap + 
unicapgtk -- so no need to bother with a v4l2 module ;-)

-Arne

I have not been paying much attention to this, but I just noticed...

>> > do is to clean the libdc subtree (iow our own backyard first :-) )
>> > so that we can offer a nice interface and talk with other projects
>> > about a common video lib that would provide basic support for every
>> > camera.

This has basically already been done with uberlibs like ffmpeg/libavformat
and frameworks like gstreamer, NMM, and surely others. libavformat
supports v4l and dv1394, and recently I ready about Roman working on
adding dc1394. Also, there is that lib that GnomeMeeting uses. I believe
the developers of these things are not interested in working on another
middle abstraction layer--they are the abstraction layer! I know ffmpeg is
always interested in ways to not add dependencies. Of course, you can do
what you want, and Arne's cam lib has scratched his itch and serves a real
purpose. I guess I am just trying to say, as friendly advice, not to
expect much in that direction. Maybe, rather, coordinate with the other
projects to add libdc1394 1.0 support.

Damien Douxchamps wrote:
> I just think it's a good time to review the current interface,
> structures,... to make the lib better and easier to use. I don't wish to
> remove functionalities of libdc at this time. I would prefer a strong
> polish and a quick release of an updated version.

I agree that there is not much point rewriting things just for kicks. 
  libdc1394 is now about as functional as its lower-level libraries allow.

> [Snip]
> 
> While this is certainly suitable for general purpose users (e.g.
> webcams, simple video grabbing,...) I think libdc or iidcapi should
> remain low-level for power users. *But* they should also aim to be as
> simple as possible (simple structures and interfaces, only one way to
> perform one action,...). I would favor the merge of libdc and iidcapi,
> if the official API is flexible like libdc.

So a good definition of the aim of libdc1394 might be to say that it 
provides simple access to all IIDC-defined capability as well as a few 
well-chosen functions for automating setting up and running a camera.

> 
> [Snip]
> 

For me, the biggest clumsiness in libdc1394 right now is the way in 
which one is forced to provide a complete list of arguments to get a 
camera set up.  The argument list ranges from very low-level details 
like raw1394 handle and node id, through middle-level things like 
packet and frame size, to high-level concerns like the DMA device file 
descriptor.  I think the frame transfer mechanism (DMA, raw access or 
whatever) should be set up separately from the camera handle and its 
registers.

A three-step set-up makes sense to me: (1) user gets a list of camera 
handles via raw1394 (after we hide the details of raw1394 handles and 
node ids inside our camera handle); (2) user chooses one of the camera 
handles (perhaps after looking at model name or ROM id) and 
initializes camera registers via a call through one of the camera 
handles; and (3) user chooses the frame transfer method (DMA etc) by 
calling the relevant set-up function.

I think libdc1394 paid a heavy price for DMA frame transfer.  It is 
bad enough that in Format 7 one has to set frame rates by tweaking the 
packet size (which in turn depends on the frame size).  With the added 
constraints imposed by fixed-size DMA buffer allocation, functions 
like dc1394_set_format7_image_size() and dc1394_set_format7_color_id() 
are simply booby traps.  One might as well replace their contents with 
memcpy(0,0,1) - segfault guaranteed.

I would be tempted to separate DMA concerns from the rest of the IIDC 
register access functionality.  The ideal would be to give the user 
robust ways of changing camera parameters independently of the 
frame-transfer mechanism.  For example, if you change the pixel coding 
id, and DMA has been set up, then the DMA buffer size should also 
change appropriately to give the user what they expect.

Regards,
Johann

-- 
Johann Schoonees                              Research engineer
Industrial Research Limited, PO Box 2225, Auckland, New Zealand
Phone +64 9 9203679 Fax +64 9 3028106 http://www.is.irl.cri.nz/
Camwire's home:  http://kauri.auck.irl.cri.nz/~johanns/camwire/

Guys,

First, if people think this kind of discussion is inappropriate for this 
forum please tell me. 

I work at Point Grey Research and we make 1394 cameras for computer 
vision.  We think libdc is great because it has allowed our few linux 
customers to get iidc cameras working under linux. 

What I would like to do is develop a collection of libdc-based example 
programs for our customers so they can get started using our cameras 
under linux more quickly and easily.  The thing is...

... its hard to put a real firm finger on it but it seems like the 
robustness of libdc/coriander has actually gotten worse since libdc 
0.9.3.  The problem with supporting linux (v.s. the "common 
alternative") is that there is such a wide selection of distributions as 
well as the presence of home-made kernels, that it makes support very 
difficult.  What we'd really like to be able to do is tell the customer 
: get libdc, get coriander, get them working, then we can talk.

These packages should work with our cameras.  Once the customer has 
verified that they do, we'll support them further with our processing 
libraries etc, but up till that point, its up to the customer to get the 
linux infrastructure working on his particular box/flavour/setup.

The catch is that its never that easy... people expect a certain amount 
of hand-holding.  I'm just trying to understand how much hand-holding 
will be required :)  To create a "test bed" for installation and running 
of this stuff I installed vanilla Fedora Core 1.  (Well, I tried with 
FC3 first but that proved a lot more difficult, what with the devices 
not even existing).  I am using libdc-1.0.0 and coriander-1.0.0.  I want 
to stick with non-CVS-tip builds because... well... supporting customers 
with CVS-tips I fear I'll be entering a world of pain.

I noticed that I can get my machine to lock up by transferring images in 
non-dma
(i.e. using raw1394 not video1394).  This isn't a big deal, but it 
points to possible instabilities.  I've had a lot of problems with 
customers using libdc 0.9.4 and 0.9.5 but 0.9.3 seemed a great 
release... I have good success telling people to back off to 0.9.3.  
(Note: I was using standard FC1 libraw(-devel)-0.9.0-12, maybe that is 
the problem?)

So.... my question to this list is:

- recommendations on which linux distribution is the best for 1394/libdc 
support (i.e. FC, SuSE, Ubuntu, etc)
- recommendations on whether we should try to support 2.6.x kernels 
now?  (for now I think I want to stick to 2.4.x)
- recommendations on whether it is reasonable to go with tagged releases 
(i.e. are things at the point where we don't have to use the CVS-tip?)
- general comments on the above issues and experiences
- any pitfalls / gotchas
- suggestions for other forums to discuss this if this isn't the right 
one :)

Thanks in advance,
Don Murray
 http://www.ptgrey.com

Hi Don,

On Wed, 2004-12-22 at 10:42, Don Murray wrote:
> Guys,
> 
> First, if people think this kind of discussion is inappropriate for this 
> forum please tell me. 

Discussing usability/stability is definitely appropriate ;-)

> I work at Point Grey Research and we make 1394 cameras for computer 
> vision.  We think libdc is great because it has allowed our few linux 
> customers to get iidc cameras working under linux. 

I'm also using ptgrey cameras and these work really well under linux.

> What I would like to do is develop a collection of libdc-based example 
> programs for our customers so they can get started using our cameras 
> under linux more quickly and easily.  The thing is...

Please consider adding the programs to libdc. We can never have enough
example programs...

> ... its hard to put a real firm finger on it but it seems like the 
> robustness of libdc/coriander has actually gotten worse since libdc 
> 0.9.3.  The problem with supporting linux (v.s. the "common 
> alternative") is that there is such a wide selection of distributions as 
> well as the presence of home-made kernels, that it makes support very 
> difficult.  What we'd really like to be able to do is tell the customer 
> : get libdc, get coriander, get them working, then we can talk.

You are actually the first one to report more problems with the recent
1.0.0 releases. Two weeks ago someone told me that
libdc-1.0.0/coriander-1.0.0 was the best combination he ever had. I
myself use the latest CVS without problems. I would therefore lean
towards installation/distro problems.

A year ago I built a floppy with all the necessary software for 1394
cameras to work with a Linux box. The thing included a script that
installed everything. I haven't updated it since but it was very
convenient: 
- insert floppy
- ./install
- enjoy!
This disk solved problems for another manufacturer. If you're interested
I can update it. The problem is that it does not 'educate' your
customer. It is sometimes better to install the packages manually so you
know what you're doing...

Anyway, FYI, here's what I use now:
- coriander CVS
- libdc1394 CVS
- libraw 0.10.0
- kernel 2.6.8.1, unpatched
- Debian Sarge ('testing')

This is running on two different machines: an IBM Thinkpad R40 and a
Dell Precision 370. The 1394 interfaces are either from TI (Thinkpad) or
VIA (Dell). Since others have experienced troubles with VIA chipsets I
would recommend TI.

> These packages should work with our cameras.  Once the customer has 

PTgrey cameras work really well under Linux. However, the Linux programs
rely on libdc which is not very fault tolerant. This can lead to
hangs/segfaults if the camera is not 100% compliant with IIDC. For
example, I had to update the firmware of a Dragonfly yesterday to have
it working with Format7 under Linux. It worked well with windows...

> verified that they do, we'll support them further with our processing 
> libraries etc, but up till that point, its up to the customer to get the 
> linux infrastructure working on his particular box/flavour/setup.

It is important for the developers to receive feedback on the problems
encountered in the field. Your customers are welcome to report them to
this list (or coriander list, see below). They should of course RTFM
before doing so ;-)

> The catch is that its never that easy... people expect a certain amount 
> of hand-holding.  I'm just trying to understand how much hand-holding 
> will be required :)  To create a "test bed" for installation and running 
> of this stuff I installed vanilla Fedora Core 1.  (Well, I tried with 
> FC3 first but that proved a lot more difficult, what with the devices 
> not even existing).  I am using libdc-1.0.0 and coriander-1.0.0.  I want 
> to stick with non-CVS-tip builds because... well... supporting customers 
> with CVS-tips I fear I'll be entering a world of pain.

Non CVS is definitely better. Regarding the distro, I don't think there
will be a lot of problems using another one because very few config
files are used (I can only think of /etc/ld.so.conf).

If the machine is used _only_ for 1394 cameras I would recommend not to
install the packages of the distribution but instead to compile/install
the packages manually. This way you don't have 2 different versions of
one program/lib on the machine and this avoids lots of tricky problems. 

> I noticed that I can get my machine to lock up by transferring images in 
> non-dma
> (i.e. using raw1394 not video1394).  This isn't a big deal, but it 
> points to possible instabilities.  I've had a lot of problems with 
> customers using libdc 0.9.4 and 0.9.5 but 0.9.3 seemed a great 
> release... I have good success telling people to back off to 0.9.3.  
> (Note: I was using standard FC1 libraw(-devel)-0.9.0-12, maybe that is 
> the problem?)

There is a problem with raw1394 capture in 0.9.4 and 0.9.5. It has been
fixed in 1.0.0.

> So.... my question to this list is:
> 
> - recommendations on which linux distribution is the best for 1394/libdc 
> support (i.e. FC, SuSE, Ubuntu, etc)

I would recommend Debian since that's what I use, but the installation
can be a real pain for beginners. Second choice would be FC... because I
used to work on RH machines. A friend of mine used Suse and we've never
been able to have 1394 working. A fresh 'debian upgrade' solved the
problem ;-) 

> - recommendations on whether we should try to support 2.6.x kernels 
> now?  (for now I think I want to stick to 2.4.x)

I use 2.6 for along time and I'm very happy with it. I don't know if the
advances made in the 1394 driver of 2.6 reach the 2.4 tree. It's
definitely worth a try since switching kernels is (relatively) easy

> - recommendations on whether it is reasonable to go with tagged releases 
> (i.e. are things at the point where we don't have to use the CVS-tip?)

Official releases are OK (i.e. libdc/coriander 1.0.0).

> - general comments on the above issues and experiences

see above ;-)

> - any pitfalls / gotchas

- watch out for multiple installations of a library/program. Better
install from sources and uninstall the packages.
- don't forget ldconfig
- add /usr/local/lib in /etc/ld.so.conf

> - suggestions for other forums to discuss this if this isn't the right 
> one :)

If the purpose is to have coriander working you can post on the
coriander-user list. There is also a coriander-devel for
bugs,patches,... (see http://www.sf.net/projects/coriander)

Damien

-- 
  _    Damien 'Takahara' Douxchamps
 ('-   Post-doctoral investigator
 //\   Image Processing Group, Nara Institute of Science and Technology
 V_/_  http://chihara.aist-nara.ac.jp/

Damien, thanks for the support!

Damien Douxchamps wrote:

>>What I would like to do is develop a collection of libdc-based example 
>>programs for our customers so they can get started using our cameras 
>>under linux more quickly and easily.  The thing is...
>>    
>>
>
>Please consider adding the programs to libdc. We can never have enough
>example programs...
>  
>

I was thinking of this.  For example, I have a modification of 
grab_gray_image.c that uses
DMA transfer that might be of interest.    I will let you know what I 
come up with.

>You are actually the first one to report more problems with the recent
>1.0.0 releases. Two weeks ago someone told me that
>libdc-1.0.0/coriander-1.0.0 was the best combination he ever had. I
>myself use the latest CVS without problems. I would therefore lean
>towards installation/distro problems.
>  
>
I had some problems in the past, so when I stumbled on this freeze 
behavior with
coriander, I became worried about whether it was just dumb luck or that 
the previous
issues had not been fixed.

The issue I have is that I do the following with a simple camera (in my 
case a Flea):
- put the grab device to RAW1394
- push the "start" transfer button
- hit "receive"

The fps goes up to around 7.5 and then my machine freezes, display, 
mouse and
keyboard.  VIDEO1394 works fine.  I haven't dug into it much, it could have
something to do with my h/w I suppose, but I have a good quality ASUS 
motherboard
and the entire system has been working flawlessly under XP for many months.

I can try to track down seg faults or crashes, but "box freezes" are a 
real bitch :)

BTW, after sending out that last email, I also did get a version of 
grab_gray_image
working for both DMA and non-DMA transfers with no freezes.  Tomorrow I
will try grabbing more frames.  If that works, then it might be more of 
a coriander
thing rather than a libdc thing.

>A year ago I built a floppy with all the necessary software for 1394
>cameras to work with a Linux box. The thing included a script that
>installed everything. I haven't updated it since but it was very
>convenient: 
>- insert floppy
>- ./install
>- enjoy!
>This disk solved problems for another manufacturer. If you're interested
>I can update it. The problem is that it does not 'educate' your
>customer. It is sometimes better to install the packages manually so you
>know what you're doing...
>  
>
Yes, I think I used that at that time.  It was very good.  I do agree 
with the
manditory education too though.  Right now I just want to make sure that I'm
comfortable with the process and then we can decide how much we want to
make the customer learn :)

>This is running on two different machines: an IBM Thinkpad R40 and a
>Dell Precision 370. The 1394 interfaces are either from TI (Thinkpad) or
>VIA (Dell). Since others have experienced troubles with VIA chipsets I
>would recommend TI.
>  
>
Oh.  Crap... I'll check my mboard - it might be VIA.

>PTgrey cameras work really well under Linux. However, the Linux programs
>rely on libdc which is not very fault tolerant. This can lead to
>hangs/segfaults if the camera is not 100% compliant with IIDC. For
>example, I had to update the firmware of a Dragonfly yesterday to have
>it working with Format7 under Linux. It worked well with windows...
>  
>
Yes, I hear you.  There are definitely improvements we can make towards 
100% compliance.
This is one reason, BTW, why I think using libdc is a good idea... it 
may help educate
PGR in where we are getting sloppy.


>If the machine is used _only_ for 1394 cameras I would recommend not to
>install the packages of the distribution but instead to compile/install
>the packages manually. This way you don't have 2 different versions of
>one program/lib on the machine and this avoids lots of tricky problems. 
>  
>
I agree that if they need to upgrade an existing package they should 
either make sure they
delete the old one, or, as you say, not install it in the first place.

>I would recommend Debian since that's what I use, but the installation
>can be a real pain for beginners. Second choice would be FC... because I
>used to work on RH machines. 
>
Our distribution of choice was FC, but I've heard a lot of murmurings 
that FC is
losing favour in the linux community, which worried me.  But it sounds 
like the
distribution is probably not that critical.

>>- recommendations on whether we should try to support 2.6.x kernels 
>>now?  (for now I think I want to stick to 2.4.x)
>>    
>>
>
>I use 2.6 for along time and I'm very happy with it. I don't know if the
>advances made in the 1394 driver of 2.6 reach the 2.4 tree. It's
>definitely worth a try since switching kernels is (relatively) easy
>  
>
Ok.  I will try to test both FC1 and FC3.   I just got scared off by the 
"udev" stuff which
I am completely unfamiliar with.  Time to learn.

>- don't forget ldconfig
>- add /usr/local/lib in /etc/ld.so.conf
>  
>
I was planning to recommend using ./configure --prefix=/usr so the libs are
where they are expected.  Bad idea?

Anyway, thanks for all the feedback, Damien!

Don

Hi Don,

On Wed, 2004-12-22 at 14:34, Don Murray wrote:

[snip]

> I had some problems in the past, so when I stumbled on this freeze 
> behavior with
> coriander, I became worried about whether it was just dumb luck or that 
> the previous
> issues had not been fixed.
> 
> The issue I have is that I do the following with a simple camera (in my 
> case a Flea):
> - put the grab device to RAW1394
> - push the "start" transfer button
> - hit "receive"
> 
> The fps goes up to around 7.5 and then my machine freezes, display, 
> mouse and
> keyboard.  VIDEO1394 works fine.  I haven't dug into it much, it could have
> something to do with my h/w I suppose, but I have a good quality ASUS 
> motherboard
> and the entire system has been working flawlessly under XP for many months.

In coriander, the RAW1394 capture is much simpler than VIDEO1394. If
video1394 works but not raw1394 the problem is at a lower level: libdc
or kernel.

For video1394, don't forget to choose a buffer size of at least 4
frames. 

> I can try to track down seg faults or crashes, but "box freezes" are a 
> real bitch :)

The problems in coriander that could lead to a frozen box are limited.
In fact, I can only think of a display problem (overflow of the overlay
size). Sometimes it can be recovered by accessing the basic shells
(CTRL-ALT-F1,2,...). Coriander can still produce other frozen cubes, but
IMHO the cause is rather at a lower level.

> BTW, after sending out that last email, I also did get a version of 
> grab_gray_image
> working for both DMA and non-DMA transfers with no freezes.  Tomorrow I
> will try grabbing more frames.  If that works, then it might be more of 
> a coriander
> thing rather than a libdc thing.

Interesting clue...

> >A year ago I built a floppy with all the necessary software for 1394
> >cameras to work with a Linux box. The thing included a script that
> >installed everything. I haven't updated it since but it was very
> >convenient: 
> >- insert floppy
> >- ./install
> >- enjoy!
> >This disk solved problems for another manufacturer. If you're interested
> >I can update it. The problem is that it does not 'educate' your
> >customer. It is sometimes better to install the packages manually so you
> >know what you're doing...
> >  
> >
> Yes, I think I used that at that time.  It was very good.  I do agree 
> with the
> manditory education too though.  Right now I just want to make sure that I'm
> comfortable with the process and then we can decide how much we want to
> make the customer learn :)

I'll try to update it. If for nothing else you can see the detailed step
of the installation by reading the script.

> >This is running on two different machines: an IBM Thinkpad R40 and a
> >Dell Precision 370. The 1394 interfaces are either from TI (Thinkpad) or
> >VIA (Dell). Since others have experienced troubles with VIA chipsets I
> >would recommend TI.
> >  
> >
> Oh.  Crap... I'll check my mboard - it might be VIA.

You can put a second card in your computer and see if connecting the
camera to one card or the other changes something.

> >PTgrey cameras work really well under Linux. However, the Linux programs
> >rely on libdc which is not very fault tolerant. This can lead to
> >hangs/segfaults if the camera is not 100% compliant with IIDC. For
> >example, I had to update the firmware of a Dragonfly yesterday to have
> >it working with Format7 under Linux. It worked well with windows...
> >  
> >
> Yes, I hear you.  There are definitely improvements we can make towards 
> 100% compliance.
> This is one reason, BTW, why I think using libdc is a good idea... it 
> may help educate
> PGR in where we are getting sloppy.

LOL ;-)

> >If the machine is used _only_ for 1394 cameras I would recommend not to
> >install the packages of the distribution but instead to compile/install
> >the packages manually. This way you don't have 2 different versions of
> >one program/lib on the machine and this avoids lots of tricky problems. 
> >  
> >
> I agree that if they need to upgrade an existing package they should 
> either make sure they
> delete the old one, or, as you say, not install it in the first place.
> 
> >I would recommend Debian since that's what I use, but the installation
> >can be a real pain for beginners. Second choice would be FC... because I
> >used to work on RH machines. 
> >
> Our distribution of choice was FC, but I've heard a lot of murmurings 
> that FC is
> losing favour in the linux community, which worried me.  But it sounds 
> like the
> distribution is probably not that critical.

Certainly not critical. It's better that the user keeps the distro he's
familiar with.

> >>- recommendations on whether we should try to support 2.6.x kernels 
> >>now?  (for now I think I want to stick to 2.4.x)
> >>    
> >>
> >
> >I use 2.6 for along time and I'm very happy with it. I don't know if the
> >advances made in the 1394 driver of 2.6 reach the 2.4 tree. It's
> >definitely worth a try since switching kernels is (relatively) easy
> >  
> >
> Ok.  I will try to test both FC1 and FC3.   I just got scared off by the 
> "udev" stuff which
> I am completely unfamiliar with.  Time to learn.

Don't know much about it either...

> >- don't forget ldconfig
> >- add /usr/local/lib in /etc/ld.so.conf
> >  
> >
> I was planning to recommend using ./configure --prefix=/usr so the libs are
> where they are expected.  Bad idea?

Not a bad idea...

Damien

-- 
  _    Damien 'Takahara' Douxchamps
 ('-   Post-doctoral investigator
 //\   Image Processing Group, Nara Institute of Science and Technology
 V_/_  http://chihara.aist-nara.ac.jp/

The linux 1394 stack is not too stable in some conditions. There are 
apparently a few occasions that may freeze the entire machine especially 
if you kill a thread while it waits for a IEEE-1394 call to return.

video1394 also has severe bugs. It is possible that the reception with 
video1394 suddenly stops and can only be restarted by shutting down the 
isoch reception and setting it up from fresh again.

Other problems are that one can not unload IEEE1394 modules: "rmmod" 
blocks. This might not affect a running system - it just makes driver 
development a pain :-(

Also I noticed that some devices can not start isochronous transmission 
under Linux where it works with windows.

And finally I encounter bus-reset storms with Linux which also renders 
the 1394 stack unusable.

And if you compare to Windows, you will find some other minor issues: 
You can not DMA to user-provided buffers and a good bandwidth management 
is lacking.

+++
BUT:

If you have a stable system setup, then linux1394 might work very well 
for you. I solved many tasks during the development of the firmware of 
our devices with the linux stack and these tasks would have took much 
longer time to resolve using Windows.
( I emphasized this statement so that the linux1394 developers do not 
get too embarassed :-) )
+++



I currently dedicated all my square time in investigating these 
problems. Hopefully I can come up with some solutions soon.

But I currently have not a too good feeling in recommending Linux for 
firewire devices in production systems to customers. ( This is backed at 
least by some experience since "customers" means the customers of The 
Imaging Source ;-) ).


  /Arne

>>BTW, after sending out that last email, I also did get a version of 
>>grab_gray_image
>>working for both DMA and non-DMA transfers with no freezes.  Tomorrow I
>>will try grabbing more frames.  If that works, then it might be more of 
>>a coriander
>>thing rather than a libdc thing.
> 
> 
> Interesting clue...
> 

I bet those are just race conditions. So they might or might not appear 
in the current situation / with the current software / with the current 
system.

I also got those freezes with my video-2-1394 driver so I guess at least 
some of the roots of these problems are below "raw1394".

I can reproduce them somewhat whith my "raw1394" based solution.


  /Arne

Arne, thanks for the information and recommendations (and warnings :))

Arne Caspari wrote:
<snip>

> But I currently have not a too good feeling in recommending Linux for 
> firewire devices in production systems to customers. ( This is backed 
> at least by some experience since "customers" means the customers of 
> The Imaging Source ;-) ).

Do you know of an alternative, btw?

Don

On Thu, 2004-12-23 at 02:55, Don Murray wrote:
> Arne, thanks for the information and recommendations (and warnings :))
> 
> Arne Caspari wrote:
> <snip>
> 
> > But I currently have not a too good feeling in recommending Linux for 
> > firewire devices in production systems to customers. ( This is backed 
> > at least by some experience since "customers" means the customers of 
> > The Imaging Source ;-) ).
> 
> Do you know of an alternative, btw?

I worked for a company that uses PtGrey cameras for production systems.
My experience is that once it works, it works forever. Linux was the
perfect choice since the application would be running almost 12/7/365
2000km away. The whole thing is to find a stable config (kernel, libs,
application). I remember having hard times upgrading kernels on these
machines because the 1394 drivers would sometimes not work anymore.
Nevertheless, the company recommends to use Linux for 1394 even though
they offer a windows version too. Maybe it's because I was there to do
the support ;-)

Damien

-- 
  _    Damien 'Takahara' Douxchamps
 ('-   Post-doctoral investigator
 //\   Image Processing Group, Nara Institute of Science and Technology
 V_/_  http://chihara.aist-nara.ac.jp/