libdc1394-devel — Reflector for all things relating to the devlopment of libdc1394.

Re: [libdc] Cannot stop the ISO transfer.

[Matwey V. K. <mat...@gm...>]

Hi,

Sorry for long delay. I've done some tests you requested.

13.02.2024 12:45, Damien Douxchamps пишет:
> Hello Matwey,
> 
> On Thu, 2024-02-08 at 19:38 +0300, Matwey V. Kornilov wrote:
>> Hi,
>>
>>
>> First of all, let me apologize for asking questions here :) It likely
>> looks very weird to ask the questions about IIDC in 2024.
> 
> Some of us are still using IIDC cameras! :)
> 
>> However, I've found that I don't understand the ISO transfer stop
>> concept and could not figure it out from the examples and the
>> documentation. The main issue is that
>>
>>      dc1394_video_set_transmission(&camera, DC1394_OFF)
>>
>> sometimes returns with non-successful error code. And what do I do
>> here? In my opinion it should never happen, like closing a file is
>> always a successful operation just because you can't do anything else
>> if the file failed to be closed.
> 
> This is strange indeed. dc1394_video_set_transmission() only sets a
> control register, so failure should not happen unless something is
> seriously wrong.
> 
> What is the error code?

It is DC1394_FAILURE (-1).

> Did you try to run with debug ON? IIRC this is done with prefixing your
> command with DC1394_DEBUG=1

libdc1394 debug: juju: Attempting iso allocation: handle 0, chan 0xffff, 
bw 4108
libdc1394 debug: juju: Allocated handle 0: chan 0 bw 4108
libdc1394 debug: juju: Receiving from iso channel 0
libdc1394 debug: Juju: got iso event, cycle 0x8bff, header_len 1272
libdc1394 debug: Juju: using cycle 0x8b56 (diff was 19750)
libdc1394 debug: Juju: frame latency 21314 us
libdc1394 debug: Juju: got iso event, cycle 0x8f1f, header_len 1272
libdc1394 debug: Juju: using cycle 0x8e76 (diff was 19750)
libdc1394 debug: Juju: frame latency 21313 us
libdc1394 debug: Juju: got iso event, cycle 0x923f, header_len 1272
libdc1394 debug: Juju: using cycle 0x9196 (diff was 19750)
libdc1394 debug: Juju: frame latency 21311 us
libdc1394 debug: Juju: got iso event, cycle 0x955f, header_len 1272
libdc1394 debug: Juju: using cycle 0x94b6 (diff was 19750)
libdc1394 debug: Juju: frame latency 21312 us
libdc1394 debug: Juju: got iso event, cycle 0x987f, header_len 1272
libdc1394 debug: Juju: using cycle 0x97d7 (diff was 19750)
libdc1394 debug: Juju: frame latency 21188 us
libdc1394 debug: Juju: got iso event, cycle 0x9b9f, header_len 1272
libdc1394 debug: Juju: using cycle 0x9af7 (diff was 19750)
libdc1394 debug: Juju: frame latency 21189 us
libdc1394 debug: Juju: got iso event, cycle 0x9ebf, header_len 1272
libdc1394 debug: Juju: using cycle 0x9e17 (diff was 19750)
libdc1394 debug: Juju: frame latency 21187 us
libdc1394 debug: juju: Response error, rcode 0x14
libdc1394 error: Generic failure: in dc1394_video_set_transmission 
(control.c, line 962): Could not stop ISO transmission

> 
>> But it does happen for me from time to time. If I just ignore the
>> error, then everything eventually messes up and then only camera
>> power-reset helps. What I experimentally found is that
>>
>>      while (dc1394_video_set_transmission(&camera, DC1394_OFF) !=
>> DC1394_SUCCESS);
>>
>> works stable but looks really quite weird.
>>
>> So I would like to know
>>
>> 1) What is going on under the hood of
>> dc1394_video_set_transmission(&camera, DC1394_OFF) and what are the
>> origins of the non-successful return?
> 
> The returned error code would give us some clue ;)
> 
> Looking at the code an error could happen if the camera was not
> initialized (unlikely) or there is a low level ioctl problem. A bad
> cable or other hardware issue could also lead to call failing.
> 
>> 2) What is the correct and safe way to stop the transmission?
> 
> You're doing the right thing:
> 
> int err=dc1394_video_set_transmission(&camera, DC1394_OFF);
> if(err!=DC1394_SUCCESS) {
> 	... send debug message, nuke the entire site from orbit,...
> }
> 
>> 3) What is the correct way to recover the camera at the application
>> start if an application has previously crashed in the middle of
>> transmission, i.e. the transmission has not been stopped?
> 
> You could try dc1394_camera_reset() and/or dc1394_reset_bus()
> The first one will still need to write to a register, so the same
> problem could happen.
> 
>> Thanks, and hope there are still people who remember what is going on
>> here.
> 
> Well... It's been a while since I had to dig into libdc1394 ;)
> 
> Is stopping the transmission the only thing that fails? What if you try
> to change a feature setting or something else simple? If trying to stop
> the transmission fails then most other commands sent to the camera
> would also fail.

Yes, stopping the transmission is the only thing that fails and after 
that the camera is not able to do anything else. I cannot reinit the camera:

libdc1394 debug: Initializing platform 0: linux
libdc1394 debug: linux: Failed to open RAW1394DEV or /dev/raw1394
libdc1394 debug: Failed to initialize platform 0
libdc1394 debug: Initializing platform 1: juju
libdc1394 debug: Juju: Found /dev/fw1
libdc1394 debug: Juju: Found /dev/fw0
libdc1394 debug: Initialized platform 1
libdc1394 debug: Initializing platform 2: usb
libdc1394 debug: Initialized platform 2
libdc1394 debug: Enumerating cameras...
libdc1394 debug: Enumerating platform juju
libdc1394 debug: Juju: Opened /dev/fw1 successfully
libdc1394 debug: Juju: Opened /dev/fw0 successfully
libdc1394 debug: Platform juju has 2 device(s)
libdc1394 debug: Got 256 quads of config ROM
libdc1394 debug: Adding camera f3100000075c7:0 f31:0 (Prosilica:Digital 
Camera (DCAM 1.31))
libdc1394 debug: Got 256 quads of config ROM
libdc1394 debug: Enumerating platform usb
libdc1394 debug: Platform usb has 0 device(s)
libdc1394 debug: Juju: kernel API has version 5
libdc1394 debug: juju: Response error, rcode 0x14


Only power cycle helps to recover the camera.

> 
> Damien
> 
> 

Re: [libdc] Cannot stop the ISO transfer.

[Damien D. <dd...@do...>]

Hello Matwey,

On Thu, 2024-02-08 at 19:38 +0300, Matwey V. Kornilov wrote:
> Hi,
> 
> 
> First of all, let me apologize for asking questions here :) It likely
> looks very weird to ask the questions about IIDC in 2024.

Some of us are still using IIDC cameras! :)

> However, I've found that I don't understand the ISO transfer stop
> concept and could not figure it out from the examples and the
> documentation. The main issue is that
> 
>     dc1394_video_set_transmission(&camera, DC1394_OFF)
> 
> sometimes returns with non-successful error code. And what do I do
> here? In my opinion it should never happen, like closing a file is
> always a successful operation just because you can't do anything else
> if the file failed to be closed.

This is strange indeed. dc1394_video_set_transmission() only sets a
control register, so failure should not happen unless something is
seriously wrong. 

What is the error code?
Did you try to run with debug ON? IIRC this is done with prefixing your
command with DC1394_DEBUG=1

> But it does happen for me from time to time. If I just ignore the
> error, then everything eventually messes up and then only camera
> power-reset helps. What I experimentally found is that
> 
>     while (dc1394_video_set_transmission(&camera, DC1394_OFF) !=
> DC1394_SUCCESS);
> 
> works stable but looks really quite weird.
> 
> So I would like to know
> 
> 1) What is going on under the hood of
> dc1394_video_set_transmission(&camera, DC1394_OFF) and what are the
> origins of the non-successful return?

The returned error code would give us some clue ;)

Looking at the code an error could happen if the camera was not
initialized (unlikely) or there is a low level ioctl problem. A bad
cable or other hardware issue could also lead to call failing.

> 2) What is the correct and safe way to stop the transmission?

You're doing the right thing:

int err=dc1394_video_set_transmission(&camera, DC1394_OFF);
if(err!=DC1394_SUCCESS) {
	... send debug message, nuke the entire site from orbit,...
}

> 3) What is the correct way to recover the camera at the application
> start if an application has previously crashed in the middle of
> transmission, i.e. the transmission has not been stopped?

You could try dc1394_camera_reset() and/or dc1394_reset_bus()
The first one will still need to write to a register, so the same
problem could happen.

> Thanks, and hope there are still people who remember what is going on
> here.

Well... It's been a while since I had to dig into libdc1394 ;)

Is stopping the transmission the only thing that fails? What if you try
to change a feature setting or something else simple? If trying to stop
the transmission fails then most other commands sent to the camera
would also fail.

Damien


-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

[libdc] Cannot stop the ISO transfer.

[Matwey V. K. <mat...@gm...>]

Hi,


First of all, let me apologize for asking questions here :) It likely
looks very weird to ask the questions about IIDC in 2024.


However, I've found that I don't understand the ISO transfer stop
concept and could not figure it out from the examples and the
documentation. The main issue is that

    dc1394_video_set_transmission(&camera, DC1394_OFF)

sometimes returns with non-successful error code. And what do I do
here? In my opinion it should never happen, like closing a file is
always a successful operation just because you can't do anything else
if the file failed to be closed.

But it does happen for me from time to time. If I just ignore the
error, then everything eventually messes up and then only camera
power-reset helps. What I experimentally found is that

    while (dc1394_video_set_transmission(&camera, DC1394_OFF) !=
DC1394_SUCCESS);

works stable but looks really quite weird.

So I would like to know

1) What is going on under the hood of
dc1394_video_set_transmission(&camera, DC1394_OFF) and what are the
origins of the non-successful return?

2) What is the correct and safe way to stop the transmission?

3) What is the correct way to recover the camera at the application
start if an application has previously crashed in the middle of
transmission, i.e. the transmission has not been stopped?

Thanks, and hope there are still people who remember what is going on here.

-- 
With best regards,
Matwey V. Kornilov

Re: [libdc] config.{guess,sub} of libdc1394 is outdated

[Damien D. <dd...@do...>]

Hi Levi,

On Mon, 2023-06-05 at 10:38 +0800, Levi Zim wrote:
> Hi,
> 
> The config.guess and config.sub is outdated and doesn't work on riscv64 
> linux.
> 
> It is causing our build to fail (build log: 
> https://archriscv.felixc.at/.status/log.htm?url=logs/libdc1394/libdc1394-2.2.6-3.log). 
> 
> 
> It would be nice if the maintainers of libdc1394 could update these two 
> scripts.

Thanks for the feedback. I've updated the library and the new release
(2.2.7) now includes the latest config.guess and config.sub.

This has no impact for those who build from git: in that case autotools
will install your system's config.xxx files.

Let me know if there's any issue, I haven't built/released something for
libdc in a while... ;)

Cheers,

Damien

-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

[libdc] config.{guess,sub} of libdc1394 is outdated

[Levi Z. <rsw...@ou...>]

Hi,

The config.guess and config.sub is outdated and doesn't work on riscv64 
linux.

It is causing our build to fail (build log: 
https://archriscv.felixc.at/.status/log.htm?url=logs/libdc1394/libdc1394-2.2.6-3.log). 


It would be nice if the maintainers of libdc1394 could update these two 
scripts.


kxxt

Re: [libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Damien D. <dd...@do...>]

Hi Alois,

On Tue, 2023-04-11 at 18:47 +0200, Alois Schlögl wrote:
> Dear Damien,
> 
> 
> when going int production, we noticed one more issue. The camera 
> resolution on linux appear different on Linux vs. Windows.
> On windows with the dcam-api drivers, micromanager 1.4 shows 1344x1024 
> pixels 16 bit 2.6MB,
> on linux with libdc1394 and Micromanager 2.0, we get only 640x480px 
> RGB32 3MB.
> 
> Checking also with some spatial calibration scale, we can say less than 
> a quarter of the area.
> 
> In order to remove this limitation, I'm wondering whether this could be 
> fixed within the libdc1394 driver ?
> Do you have any hints/suggestions how to overcome these limits ?

I don't think this is an issue with the drivers/libraries. Rather this
could be a design decision at the application level: your micromanager
may use the highest resolution by default, while libdc1394 uses the
current resolution reported by the camera (which is often the boot
default selected by the manufacturer).

Normally you need to select the image format since you can't really
count on the current format being what you want (for example, another
application may have set the image format to something else...)
libdc1394 of course allows you to select the format, and I suspect
'micromanager 2.0' would also let you choose that?

BTW 3MB for 640x480 is a bit large, even at 32bit/pixel. Are you sure
about this value?

Damien

> Cheers,
>     Alois
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Mailing list for libdc1394-devel
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

Re: [libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Alois S. <alo...@gm...>]

Dear Damien,


when going int production, we noticed one more issue. The camera 
resolution on linux appear different on Linux vs. Windows.
On windows with the dcam-api drivers, micromanager 1.4 shows 1344x1024 
pixels 16 bit 2.6MB,
on linux with libdc1394 and Micromanager 2.0, we get only 640x480px 
RGB32 3MB.

Checking also with some spatial calibration scale, we can say less than 
a quarter of the area.

In order to remove this limitation, I'm wondering whether this could be 
fixed within the libdc1394 driver ?
Do you have any hints/suggestions how to overcome these limits ?


Cheers,
    Alois

Re: [libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Alois S. <alo...@gm...>]

Am 3/18/23 um 13:26 schrieb Damien Douxchamps:
> Hello Alois,
>
> On Wed, 2023-03-08 at 18:50 +0100, Alois Schlögl wrote:
>> Am 3/8/23 um 04:53 schrieb Damien Douxchamps:
>>> Hello Alois,
>>>
>>> On Mon, 2023-03-06 at 19:14 +0100, Alois Schlögl wrote:
>>>> Hello Damien,
>>>>
>>>> Am 3/6/23 um 09:58 schrieb Damien Douxchamps:
>>>>> Hello Alois,
>>>>>
>>>>> On Mon, 2023-03-06 at 09:31 +0100, Alois Schlögl wrote:
>>>>>> To whom it my concern,
>>>>>>
>>>>>>
>>>>>> I'm trying to use the Hamatsu Camera ORCA-ER C4742-80-12AG with
>>>>>> Micro-mananger [1] on Debian11, but run into problems that the camera is
>>>>>> not recognized. When search the list of supported cameras [2], there are
>>>>>> several ORCA cameras listed, but not
>>>>>> ORCA-ER C4742-80-12AG
>>>>>>
>>>>>> Specifically, I used micromanager 2.0 and libdc1394, libraw1394,
>>>>>> gscanbus, dvgrab, Debian11, linux-kernel 5.10. The firewire card is
>>>>>> identified, and /dev/fw0 becomes available and permissions are set.
>>>>>> dc1394_reset_bus shows this message:
>>>>>> /usr/bin/dc1394_reset_bus
>>>>>> Using camera with GUID 90060415610105
>>>>>> Reseting bus...
>>>>>> but dvgrab can not find the camera. The output from testlibraw and
>>>>>> gscanbus is attached. Micromanager 2.0 can be started, and the hardware
>>>>>> configuration is performed, trying to configure with IIDC or with dc1394
>>>>>> fail with an error that no camera is found.
>>>>>>
>>>>>>
>>>>>> Do you know a solution how to make this camera useful again ?
>>>>>> Do you have any suggestions what I've been missing, and what else I
>>>>>> could try ?
>>>>>> Is it feasible in support this camera in libdc1394 ?
>>>>> Yes, it should work with libdc1394 and coriander (but the latter may not
>>>>> work on recent debian/ubuntu). This part of gscanbus output says it's an
>>>>> IIDC camera that supports the 1.30 version of the protocol:
>>>>>
>>>>> Unit Spec ID: 0x0000A02D      # IIDC
>>>>> Unit SW Version: 0x00000102   # 1.30
>>>>>
>>>>> I'm not sure why it's not properly detected. I've used Hamamatsu cameras
>>>>> in the past and they usually work quite well.
>>>>>
>>>>> It could be interesting to add debug prints in identify_unit() in
>>>>> dc1394/enumeration.c:90 to see what condition fails. Is it something you
>>>>> can do?
>>>>>
>>>>> Regarding dvgrab: it will not work with IIDC cameras; it is made for
>>>>> camcorders and other video/playback devices.
>>>>>
>>>>> Interesting that you found a camera not listed on my website. It's
>>>>> obsolete but if we can make it work I'll add it posthumously! ;-)
>>>>>
>>>>> Best,
>>>>>
>>>>> Damien
>>>>>
>>>> thanks for your reply.
>>>>
>>>> I've added more debugging information in  dc1394/enumeration.c
>>>> The patch (debug.log) and the extra output of dc1394_reset_bus is attached.
>>>> Overall, dc1394_reset_bus seems to run ok,
>>>>
>>>> When configure the hardware with dc1394 in MM, it crashes (see
>>>> mm_patched_dc1394).
>>>> There errorr suggest that it could not handle some camera features.
>>>> Maybe that provides a hint.
>>> Thanks, that is helpful although I have to admit the error is puzzling.
>>> Here's a patch to give us an idea of which feature fails. It also dumps
>>> more data and doesn't stop on error. This last point may make your
>>> camera work or at least be detected. Let me know what kind of output you
>>> get.
>>>
>>> Damien
>>>
>>>
>> Hello Damien,
>>
>> the following is shown (due to your patch to register.c)
>>
>> Base 0xF00000, Offset 0x400
>>       Value: 0x40001000
>> Base 0xF00000, Offset 0x60C
>>       Value: 0x02000000
>> Base 0xF00000, Offset 0x608
>>       Value: 0xE0000000
>> Base 0xF00000, Offset 0x604
>>       Value: 0x00000000
>> Base 0xF00000, Offset 0x600
>>       Value: 0x00000000
>>
>> It seems that dc1394_feature_get() gets only called by grab_gray_image.
>> So, I checked also all executables in the example directory; the output
>> logs of these are also attached.
>> I've added more debug information, it should not be too difficult to
>> filter these (e.g. grep -v DBG *log)
>>
>> When searching for "error" in these output logs, I see these:
>>
>> basler_sff_extended_data.log:libdc1394 error: Generic failure: in
>> dc1394_basler_sff_feature_enable (basler.c, line 221): Cannot read SFF
>> feature CSR register
>> basler_sff_extended_data.log:libdc1394 error: Generic failure: in main
>> (basler_sff_extended_data.c, line 167): cannot enable Extended_Data_Stream
>> dc1394_multiview.log:libdc1394 error: No suitable Xv adaptor found
>> ladybug5capture.log:libdc1394 error: Function not supported by this
>> camera: in main (ladybug5capture.c, line 146): Could not set B mode
>> ladybug.log:libdc1394 error: Function not supported by this camera: in
>> main (ladybug.c, line 93): Could not set B mode
> These errors are expected since you're not using a Basler or Ladybug
> camera. The Xv adapter error is unrelated.
>
> The fact that helloworld.c runs without trouble means that your camera
> may be detected properly with the current patched code? Also,
> grab_gray_image captured an image (image.pgm), can you check if it's a
> valid image?
>
> Damien
>


Thanks, I tested this again. It seems it is a valid image. I tested now 
again with micromanager.
Trying to configure the camera with IIDC crashed the camera controller, 
which could be resolved only by a power reset (turning off and on) the 
camera controller.

When configuring the camera with dc1394, micromanager is able to access 
the camera.
I did several tests and rebooted the computer, and tested also stock 
version of libdc1394 from debian11, and it seems that this is working now.
At the moment, I assume that the earlier issues were do to the fact, 
that the camera controller was crashed, and the tools from libdc1394 did 
not work because of that.

The upshot of this story seems to be:
1) the hardware configuration in micromanager need to be configured with 
the dc1394.
2) the IIDC driver in Micromanager 2.0-dev seem buggy, and would crash 
the camera controller.

Sorry for the noise, and thanks for your support.

Best,
    Alois

Re: [libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Damien D. <dd...@do...>]

Hello Alois,

On Wed, 2023-03-08 at 18:50 +0100, Alois Schlögl wrote:
> Am 3/8/23 um 04:53 schrieb Damien Douxchamps:
> > Hello Alois,
> >
> > On Mon, 2023-03-06 at 19:14 +0100, Alois Schlögl wrote:
> >> Hello Damien,
> >>
> >> Am 3/6/23 um 09:58 schrieb Damien Douxchamps:
> >>> Hello Alois,
> >>>
> >>> On Mon, 2023-03-06 at 09:31 +0100, Alois Schlögl wrote:
> >>>> To whom it my concern,
> >>>>
> >>>>
> >>>> I'm trying to use the Hamatsu Camera ORCA-ER C4742-80-12AG with
> >>>> Micro-mananger [1] on Debian11, but run into problems that the camera is
> >>>> not recognized. When search the list of supported cameras [2], there are
> >>>> several ORCA cameras listed, but not
> >>>> ORCA-ER C4742-80-12AG
> >>>>
> >>>> Specifically, I used micromanager 2.0 and libdc1394, libraw1394,
> >>>> gscanbus, dvgrab, Debian11, linux-kernel 5.10. The firewire card is
> >>>> identified, and /dev/fw0 becomes available and permissions are set.
> >>>> dc1394_reset_bus shows this message:
> >>>> /usr/bin/dc1394_reset_bus
> >>>> Using camera with GUID 90060415610105
> >>>> Reseting bus...
> >>>> but dvgrab can not find the camera. The output from testlibraw and
> >>>> gscanbus is attached. Micromanager 2.0 can be started, and the hardware
> >>>> configuration is performed, trying to configure with IIDC or with dc1394
> >>>> fail with an error that no camera is found.
> >>>>
> >>>>
> >>>> Do you know a solution how to make this camera useful again ?
> >>>> Do you have any suggestions what I've been missing, and what else I
> >>>> could try ?
> >>>> Is it feasible in support this camera in libdc1394 ?
> >>> Yes, it should work with libdc1394 and coriander (but the latter may not
> >>> work on recent debian/ubuntu). This part of gscanbus output says it's an
> >>> IIDC camera that supports the 1.30 version of the protocol:
> >>>
> >>> Unit Spec ID: 0x0000A02D      # IIDC
> >>> Unit SW Version: 0x00000102   # 1.30
> >>>
> >>> I'm not sure why it's not properly detected. I've used Hamamatsu cameras
> >>> in the past and they usually work quite well.
> >>>
> >>> It could be interesting to add debug prints in identify_unit() in
> >>> dc1394/enumeration.c:90 to see what condition fails. Is it something you
> >>> can do?
> >>>
> >>> Regarding dvgrab: it will not work with IIDC cameras; it is made for
> >>> camcorders and other video/playback devices.
> >>>
> >>> Interesting that you found a camera not listed on my website. It's
> >>> obsolete but if we can make it work I'll add it posthumously! ;-)
> >>>
> >>> Best,
> >>>
> >>> Damien
> >>>
> >> thanks for your reply.
> >>
> >> I've added more debugging information in  dc1394/enumeration.c
> >> The patch (debug.log) and the extra output of dc1394_reset_bus is attached.
> >> Overall, dc1394_reset_bus seems to run ok,
> >>
> >> When configure the hardware with dc1394 in MM, it crashes (see
> >> mm_patched_dc1394).
> >> There errorr suggest that it could not handle some camera features.
> >> Maybe that provides a hint.
> > Thanks, that is helpful although I have to admit the error is puzzling.
> > Here's a patch to give us an idea of which feature fails. It also dumps
> > more data and doesn't stop on error. This last point may make your
> > camera work or at least be detected. Let me know what kind of output you
> > get.
> >
> > Damien
> >
> >
> 
> Hello Damien,
> 
> the following is shown (due to your patch to register.c)
> 
> Base 0xF00000, Offset 0x400
>      Value: 0x40001000
> Base 0xF00000, Offset 0x60C
>      Value: 0x02000000
> Base 0xF00000, Offset 0x608
>      Value: 0xE0000000
> Base 0xF00000, Offset 0x604
>      Value: 0x00000000
> Base 0xF00000, Offset 0x600
>      Value: 0x00000000
> 
> It seems that dc1394_feature_get() gets only called by grab_gray_image.
> So, I checked also all executables in the example directory; the output 
> logs of these are also attached.
> I've added more debug information, it should not be too difficult to 
> filter these (e.g. grep -v DBG *log)
> 
> When searching for "error" in these output logs, I see these:
> 
> basler_sff_extended_data.log:libdc1394 error: Generic failure: in 
> dc1394_basler_sff_feature_enable (basler.c, line 221): Cannot read SFF 
> feature CSR register
> basler_sff_extended_data.log:libdc1394 error: Generic failure: in main 
> (basler_sff_extended_data.c, line 167): cannot enable Extended_Data_Stream
> dc1394_multiview.log:libdc1394 error: No suitable Xv adaptor found
> ladybug5capture.log:libdc1394 error: Function not supported by this 
> camera: in main (ladybug5capture.c, line 146): Could not set B mode
> ladybug.log:libdc1394 error: Function not supported by this camera: in 
> main (ladybug.c, line 93): Could not set B mode

These errors are expected since you're not using a Basler or Ladybug
camera. The Xv adapter error is unrelated.

The fact that helloworld.c runs without trouble means that your camera
may be detected properly with the current patched code? Also,
grab_gray_image captured an image (image.pgm), can you check if it's a
valid image?

Damien

>     Alois
> 
> 
> _______________________________________________
> Mailing list for libdc1394-devel
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

Re: [libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Alois S. <alo...@gm...>]

Am 3/8/23 um 04:53 schrieb Damien Douxchamps:
> Hello Alois,
>
> On Mon, 2023-03-06 at 19:14 +0100, Alois Schlögl wrote:
>> Hello Damien,
>>
>> Am 3/6/23 um 09:58 schrieb Damien Douxchamps:
>>> Hello Alois,
>>>
>>> On Mon, 2023-03-06 at 09:31 +0100, Alois Schlögl wrote:
>>>> To whom it my concern,
>>>>
>>>>
>>>> I'm trying to use the Hamatsu Camera ORCA-ER C4742-80-12AG with
>>>> Micro-mananger [1] on Debian11, but run into problems that the camera is
>>>> not recognized. When search the list of supported cameras [2], there are
>>>> several ORCA cameras listed, but not
>>>> ORCA-ER C4742-80-12AG
>>>>
>>>> Specifically, I used micromanager 2.0 and libdc1394, libraw1394,
>>>> gscanbus, dvgrab, Debian11, linux-kernel 5.10. The firewire card is
>>>> identified, and /dev/fw0 becomes available and permissions are set.
>>>> dc1394_reset_bus shows this message:
>>>> /usr/bin/dc1394_reset_bus
>>>> Using camera with GUID 90060415610105
>>>> Reseting bus...
>>>> but dvgrab can not find the camera. The output from testlibraw and
>>>> gscanbus is attached. Micromanager 2.0 can be started, and the hardware
>>>> configuration is performed, trying to configure with IIDC or with dc1394
>>>> fail with an error that no camera is found.
>>>>
>>>>
>>>> Do you know a solution how to make this camera useful again ?
>>>> Do you have any suggestions what I've been missing, and what else I
>>>> could try ?
>>>> Is it feasible in support this camera in libdc1394 ?
>>> Yes, it should work with libdc1394 and coriander (but the latter may not
>>> work on recent debian/ubuntu). This part of gscanbus output says it's an
>>> IIDC camera that supports the 1.30 version of the protocol:
>>>
>>> Unit Spec ID: 0x0000A02D      # IIDC
>>> Unit SW Version: 0x00000102   # 1.30
>>>
>>> I'm not sure why it's not properly detected. I've used Hamamatsu cameras
>>> in the past and they usually work quite well.
>>>
>>> It could be interesting to add debug prints in identify_unit() in
>>> dc1394/enumeration.c:90 to see what condition fails. Is it something you
>>> can do?
>>>
>>> Regarding dvgrab: it will not work with IIDC cameras; it is made for
>>> camcorders and other video/playback devices.
>>>
>>> Interesting that you found a camera not listed on my website. It's
>>> obsolete but if we can make it work I'll add it posthumously! ;-)
>>>
>>> Best,
>>>
>>> Damien
>>>
>> thanks for your reply.
>>
>> I've added more debugging information in  dc1394/enumeration.c
>> The patch (debug.log) and the extra output of dc1394_reset_bus is attached.
>> Overall, dc1394_reset_bus seems to run ok,
>>
>> When configure the hardware with dc1394 in MM, it crashes (see
>> mm_patched_dc1394).
>> There errorr suggest that it could not handle some camera features.
>> Maybe that provides a hint.
> Thanks, that is helpful although I have to admit the error is puzzling.
> Here's a patch to give us an idea of which feature fails. It also dumps
> more data and doesn't stop on error. This last point may make your
> camera work or at least be detected. Let me know what kind of output you
> get.
>
> Damien
>
>

Hello Damien,

the following is shown (due to your patch to register.c)

Base 0xF00000, Offset 0x400
     Value: 0x40001000
Base 0xF00000, Offset 0x60C
     Value: 0x02000000
Base 0xF00000, Offset 0x608
     Value: 0xE0000000
Base 0xF00000, Offset 0x604
     Value: 0x00000000
Base 0xF00000, Offset 0x600
     Value: 0x00000000

It seems that dc1394_feature_get() gets only called by grab_gray_image.
So, I checked also all executables in the example directory; the output 
logs of these are also attached.
I've added more debug information, it should not be too difficult to 
filter these (e.g. grep -v DBG *log)

When searching for "error" in these output logs, I see these:

basler_sff_extended_data.log:libdc1394 error: Generic failure: in 
dc1394_basler_sff_feature_enable (basler.c, line 221): Cannot read SFF 
feature CSR register
basler_sff_extended_data.log:libdc1394 error: Generic failure: in main 
(basler_sff_extended_data.c, line 167): cannot enable Extended_Data_Stream
dc1394_multiview.log:libdc1394 error: No suitable Xv adaptor found
ladybug5capture.log:libdc1394 error: Function not supported by this 
camera: in main (ladybug5capture.c, line 146): Could not set B mode
ladybug.log:libdc1394 error: Function not supported by this camera: in 
main (ladybug.c, line 93): Could not set B mode


    Alois

Re: [libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Damien D. <dd...@do...>]

Hello Alois,

On Mon, 2023-03-06 at 19:14 +0100, Alois Schlögl wrote:
> Hello Damien,
> 
> Am 3/6/23 um 09:58 schrieb Damien Douxchamps:
> > Hello Alois,
> >
> > On Mon, 2023-03-06 at 09:31 +0100, Alois Schlögl wrote:
> >> To whom it my concern,
> >>
> >>
> >> I'm trying to use the Hamatsu Camera ORCA-ER C4742-80-12AG with
> >> Micro-mananger [1] on Debian11, but run into problems that the camera is
> >> not recognized. When search the list of supported cameras [2], there are
> >> several ORCA cameras listed, but not
> >> ORCA-ER C4742-80-12AG
> >>
> >> Specifically, I used micromanager 2.0 and libdc1394, libraw1394,
> >> gscanbus, dvgrab, Debian11, linux-kernel 5.10. The firewire card is
> >> identified, and /dev/fw0 becomes available and permissions are set.
> >> dc1394_reset_bus shows this message:
> >> /usr/bin/dc1394_reset_bus
> >> Using camera with GUID 90060415610105
> >> Reseting bus...
> >> but dvgrab can not find the camera. The output from testlibraw and
> >> gscanbus is attached. Micromanager 2.0 can be started, and the hardware
> >> configuration is performed, trying to configure with IIDC or with dc1394
> >> fail with an error that no camera is found.
> >>
> >>
> >> Do you know a solution how to make this camera useful again ?
> >> Do you have any suggestions what I've been missing, and what else I
> >> could try ?
> >> Is it feasible in support this camera in libdc1394 ?
> > Yes, it should work with libdc1394 and coriander (but the latter may not
> > work on recent debian/ubuntu). This part of gscanbus output says it's an
> > IIDC camera that supports the 1.30 version of the protocol:
> >
> > Unit Spec ID: 0x0000A02D      # IIDC
> > Unit SW Version: 0x00000102   # 1.30
> >
> > I'm not sure why it's not properly detected. I've used Hamamatsu cameras
> > in the past and they usually work quite well.
> >
> > It could be interesting to add debug prints in identify_unit() in
> > dc1394/enumeration.c:90 to see what condition fails. Is it something you
> > can do?
> >
> > Regarding dvgrab: it will not work with IIDC cameras; it is made for
> > camcorders and other video/playback devices.
> >
> > Interesting that you found a camera not listed on my website. It's
> > obsolete but if we can make it work I'll add it posthumously! ;-)
> >
> > Best,
> >
> > Damien
> >
> 
> thanks for your reply.
> 
> I've added more debugging information in  dc1394/enumeration.c
> The patch (debug.log) and the extra output of dc1394_reset_bus is attached.
> Overall, dc1394_reset_bus seems to run ok,
> 
> When configure the hardware with dc1394 in MM, it crashes (see 
> mm_patched_dc1394).
> There errorr suggest that it could not handle some camera features.
> Maybe that provides a hint.

Thanks, that is helpful although I have to admit the error is puzzling.
Here's a patch to give us an idea of which feature fails. It also dumps
more data and doesn't stop on error. This last point may make your
camera work or at least be detected. Let me know what kind of output you
get.

Damien

-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

Re: [libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Alois S. <alo...@gm...>]

Hello Damien,

Am 3/6/23 um 09:58 schrieb Damien Douxchamps:
> Hello Alois,
>
> On Mon, 2023-03-06 at 09:31 +0100, Alois Schlögl wrote:
>> To whom it my concern,
>>
>>
>> I'm trying to use the Hamatsu Camera ORCA-ER C4742-80-12AG with
>> Micro-mananger [1] on Debian11, but run into problems that the camera is
>> not recognized. When search the list of supported cameras [2], there are
>> several ORCA cameras listed, but not
>> ORCA-ER C4742-80-12AG
>>
>> Specifically, I used micromanager 2.0 and libdc1394, libraw1394,
>> gscanbus, dvgrab, Debian11, linux-kernel 5.10. The firewire card is
>> identified, and /dev/fw0 becomes available and permissions are set.
>> dc1394_reset_bus shows this message:
>> /usr/bin/dc1394_reset_bus
>> Using camera with GUID 90060415610105
>> Reseting bus...
>> but dvgrab can not find the camera. The output from testlibraw and
>> gscanbus is attached. Micromanager 2.0 can be started, and the hardware
>> configuration is performed, trying to configure with IIDC or with dc1394
>> fail with an error that no camera is found.
>>
>>
>> Do you know a solution how to make this camera useful again ?
>> Do you have any suggestions what I've been missing, and what else I
>> could try ?
>> Is it feasible in support this camera in libdc1394 ?
> Yes, it should work with libdc1394 and coriander (but the latter may not
> work on recent debian/ubuntu). This part of gscanbus output says it's an
> IIDC camera that supports the 1.30 version of the protocol:
>
> Unit Spec ID: 0x0000A02D      # IIDC
> Unit SW Version: 0x00000102   # 1.30
>
> I'm not sure why it's not properly detected. I've used Hamamatsu cameras
> in the past and they usually work quite well.
>
> It could be interesting to add debug prints in identify_unit() in
> dc1394/enumeration.c:90 to see what condition fails. Is it something you
> can do?
>
> Regarding dvgrab: it will not work with IIDC cameras; it is made for
> camcorders and other video/playback devices.
>
> Interesting that you found a camera not listed on my website. It's
> obsolete but if we can make it work I'll add it posthumously! ;-)
>
> Best,
>
> Damien
>

thanks for your reply.

I've added more debugging information in  dc1394/enumeration.c
The patch (debug.log) and the extra output of dc1394_reset_bus is attached.
Overall, dc1394_reset_bus seems to run ok,

When configure the hardware with dc1394 in MM, it crashes (see 
mm_patched_dc1394).
There errorr suggest that it could not handle some camera features.
Maybe that provides a hint.

Best,
   Alois

Re: [libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Damien D. <dd...@do...>]

Hello Alois,

On Mon, 2023-03-06 at 09:31 +0100, Alois Schlögl wrote:
> To whom it my concern,
> 
> 
> I'm trying to use the Hamatsu Camera ORCA-ER C4742-80-12AG with 
> Micro-mananger [1] on Debian11, but run into problems that the camera is 
> not recognized. When search the list of supported cameras [2], there are 
> several ORCA cameras listed, but not
> ORCA-ER C4742-80-12AG
> 
> Specifically, I used micromanager 2.0 and libdc1394, libraw1394, 
> gscanbus, dvgrab, Debian11, linux-kernel 5.10. The firewire card is 
> identified, and /dev/fw0 becomes available and permissions are set. 
> dc1394_reset_bus shows this message:
> /usr/bin/dc1394_reset_bus
> Using camera with GUID 90060415610105
> Reseting bus...
> but dvgrab can not find the camera. The output from testlibraw and 
> gscanbus is attached. Micromanager 2.0 can be started, and the hardware 
> configuration is performed, trying to configure with IIDC or with dc1394 
> fail with an error that no camera is found.
> 
> 
> Do you know a solution how to make this camera useful again ?
> Do you have any suggestions what I've been missing, and what else I 
> could try ?
> Is it feasible in support this camera in libdc1394 ?

Yes, it should work with libdc1394 and coriander (but the latter may not
work on recent debian/ubuntu). This part of gscanbus output says it's an
IIDC camera that supports the 1.30 version of the protocol:

Unit Spec ID: 0x0000A02D      # IIDC
Unit SW Version: 0x00000102   # 1.30

I'm not sure why it's not properly detected. I've used Hamamatsu cameras
in the past and they usually work quite well.

It could be interesting to add debug prints in identify_unit() in
dc1394/enumeration.c:90 to see what condition fails. Is it something you
can do?

Regarding dvgrab: it will not work with IIDC cameras; it is made for
camcorders and other video/playback devices.

Interesting that you found a camera not listed on my website. It's
obsolete but if we can make it work I'll add it posthumously! ;-)

Best,

Damien

-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

[libdc] Software/Driver for ORCA-ER C4742-80-12AG

[Alois S. <alo...@gm...>]

To whom it my concern,


I'm trying to use the Hamatsu Camera ORCA-ER C4742-80-12AG with 
Micro-mananger [1] on Debian11, but run into problems that the camera is 
not recognized. When search the list of supported cameras [2], there are 
several ORCA cameras listed, but not
ORCA-ER C4742-80-12AG

Specifically, I used micromanager 2.0 and libdc1394, libraw1394, 
gscanbus, dvgrab, Debian11, linux-kernel 5.10. The firewire card is 
identified, and /dev/fw0 becomes available and permissions are set. 
dc1394_reset_bus shows this message:
/usr/bin/dc1394_reset_bus
Using camera with GUID 90060415610105
Reseting bus...
but dvgrab can not find the camera. The output from testlibraw and 
gscanbus is attached. Micromanager 2.0 can be started, and the hardware 
configuration is performed, trying to configure with IIDC or with dc1394 
fail with an error that no camera is found.


Do you know a solution how to make this camera useful again ?
Do you have any suggestions what I've been missing, and what else I 
could try ?
Is it feasible in support this camera in libdc1394 ?


Best regards,
Alois

[1] https://micro-manager.org/
[2] https://damien.douxchamps.net/ieee1394/cameras/search/

Re: [libdc] DC1394 build for Windows

[Damien D. <dd...@do...>]

Hi Joseph,

On Mon, 2022-05-30 at 07:05 +0000, Joseph wrote:
> Hello,
> 
> I have
> read https://github.com/indigo-astronomy/libdc1394/blob/master/INSTALL-windows but it's always a bit complicated on Windows to build a binary release (we miss easy build 100% from command line with: apt install build-essential , configure and make etc.)
> 
> 
> Would someone have a ready-to-use Windows 7 build? 
> 
> 
> 
> 
> * Either with an .exe just to do some tests to list all the connected
> devices (I'm not sure yet if my camera is DC1394 compatible)
> * Or with a dc1394 DLL that can be called from Python
> with https://github.com/jordens/pydc1394/ ; it calls the DLL with: dll
> = _dll = cdll.LoadLibrary(find_library('dc1394'))
> 
> 
> If it works with my camera, I'll do a proper build then, but before
> I'm just looking for a quick test with Windows to know if the camera
> is DC1394.

Just an email to let you know that at least one person is still
listening on this list :-) Unfortunately I don't have a windows machine
to try. I did build successfully with windows a long time ago (8-9
years), in fact the readme you mention brought back some old memories
(it should, I wrote it!). At the time it was somewhat straightforward on
windows 7 but the instructions may not be up to date for newer systems.
Have you tried a build?

Best,

Damien


-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

[libdc] DC1394 build for Windows

[Joseph <j...@gg...>]

Hello,

I have read
https://github.com/indigo-astronomy/libdc1394/blob/master/INSTALL-windows
but it's always a bit complicated on Windows to build a binary release (we
miss easy build 100% from command line with: apt install build-essential ,
configure and make etc.)

Would someone have a ready-to-use Windows 7 build?


* Either with an .exe just to do some tests to list all the connected
devices (I'm not sure yet if my camera is DC1394 compatible)
* Or with a dc1394 DLL that can be called from Python with
https://github.com/jordens/pydc1394/ ; it calls the DLL with: dll = _dll =
cdll.LoadLibrary(find_library('dc1394'))

If it works with my camera, I'll do a proper build then, but before I'm
just looking for a quick test with Windows to know if the camera is DC1394.

Thanks in advance
Jo

Re: [libdc] Problem using libdc1394 and Ubuntu 18.04

[Damien D. <dd...@do...>]

Hi Pierre,

On Wed, 2020-12-02 at 10:10 +0000, Pierre Ferrer-Valls wrote:
> Hello all, 
> I am trying to use a Firefly MV camera (full reference below) with a
> Jetson TX2 card from Nvidia (running on Ubuntu 18.04). My goal is to
> get the video and encode it in .mp4 ideally (or .avi if mp4 is not
> available) and store it in a specific folder. I tried to install
> libdc1394 on the TX2 by copying the files and using the procedure
> written in INSTALL but it doesn’t work (error : ‘sudo ./configure :
> command not found’). I also tried to change the configure.ac extension
> into .sh, still the same result. I get the same results with Coriander
> installation process. 

If configure.sh is not there then you need to run "autoreconf -fi"
beforehand.

> Another question : is it possible to extend the limit of the buffer of
> 30M in the capture setup ? 

Where have you seen that limit of 30M? I don't remember such limit in
libdc but then again I haven't dived in the code in a long time...

Typically you only need a few capture buffers (4~10 images). If you need
to keep more images in memory you could dump them in an SHM buffer for
example. Though these days SSDs are quite fast and you can probably just
write to a regular file.

> Has anyone did this kind of project before ? I could really use a hand
> here. 

You could use gstreamer to encode the video. A quick and dirty way would
be to dump the raw data to stdout and have gstreamer read stdout and do
the mp4 encoding. Something like this:

gst-launch-1.0 filesrc location=/dev/stdin !
video/x-raw,width=640,height=480,format=I420,framerate=30/1 !
videoconvert ! (encoding part...) ! filesink location=v1.mp4

You'll have to change a few things of course, like the pixel format
(probably not I420) and play with the encoding part. Encoders sometimes
require a specific input color space, hence the videoconvert element.

> Thanks for any help you may give me ! 😃 

Cheers!

Damien


-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

[libdc] Problem using libdc1394 and Ubuntu 18.04

[Pierre Ferrer-V. <pie...@ai...>]

Hello all,
I am trying to use a Firefly MV camera (full reference below) with a Jetson TX2 card from Nvidia (running on Ubuntu 18.04). My goal is to get the video and encode it in .mp4 ideally (or .avi if mp4 is not available) and store it in a specific folder. I tried to install libdc1394 on the TX2 by copying the files and using the procedure written in INSTALL but it doesn’t work (error : ‘sudo ./configure : command not found’). I also tried to change the configure.ac extension into .sh, still the same result. I get the same results with Coriander installation process.

Another question : is it possible to extend the limit of the buffer of 30M in the capture setup ?
Has anyone did this kind of project before ? I could really use a hand here.

Thanks for any help you may give me ! 😃





[cid:image001.png@01D6C89A.C1DBE1E0]

Re: [libdc] Using Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) with coriander/libdc1394

[Stephan B. <ste...@po...>]

Dear Damien,

Thanks a lot for your answer, which helped me a lot.
Indeed, coriander already fails with capturing only, but as you 
mentioned, limiting the size of the images (doesn't have to be a 
multiple of 64) solves the problem.
Metadata added to the images could be a good explanation for this.
It's nice to use libdc1394 and still having cameras supporting it.
I hope FLIR/PointGrey will continue to produce the cameras for a long 
time.

Best
Stephan


Am 19.09.2020 10:21 schrieb Damien Douxchamps:
> Hi Stephan,
> 
> On Mon, 2020-09-14 at 11:19 +0200, Stephan Boltzmann wrote:
>> Hello everybody out there using libdc1394,
>> 
>> I'm interested in USB cameras supporting libdc1394.
>> I started with a FLIR (formerly PointGrey) Chameleon 3 camera
>> (CM3-U3-13S2C-CS) and was pleased to see it working very well with
>> coriander and a custom libdc1394 program.
>> 
>> I went on to try models of the Chameleon 3 with a higher frame rate,
>> which worked with coriander, but my program turned out to not keep 
>> pace
>> with the frames.
> 
> Processing wise or capture wise? If you have capture issues, try using 
> a
> triple buffer with frame-pointer exchange:
> 
> Camera >> Buffer 1 >> Buffer 2 >> Buffer 3 >> application
> 
> The camera writes to buffer 1. When it's done, it locks a mutex, swaps
> the pointers of buffers 1 and 2, sets a flag indicating a new frame,
> then unlocks the mutex and starts filling buffer 2.
> 
> Similarly, the application code uses buffer 3. When it's done with it,
> it locks the mutex, checks if a new frame arrived, and if so it swaps
> the pointers of buffers 2 and 3. Etc...
> 
>> The Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) cameras work
>> well with flycap and are correctly detected by coriander (Ubuntu 16.04
>> LTS), but would give me the error message "libdc1394 error: usb: Bulk
>> transfer 0 failed with code 6" upon trying display frames.
>> I then tried different modes to no success.
> 
> I have a grasshopper but it's the firewire B model, so I'm afraid I
> can't test that specific issue. I do have a USB Firefly MV and have not
> seen that error with it.
> 
> The error code is from libusb, and corresponds to
> LIBUSB_TRANSFER_OVERFLOW (the device sent more data than requested).
> 
> This could be the camera adding data at the end of the frame (e.g.
> metadata) but it should still be fine with ROI/Format_7 image formats
> (those have provision for 'padding' bytes at the end of the frame)
> 
>> Does anyone has an idea about which additional diagnostics to run in
>> order to pin down the problem?
> 
> First, try to do capture only (no display). I'm 99% sure it will 
> already
> fail (that rules out any display issue).
> 
> Another idea: try to limit the image size (using ROI / Format_7 image
> formats for example) You could also try to have the total image byte
> size be a multiple of 64 (this idea is probably a bit far fetched)
> 
>> I would also be grateful for hints towards other USB cameras 
>> supporting
>> libdc1394 - I looked through the list on the libdc1394 website and 
>> these
>> were the models I found.
> 
> As far as I know the only manufacturer of such cameras is
> PointGrey/FLIR. Although maybe I should say "_was_" because FLIR 
> stopped
> selling 1394 cameras recently, so it's quite possible they will also
> stop making their USB cameras compliant with IIDC.
> 
> At this stage I think it's clear that 1394 cameras are "Not For New
> Designs" :(
> 
> HTH,
> 
> Damien

Re: [libdc] Using Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) with coriander/libdc1394

[Damien D. <dd...@do...>]

Hi Stephan,

On Mon, 2020-09-14 at 11:19 +0200, Stephan Boltzmann wrote:
> Hello everybody out there using libdc1394,
> 
> I'm interested in USB cameras supporting libdc1394.
> I started with a FLIR (formerly PointGrey) Chameleon 3 camera 
> (CM3-U3-13S2C-CS) and was pleased to see it working very well with 
> coriander and a custom libdc1394 program.
>
> I went on to try models of the Chameleon 3 with a higher frame rate, 
> which worked with coriander, but my program turned out to not keep pace 
> with the frames.

Processing wise or capture wise? If you have capture issues, try using a
triple buffer with frame-pointer exchange:

Camera >> Buffer 1 >> Buffer 2 >> Buffer 3 >> application

The camera writes to buffer 1. When it's done, it locks a mutex, swaps
the pointers of buffers 1 and 2, sets a flag indicating a new frame,
then unlocks the mutex and starts filling buffer 2.

Similarly, the application code uses buffer 3. When it's done with it,
it locks the mutex, checks if a new frame arrived, and if so it swaps
the pointers of buffers 2 and 3. Etc...

> The Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) cameras work 
> well with flycap and are correctly detected by coriander (Ubuntu 16.04 
> LTS), but would give me the error message "libdc1394 error: usb: Bulk 
> transfer 0 failed with code 6" upon trying display frames.
> I then tried different modes to no success.

I have a grasshopper but it's the firewire B model, so I'm afraid I
can't test that specific issue. I do have a USB Firefly MV and have not
seen that error with it.

The error code is from libusb, and corresponds to
LIBUSB_TRANSFER_OVERFLOW (the device sent more data than requested). 

This could be the camera adding data at the end of the frame (e.g.
metadata) but it should still be fine with ROI/Format_7 image formats
(those have provision for 'padding' bytes at the end of the frame)

> Does anyone has an idea about which additional diagnostics to run in 
> order to pin down the problem?

First, try to do capture only (no display). I'm 99% sure it will already
fail (that rules out any display issue).

Another idea: try to limit the image size (using ROI / Format_7 image
formats for example) You could also try to have the total image byte
size be a multiple of 64 (this idea is probably a bit far fetched)

> I would also be grateful for hints towards other USB cameras supporting 
> libdc1394 - I looked through the list on the libdc1394 website and these 
> were the models I found.

As far as I know the only manufacturer of such cameras is
PointGrey/FLIR. Although maybe I should say "_was_" because FLIR stopped
selling 1394 cameras recently, so it's quite possible they will also
stop making their USB cameras compliant with IIDC.

At this stage I think it's clear that 1394 cameras are "Not For New
Designs" :(

HTH,

Damien

-- 
Damien 高原 Douxchamps    http://damien.douxchamps.net/

Re: [libdc] [EXTERNAL] Using Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) with coriander/libdc1394

[Stephan B. <ste...@po...>]

Dear Jeff,

Thanks a lot for your answer.
The size of usbfs_memory is indeed a known issue and I had already 
increased it to 2048 MB.
Your hint on the size of usbfs_memory made me think about simply trying 
frames with a smaller width and height.
Indeed, I can get both, the Grashopper and the Flea3 working if I use 
frames with a size of 90 x 90 px.
Thus, the cameras can in principle work with libdc1394.
Since this size is too small for my application, I still have to find a 
way to allow for bigger frames.
Changing the packet size to smaller values doesn't seem to help.

Best
Stephan


Am 14.09.2020 16:59 schrieb Mulligan, Jeffrey B. (ARC-TH) via 
libdc1394-devel:
> Greetings Stephan,
> 
> I have a number of Flea3's, which like you I used to run with
> libdc1394.  I don't now remember exactly why I switched to using the
> flycap library, but there was something that I needed to do that I
> couldn't get to work with libdc1394.  For the past few years I have
> been using a flycap-based program instead of the libdc1394 version.
> 
> I do have some notes regarding a problem that I resolved with the help
> of PGR support, I was unable to increase the number of buffers to a
> large enough value to do real-time recording without dropping frames,
> the solution was to increase the size of usbfs_memory from the default
> of 16MB to 200MB.  This is probably not your problem.
> 
> A couple years ago I acquired a couple of BlackFly S cameras, and
> discovered to my dismay that they are not seen by flycap, but only by
> the newer library "spinnaker".  So I had to spend a lot of time
> adapting my programs to use that library.  To make matters worse, the
> older cameras with the ieee1394 interface only work with flycap, so to
> use all of the cameras in my stable I still have to support both
> software interfaces.  The Flea3 works with either one.
> 
> It turns out that there is an open-source library that can substitute
> for the spinnaker library, it is called aravis.  It mostly works, but
> I did run into one problem, related to reading "chunk data" that
> didn't work properly, I had gotten as far as installing a packet
> sniffer to compare the traffic generated by spinview (the
> vendor-supplied application similar to flycap that does work
> correctly) with my libaravis-based program, but that got put on hold
> about a year ago, and remains that way now.
> 
> I'm sorry that I couldn't provide any answers to the question that you
> asked, but you might want to bite the bullet and leave libdc1394
> behind for the usb cameras.  I looked into it at one time and
> discovered that other vendors generally don't support the standard
> required at all...
> 
> Cheers, Jeff
> 
> 
> 
> On 9/14/20, 2:20 AM, "Stephan Boltzmann" <ste...@po...> 
> wrote:
> 
>     Hello everybody out there using libdc1394,
> 
>     I'm interested in USB cameras supporting libdc1394.
>     I started with a FLIR (formerly PointGrey) Chameleon 3 camera
>     (CM3-U3-13S2C-CS) and was pleased to see it working very well with
>     coriander and a custom libdc1394 program.
>     I went on to try models of the Chameleon 3 with a higher frame 
> rate,
>     which worked with coriander, but my program turned out to not keep 
> pace
>     with the frames.
>     The Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) cameras 
> work
>     well with flycap and are correctly detected by coriander (Ubuntu 
> 16.04
>     LTS), but would give me the error message "libdc1394 error: usb: 
> Bulk
>     transfer 0 failed with code 6" upon trying display frames.
>     I then tried different modes to no success.
>     Does anyone has an idea about which additional diagnostics to run 
> in
>     order to pin down the problem?
>     I would also be grateful for hints towards other USB cameras 
> supporting
>     libdc1394 - I looked through the list on the libdc1394 website and 
> these
>     were the models I found.
> 
>     Kind regards
>     Stephan
> 
> 
>     _______________________________________________
>     Mailing list for libdc1394-devel
>     lib...@li...
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_libdc1394-2Ddevel&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=p8PrTs7HdKmqWsCH0ysx6G5VcVwiN7r7O1heqd1IijY&m=6TGFhpX_PZteEqfdqX63xsJmXBbjepfqLIcub2AKcXM&s=hKBIvbl4zDMEM8_ZBQJCQk05HKEHI1gEj-AHiSE-1gs&e=
> 
> 
> _______________________________________________
> Mailing list for libdc1394-devel
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

Re: [libdc] [EXTERNAL] Using Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) with coriander/libdc1394

[Mulligan, J. B. (ARC-TH) <jef...@na...>]

Greetings Stephan,

I have a number of Flea3's, which like you I used to run with libdc1394.  I don't now remember exactly why I switched to using the flycap library, but there was something that I needed to do that I couldn't get to work with libdc1394.  For the past few years I have been using a flycap-based program instead of the libdc1394 version.

I do have some notes regarding a problem that I resolved with the help of PGR support, I was unable to increase the number of buffers to a large enough value to do real-time recording without dropping frames, the solution was to increase the size of usbfs_memory from the default of 16MB to 200MB.  This is probably not your problem.

A couple years ago I acquired a couple of BlackFly S cameras, and discovered to my dismay that they are not seen by flycap, but only by the newer library "spinnaker".  So I had to spend a lot of time adapting my programs to use that library.  To make matters worse, the older cameras with the ieee1394 interface only work with flycap, so to use all of the cameras in my stable I still have to support both software interfaces.  The Flea3 works with either one.

It turns out that there is an open-source library that can substitute for the spinnaker library, it is called aravis.  It mostly works, but I did run into one problem, related to reading "chunk data" that didn't work properly, I had gotten as far as installing a packet sniffer to compare the traffic generated by spinview (the vendor-supplied application similar to flycap that does work correctly) with my libaravis-based program, but that got put on hold about a year ago, and remains that way now.

I'm sorry that I couldn't provide any answers to the question that you asked, but you might want to bite the bullet and leave libdc1394 behind for the usb cameras.  I looked into it at one time and discovered that other vendors generally don't support the standard required at all...

Cheers, Jeff


 
On 9/14/20, 2:20 AM, "Stephan Boltzmann" <ste...@po...> wrote:

    Hello everybody out there using libdc1394,

    I'm interested in USB cameras supporting libdc1394.
    I started with a FLIR (formerly PointGrey) Chameleon 3 camera 
    (CM3-U3-13S2C-CS) and was pleased to see it working very well with 
    coriander and a custom libdc1394 program.
    I went on to try models of the Chameleon 3 with a higher frame rate, 
    which worked with coriander, but my program turned out to not keep pace 
    with the frames.
    The Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) cameras work 
    well with flycap and are correctly detected by coriander (Ubuntu 16.04 
    LTS), but would give me the error message "libdc1394 error: usb: Bulk 
    transfer 0 failed with code 6" upon trying display frames.
    I then tried different modes to no success.
    Does anyone has an idea about which additional diagnostics to run in 
    order to pin down the problem?
    I would also be grateful for hints towards other USB cameras supporting 
    libdc1394 - I looked through the list on the libdc1394 website and these 
    were the models I found.

    Kind regards
    Stephan


    _______________________________________________
    Mailing list for libdc1394-devel
    lib...@li...
    https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_libdc1394-2Ddevel&d=DwICAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=p8PrTs7HdKmqWsCH0ysx6G5VcVwiN7r7O1heqd1IijY&m=6TGFhpX_PZteEqfdqX63xsJmXBbjepfqLIcub2AKcXM&s=hKBIvbl4zDMEM8_ZBQJCQk05HKEHI1gEj-AHiSE-1gs&e= 

[libdc] Using Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) with coriander/libdc1394

[Stephan B. <ste...@po...>]

Hello everybody out there using libdc1394,

I'm interested in USB cameras supporting libdc1394.
I started with a FLIR (formerly PointGrey) Chameleon 3 camera 
(CM3-U3-13S2C-CS) and was pleased to see it working very well with 
coriander and a custom libdc1394 program.
I went on to try models of the Chameleon 3 with a higher frame rate, 
which worked with coriander, but my program turned out to not keep pace 
with the frames.
The Grashopper (GS3-U3-32S4C-C) or Flea3 (FL3-U3-13E4C) cameras work 
well with flycap and are correctly detected by coriander (Ubuntu 16.04 
LTS), but would give me the error message "libdc1394 error: usb: Bulk 
transfer 0 failed with code 6" upon trying display frames.
I then tried different modes to no success.
Does anyone has an idea about which additional diagnostics to run in 
order to pin down the problem?
I would also be grateful for hints towards other USB cameras supporting 
libdc1394 - I looked through the list on the libdc1394 website and these 
were the models I found.

Kind regards
Stephan

Re: [libdc] MONO12 color coding

[Matwey V. K. <mat...@gm...>]

27.10.2019 17:02, Damien Douxchamps пишет:
> Forgot to specify the new code is in the branch "add_12bit_modes"
> 

Hi,

Unfortunately, I cannot get transfer working. Everything works without
error until actual dc1394_capture_dequeue() is called. Then the
application is waiting forever.


dc1394_format7_get_roi() report the following final settings:

Camera packet size = 3328 bytes
Camera frame geometry = (0,0) (656,492)
Camera color coding = 363

Re: [libdc] MONO12 color coding

[Matwey V. K. <mat...@gm...>]

27.10.2019 17:02, Damien Douxchamps пишет:
> Forgot to specify the new code is in the branch "add_12bit_modes"
> 

Hi,

Unfortunately, I cannot get transfer working. Everything works without
error until actual dc1394_capture_dequeue() is called. Then the
application is waiting forever.


dc1394_format7_get_roi() report the following final settings:

Camera packet size = 3328 bytes
Camera frame geometry = (0,0) (656,492)
Camera color coding = 363