Hi Damien,
IIRC a general rule of thumb is that if the list is subscribers-only and
relatively low-volume, it can be "reply-to-list", because the subscriber
will get the list emails anyway and can quickly look over it.
Markus
Damien Douxchamps schrieb:
>Hi all,
>
>List member Cadgas proposed to set a default reply-to-list field instead
>of the current reply-to-original-poster. This would avoid receiving
>emails twice when someone replies to you as well as avoid unintentional
>out-of-list discussions.
>
>Although I would also favour this option, it may lead to some tricky
>situations that are not too difficult to imagine as the reply will be
>broadcast to everyone by default.
>
>Let's hear your comments about this change, if you have any. If there is
>no strong opposition I will switch to a default "reply-to-list"
>behaviour within a week or so.
>
>Damien
>
>
>

On 31/03/06 06:38:55, Damien Douxchamps wrote:
> Let's hear your comments about this change, if you have any. If there
> is no strong opposition I will switch to a default "reply-to-list"
> behaviour within a week or so.
Personally, I almost always use this, despite mailman's rather strong =20
warning to the contrary. It's much easier to be able to just hit reply.
Cheers,
--=20
Ali Harlow Email: ali@...
Senior Research Officer Tel: (020) 7040 4348
Applied Vision Research Centre Intl: +44 20 7040 4348
City University Fax: (020) 7040 5515
London Intl: +44 20 7040 5515

Hi all,
List member Cadgas proposed to set a default reply-to-list field instead
of the current reply-to-original-poster. This would avoid receiving
emails twice when someone replies to you as well as avoid unintentional
out-of-list discussions.
Although I would also favour this option, it may lead to some tricky
situations that are not too difficult to imagine as the reply will be
broadcast to everyone by default.
Let's hear your comments about this change, if you have any. If there is
no strong opposition I will switch to a default "reply-to-list"
behaviour within a week or so.
Damien
--
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, NAIST
V_/_ http://chihara.aist-nara.ac.jp/

On Tue, 2006-03-28 at 14:04 +0200, Cagdas Ogut wrote:
> if you need mirror'ing in live cell imaging, AVT cameras usually have a
> mirroring fuction built in. Check with the manual before you buy. They
> are German made and relatively less expensive in EU.
Best of all, AVT extra features are supported in libdc1394. :-)
> Cagdas
>
> P.S.: what about adding a Reply-To: field to list mails?
It is in general considered dangerous (imagine replying to the original
poster "OMG! This guy sucks!", only to realize afterwards that it was
sent to _everybody_). I'll start a small thread and ask for
comments/votes.
Damien
--
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, NAIST
V_/_ http://chihara.aist-nara.ac.jp/

Hi Jack,
On Wed, 2006-03-29 at 12:35 -0800, Jack Morrison wrote:
> I'm using libdc1394-2.0.0-pre5 on a PowerPC Linux 2.6 system.
> I have observed an apparent problem with dc1394_find_cameras()
> in dc1394_control.c - some unused connections to the 1394 device
> aren't/can't be released, until the process exits.
>
> If the call to dc1394_get_camera_info(tmpcam)
> returns an error, there is disabled cleanup code. Even if
> that code were enabled, it would not help in our case where
> e.g. a hub returns with DC1394_NOT_A_CAMERA.
>
> I believe the correction is to add an "else" clause
> corresponding to (line 167):
>
> if (err == DC1394_SUCCESS) { // is it a camera
>
> which does (line 193)
>
> } else {
> dc1394_free_camera(tmpcam);
> }
>
> I occasionally have camera operations fail in a manner
> that can only be cleared by removing and reloading the
> 1394 kernel modules. Without this fix, the modules
> can't be removed from the main capture application,
> as it reports "resource busy".
>
> I'd like to suggest that this be added to the official
> source.
Good suggestion indeed :)
I will commit that as soon as the CVS system of SF is back online.
Damien
--
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, NAIST
V_/_ http://chihara.aist-nara.ac.jp/

Hi James,
On Thu, 2006-03-30 at 18:16 -0500, James Sherman Jr. wrote:
> Thanks for responding Damien.
>
> Damien Douxchamps wrote:
> >
> > Why do you ask for the supported video modes if the video mode that you
> > select is hardcoded anyway?
> >
> This was just left in for experimentation reasons.
> >> // setting device name
> >> snprintf(device_name, 255, "/dev/video1394/%d", cameras[i]->port);
> >> if (dc1394_set_dma_device_filename(cameras[i], device_name)
> >> != DC1394_SUCCESS) {
> >> fprintf(stderr,"unable to set dma device filename!\n");
> >> clean_up_exit_all_cameras(cameras, numCameras);
> >> }
> >
> > You only need to setup the device file if you use exotic
> > names. /dev/video1394, /dev/video1394-X and /dev/video1394/X are all
> > supported.
> >
> This actually seems to be where the problem lied. I simply took out
> this setting, since as you said it will automatically detect if it is in
> /dev/video1394/X and it seems to work fine now. I wasn't able to track
> down exactly what was wrong.
Good news. At least for you because now I have to fix this bug ;-) Hop!
in the TODO list...
> >> /*-----------------------------------------------------------------------
> >> * setting capture parameters
> >> *-------------------------------------------------------------------*/
> >>
> >> if (dc1394_dma_setup_capture(cameras[i],
> >> DEFAULT_VIDEO_MODE,
> >> DEFAULT_ISO_SPEED,
> >> DEFAULT_FPS,
> >> options.ring_buffer_size,
> >> DEFAULT_DROP_FRAMES) != DC1394_SUCCESS) {
> >> fprintf(stdout, "dma_setup_capture failed\n");
> >> clean_up_exit_all_cameras(cameras, numCameras);
> >> }
> >> <it continues on, but this is where the error occurs>
> >
> > It probably means that the camera does not support the video
> > mode/format/fps combination. Add some printfs after asking for the
> > available video modes and also check that the camera supports the FPS
> > you specify.
> >
> It seems fine after I removed the set device_name manually. I don't
> think this was the case.
OK.
> > Another (partial) solution would be to try the latest CVS of libdc1394
> > but it will require some changes in your code. It will be easier to
> > track the failure because the format setup and the capture setup are now
> > separated.
> We're still having some problems getting 2.0.0-pre6 to work. We're
> still getting some weird behavior, but we're currently trying to track
> it down.
Let us know if you find something. Currently "it works for me" but hey,
I can't test everything ;-)
Damien
--
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, NAIST
V_/_ http://chihara.aist-nara.ac.jp/

Salut Andy,
On Thu, 2006-03-30 at 14:35 +0200, Andy Gotz wrote:
> Hi,
>
> is it possible to have two applications reading images from the same
> camera using libdc1394? I would like to have coriander running
> simultaneously with my application. I haven't looked into this problem
> but was wondering if someone has tried it yet? If so can they both
> control the features of the camera?
Short answer: no, it is not possible. Only one program at a time can get
the images. However you have a few tricks available to use the images
within several programs:
- use the "export to stdout" saving format in coriander. Then your app
can read the images from stdin.
- design your app with a V4L input (coriander can output to V4L)
- create a new SHM service (probably the most elegant and efficient way)
Damien
--
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, NAIST
V_/_ http://chihara.aist-nara.ac.jp/

Hi James,
On Thu, 2006-03-30 at 18:02 -0500, James Sherman Jr. wrote:
> Hello,
>
> So I was originally using the filltime field in the camera structure to
> time how fast we were getting the images, and we kept getting instances
> where the the time would actually jump backwards so we tried looking at
> the system time as well as the fill time field. So, we ran the code
> attached in timetrial.c.
[snip]
To make a long story short ;-) : the solution is to upgrade or patch
your kernel. The bug is in video1394. The earliest stable release to
include the modification is 2.6.16. Since the patch is quite trivial you
may just change video1394.c instead of recompiling/installing a whole
new kernel. You will find the patch in the linux1394-devel archives.
Damien
--
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, NAIST
V_/_ http://chihara.aist-nara.ac.jp/

Thanks for responding Damien.
Damien Douxchamps wrote:
>
> Why do you ask for the supported video modes if the video mode that you
> select is hardcoded anyway?
>
This was just left in for experimentation reasons.
>> // setting device name
>> snprintf(device_name, 255, "/dev/video1394/%d", cameras[i]->port);
>> if (dc1394_set_dma_device_filename(cameras[i], device_name)
>> != DC1394_SUCCESS) {
>> fprintf(stderr,"unable to set dma device filename!\n");
>> clean_up_exit_all_cameras(cameras, numCameras);
>> }
>
> You only need to setup the device file if you use exotic
> names. /dev/video1394, /dev/video1394-X and /dev/video1394/X are all
> supported.
>
This actually seems to be where the problem lied. I simply took out
this setting, since as you said it will automatically detect if it is in
/dev/video1394/X and it seems to work fine now. I wasn't able to track
down exactly what was wrong.
>> /*-----------------------------------------------------------------------
>> * setting capture parameters
>> *-------------------------------------------------------------------*/
>>
>> if (dc1394_dma_setup_capture(cameras[i],
>> DEFAULT_VIDEO_MODE,
>> DEFAULT_ISO_SPEED,
>> DEFAULT_FPS,
>> options.ring_buffer_size,
>> DEFAULT_DROP_FRAMES) != DC1394_SUCCESS) {
>> fprintf(stdout, "dma_setup_capture failed\n");
>> clean_up_exit_all_cameras(cameras, numCameras);
>> }
>> <it continues on, but this is where the error occurs>
>
> It probably means that the camera does not support the video
> mode/format/fps combination. Add some printfs after asking for the
> available video modes and also check that the camera supports the FPS
> you specify.
>
It seems fine after I removed the set device_name manually. I don't
think this was the case.
>
> Another (partial) solution would be to try the latest CVS of libdc1394
> but it will require some changes in your code. It will be easier to
> track the failure because the format setup and the capture setup are now
> separated.
We're still having some problems getting 2.0.0-pre6 to work. We're
still getting some weird behavior, but we're currently trying to track
it down.
Thanks again,
James

Hello,
So I was originally using the filltime field in the camera structure to
time how fast we were getting the images, and we kept getting instances
where the the time would actually jump backwards so we tried looking at
the system time as well as the fill time field. So, we ran the code
attached in timetrial.c. Of importance, the particular part of the code
that measures the time when the image is written,
struct timeval t0, t2;
gettimeofday(&t0, NULL);
for (uint_t frameNum = 0; frameNum < options.num_frames; frameNum++){
//fprintf(stderr,"capturing frame %d\n", frameNum);
//fflush(stderr);
/* capture data */
err=dc1394_dma_capture(cameras, numCameras, DC1394_VIDEO1394_WAIT);
DC1394_ERR_CHK(err,"failed to capture\n");
gettimeofday(&t2, NULL);
t2seconds = t2.tv_sec - t0.tv_sec;
t2microseconds = t2.tv_usec;
struct timeval *t1 = dc1394_video_get_filltime(cameras[0]);
t1seconds = t1->tv_sec - t0.tv_sec;
t1microseconds = t1->tv_usec;
fprintf(stdout, "p:%ld.%06ld:%ld.%06ld\n",
t2seconds, t2microseconds,
t1seconds, t1microseconds);
// free buffers for next frame
for (uint_t i = 0; i < numCameras; i++) {
dc1394_dma_done_with_buffer(cameras[i]);
}
}
So for the first 20 frames the time difference between system
time(systime) and filltime are the same, but then afterward the filltime
jumps back in time to the first time instant, and continues at the same
rate (see figure time.jpg). Note that I also used frame buffer size of
20, so it seems that the filltime buffer is looking at the time that the
frame was captured on the last buffer place. (i.e. if frame 1 was
captured at time 0, then then frame 21 captured at time t is stored in
the same memory location at time 0, but the filltime field would still
use time 0). Has anyone used the filltime buffers and had the same problem?
Thanks,
James Sherman
P.S.
The .c file was compiled using the Feb. 06, 2007 libdc version,
g++ -g -O2 -Wall -I/opt/libdc1394-2.0.0-20060207/include/dc1394 -o
timetrial timetrial.c -lm -lstdc++ -L/opt/libdc1394-2.0.0-20060207/lib/
-L/usr/local/lib -lraw1394 -ldc1394
and the output from timetrial was redirected to a file, and these
commands will extract the relevant times
cat tmp.time | grep ^p: | awk -F: '{print $3}' > tmp.filltime
cat tmp.time | grep ^p: | awk -F: '{print $2}' > tmp.systime
Yesterday (though I can't replicate the results today), showed that even
in the first 20 frames, the value in filltime for frame i was actually
the time when frame i+1 was captured. I don't understand how this is
happening, since filltime is only modified in setup_capture function.

Hi,
is it possible to have two applications reading images from the same
camera using libdc1394? I would like to have coriander running
simultaneously with my application. I haven't looked into this problem
but was wondering if someone has tried it yet? If so can they both
control the features of the camera?
Thanks for any help on this topic
Andy

It's me again. I had a small typo in my explanations of the error:
Deniz Bahadir wrote:
> ...
> else {
> if (version!=-1)
> return DC1394_FALSE; <----------
> else
> return DC1394_SUCCESS; <----------
> }
>
> return DC1394_SUCCESS;
> }
>
>
> It seems to me, that you tried to merge three errors in one. ;-)
> The first error is that instead of returning "DC1394_FAILURE" you return
> DC1394_SUCCESS" (where the first arrow points to).
I meant:
The first error is that instead of returning "DC1394_FAILURE" you return
"DC1394_FALSE" (where the first arrow points to).
Other than that, the email should be correct. :-)
So seems the fix.
That's all folks,
DENIZ

I'm using libdc1394-2.0.0-pre5 on a PowerPC Linux 2.6 system.
I have observed an apparent problem with dc1394_find_cameras()
in dc1394_control.c - some unused connections to the 1394 device
aren't/can't be released, until the process exits.
If the call to dc1394_get_camera_info(tmpcam)
returns an error, there is disabled cleanup code. Even if
that code were enabled, it would not help in our case where
e.g. a hub returns with DC1394_NOT_A_CAMERA.
I believe the correction is to add an "else" clause
corresponding to (line 167):
if (err == DC1394_SUCCESS) { // is it a camera
which does (line 193)
} else {
dc1394_free_camera(tmpcam);
}
I occasionally have camera operations fail in a manner
that can only be cleared by removing and reloading the
1394 kernel modules. Without this fix, the modules
can't be removed from the main capture application,
as it reports "resource busy".
I'd like to suggest that this be added to the official
source.

Hallo Damien, hello list,
I found a bug in your latest official version of libdc1394, version 1.2.0.
In function: int dc1394_is_camera(raw1394handle_t handle, nodeid_t node,
dc1394bool_t *value)
Lines: 1169 and 1171 (marked by arrows in the code below)
Original code:
int
dc1394_is_camera(raw1394handle_t handle, nodeid_t node, dc1394bool_t *value)
{
...
int version;
/* get the unit_sw_version (should be 0x000100 - 0x000102 for 1394
digital camera) */
/* DRD> without this check, AV/C cameras show up as well */
if (dc1394_get_sw_version(handle,node, &version)!=DC1394_SUCCESS) {
*value=DC1394_FALSE;
return DC1394_FAILURE;
}
else {
if (version!=-1)
return DC1394_FALSE; <----------
else
return DC1394_SUCCESS; <----------
}
return DC1394_SUCCESS;
}
It seems to me, that you tried to merge three errors in one. ;-)
The first error is that instead of returning "DC1394_FAILURE" you return
DC1394_SUCCESS" (where the first arrow points to).
The second error is, that if "dc1394_get_sw_version" returns
"DC1394_SUCCESS", and "version" is unequal to -1, you return a failure, and
success if "version" is -1.
The third error is, that you completely forget to set the value for
"dc1394_is_camera"'s parameter "value" (the important return-value).
A bugfix might be the following (for me fine working) code part:
Bug-fixed code:
int
dc1394_is_camera(raw1394handle_t handle, nodeid_t node, dc1394bool_t *value)
{
...
int version;
/* get the unit_sw_version (should be 0x000100 - 0x000102 for 1394
digital camera) */
/* DRD> without this check, AV/C cameras show up as well */
if (dc1394_get_sw_version(handle,node, &version)!=DC1394_SUCCESS) {
*value=DC1394_FALSE;
return DC1394_FAILURE;
}
else {
if (version!=-1)
*value DC1394_TRUE; <----------
else
*value DC1394_FALSE; <----------
}
return DC1394_SUCCESS;
}
It might be better to return "DC1394_FAILURE" if "version" was equal to -1
and "value" was set to "DC1394_FALSE". However, I think, it is completely
fine to return a "DC1394_SUCCESS", because "dc1394_get_sw_version" returns
"DC1394_SUCCESS", too.
Everything else seems to work for me as normal, although I did not
explicitely check for any other problems.
Maybe you can merge this fix in a version 1.2.1, so that there is a last
working version of branch 1.x before the final version 2.0.0?
Oh and sorry, that I am not applying a patch-file, but I don't really know,
what the needed (diff-)format must look like.
Best regards from Germany,
DENIZ BAHADIR
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl

Hi Johannes,
On Mon, 2006-03-13 at 19:56 +0100, Johannes Erb wrote:
> h list people
>
> i am trying to capture frames from two "Imaging Source DMx 21AF04"
> cameras simultaneously (mode = mono8@...; fps = 30; bus = speed400),
> but as soon as i start iso transmission for the second camera something
> fails. i tried coriander, which showed the same symptoms as my own prog;
> libdc 2.0.0-pre5 does just the same as 1.1.
>
> when i start transmission for the second cam, the first cam's
> transmission stops (fails?). restarting it causes both cameras to hang;
> coriander still finds 'em an is able to communicate with 'em (though a
> bit sticky), but i won't receive any further frames (frame rate stays
> 0,000). the only way to reactivate them is rebooting the system.
>
> i've got two more unibrain cameras which do work under equivalent
> conditions; i even get one 21AF04 and one unibrain captured
> simultaneously. so, looks if it's a problem with the imaging source cams
> (is it worth to mention that the cams work with the packaged imaging
> source software for windows?).
>
> (btw: the imaging source cams tend to need a replug after reboot (not
> every time, unfrequently). it seems to be specific for these cams, too;
> doesn't happen with the unibrain ones. maybe this is somehow related...)
>
> so far -- just wanted to know if anyone experienced something
> comparable? i didn't find anything in the lists, but: did anyone ever
> try to get two cams of the above type grabbed simultaneously? or anyone
> any ideas?
I haven't experienced that but since TIS graciously donated 2 cameras I
will be able to check. Not before the WE though, because I have a
meeting in Tokyo tomorrow.
Damien
--
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, NAIST
V_/_ http://chihara.aist-nara.ac.jp/

if you need mirror'ing in live cell imaging, AVT cameras usually have a
mirroring fuction built in. Check with the manual before you buy. They
are German made and relatively less expensive in EU.
Cagdas
P.S.: what about adding a Reply-To: field to list mails?

Hi,
I was getting this error often when using dma_capture with WAIT policy.
So I dug the reason behind it until the kernel. The reason is I consume
frames in a burst and sometimes the last one I WAIT for is not there and
WAIT is interrupted within kernel.
2.6.16 kernel uses the same call for POLL_BUFFER and WAIT_BUFFER. In the
case that WAIT_BUFFER call wakes up from wait_interruptible BEFORE a
frame arrives, kernel returns the same errno, EINTR to libdc1394 as it
would do for POLL_BUFFER is returning empty buffer. In libdc1394 this
errno is perfectly well processed for POLL_BUFFER but WAIT_BUFFER
failure is not processed correctly.
In this case libdc1394 returns DC1394_FAILURE instead. Moreover the ring
buffer counter is increased by one. This is meaningless. Increasing this
count can help a dma_done_with_buffer after such a failure but the
correct policy should return something else that waiting application
should be able to process and retry as necessary. Of course ring buffer
counter should remain same as it rolls back to original at POLL_BUFFER
policy. These are actually same things, policy only changes expectation
but failure should be analysed carefully by the application.
I already hacked pre6 for a usable work around. As far as I see today
revision 1.26.2.25 of dc1394_capture.c in CVS is still not addressing
this issue. Do you want a patch against pre6 or CVS?
One little question if anybody remembers:
At what kernel revision using a single frame ring buffer became
possible? I guess this error was introduced around that time because now
completely empty ring buffer is possible.
regards,
Cagdas

Live cell imaging. I've been working with a Hammamatsu C4742-95 camera,
but its too expensive to get second.
Basically, the only requirements are:
C-Mount
Doesn't suck with libdc1394
Other than that, its pretty open.
Brendan Drew wrote:
> What's your application?
>
> Paul Davis wrote:
>
>>
>> I'm in the process of looking for a new camera. Seeing as I'll be
>> using libdc1394 to code the interface I thought I'd see if anyone on
>> the list had any recommendations or warnings about cameras.
>>
>> Thanks,
>> Paul Davis
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting
>> language
>> that extends applications into web and mobile media. Attend the live
>> webcast
>> and join the prime developer group breaking into this new coding
>> territory!
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Mailing list for libdc1394-devel
>> libdc1394-devel@...
>> https://lists.sourceforge.net/lists/listinfo/libdc1394-devel
>
>
>

I'm in the process of looking for a new camera. Seeing as I'll be using
libdc1394 to code the interface I thought I'd see if anyone on the list
had any recommendations or warnings about cameras.
Thanks,
Paul Davis

Hi
Coriander is offering me a per frame "(dc1394_capture.c:397) error!" message when I try to receive frames using raw1394 mode. I also get an error when I try to receive frames using video1394:
(dc1394_capture.c) VIDEO1394_IOC_LISTEN_QUEUE_BUFFER ioctl failed!
Libdc1394 error (dc1394_capture.c:dc1394_dma_setup_capture:471): Generic failure : Could not setup DMA capture
Failed to setup DMA capture. Error code 1
This may be a simple configuration error, however i cant seem to find any setup issues. Coriander is correctly finding and identifying the camera on the bus. I checked the /dev permissions and they are correct...
Im running on a 64 bit machine on which I dont have root access... so I had to install the latest 1394 lib into a user directory.
I would appreciate any suggestions.
-Cole

Hello James,
On Sun, 2006-03-19 at 20:35 -0500, James Sherman Jr. wrote:
> I believe this is a problem with bandwidth that is available on a single
> port. In the one of the newer versions of dc1394_dma_setup_capture, it
> prints out the amount of bandwidth that is reserved for that camera.
> Each port can only have 4915 units of bandwidth (see the comment in
> dc1394_control.c). By putting more than one camera on a port, my guess
> is that you are exceeding the bandwidth (thus returning an error). The
> reason why this breaks things is that the reserved memory isn't released
> automatically, thus when you try to run it again, you try and reserve
> more bandwidth that isn't there. (I had this same problem just last week.)
Something was missing: in the case where a channel could be allocated
but not the bandwidth, the channel was not freed. This is fixed, but I'm
not sure that it's the source of your problem.
Damien
--
_ Damien 'Takahara' Douxchamps, PhD
('- Post-doctoral investigator
//\ Image Processing Group, NAIST
V_/_ http://chihara.aist-nara.ac.jp/