libdc1394 + Point Grey Chameleon USB2.0 + Raspberry Pi

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

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

image timestamp

I am curious what the most 'accurate' time stamp is that is available
for FireWire images captured in Linux. All the data we collect in our
acquisition system are time tagged with the local time (millisecond
resolution). We would like to do the same with FireWire images. Since
the cameras are not time synchronized with the PC, I am guessing that
the time stamp that is available is when the image arrived in the PC.
How best to access this information for images captured via 

dc1394_capture_dequeue(cam, DC1394_CAPTURE_POLICY_WAIT, &capture)

Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer <at> ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
Mailing list for libdc1394-devel
libdc1394-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

stupid question about byte swapping

Apparently all IIDC camera send data in big endian format for the frame image (in a dc1394video_frame_t the
little_endian value is always false).
Does this mean on an Intel CPU I have to byte swap all the frame image data (16 bit bayer in my case)? Or does the
library takes care of it ?

Rodolphe

--

|        Rodolphe Pineau    RTI-Zone        |
|         http://www.rti-zone.org/          |
|   Robotics / Unix / Mac OS X / Astronomy  |

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev

Occasional DC1394_NO_ISO_CHANNEL

I am running DC1394 on:

	openSUSE 12.1 (kernel 3.1.0-1.2-desktop)
	libdc1394 (libdc1394-22-2.1.3-29.1.2.i586)
	libraw1394 as used by dc1394 - not directly
		(libraw1394-11-2.0.7-4.1.2.i586)

The camera info looks like this:

------ Camera information ------
Vendor                            :     SONY
Model                             :     DFW-SX910 v1.23A
Unit                              :     0
Specifications ID                 :     0xa02d
Software revision                 :     0x102
IIDC version code                 :     547
Unit directory offset             :     0x434
Unit dependent directory offset   :     0x444
Commands registers base           :     0xf00000
Unique ID                         :     0x08004602000f08bc
Vendor ID                         :     0x80046
Model ID                          :     0x0
Advanced features found at offset :     0xf30000
1394b mode capable (>=800Mbit/s)  :     No
Platform backend                  :     juju

The Bus card is:

0a:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx]

Quite often, I see lines like this when configuring a camera:

libdc1394 error: Generic failure: in dc1394_video_get_iso_speed (control.c, line 748): Could not get
ISO data

libdc1394 error: Generic failure: in dc1394_feature_is_present (control.c, line 1318): Could not get
register for feature

libdc1394 error: Generic failure: in dc1394_feature_get (control.c, line 235): Could not check feature presence

libdc1394 error: Generic failure: in dc1394_feature_get_all (control.c, line 210): Could not get
camera feature

and once in a while:

libdc1394 warning: iso allocation not available in this kernel, using channel 0...

It is not consistent. When the ISO-related errors happen, I cannot get
images. When the feature errors happen I cannot change settings.

I cannot say that I have found a pattern. Except that once it is not
happy, I need to unplug and plug in the camera to get it to work again.
Until it fails again.

I would say it fails with something like this more than 50% of the time.
Once it works, it seems ok. It is when starting that it gets confused.

I am running the cameras in ISO mode, calling dc1394_capture_dequeue() /
dc1394_capture_enqueue() for each image.

I can provide more details about how I set up / tear down the camera. I
think it is pretty much as suggested in the various docs.

OOC, is there any brute-force approach that resets the bus similar to
the way it is when a camera is physically unplugged/plugged in?

Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
roger.oberholtzer <at> ramboll.se
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Mailing list for libdc1394-devel
libdc1394-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdc1394-devel

Milo Corkey

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev

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

Using a Pointgrey Flea3 Camera with libd1394

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev

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

Re: Fwd: Re: dc1394_avt_get_deferred_trans in dc1394 v2

Hi again

I have reduced the problem to something I believe is not vendor specific.

The idea is as follows

call dc1394_avt_set_deferred_trans to stop DMA transfer (the camera will  
continue capturing to internal FIFO)
call dc1394_avt_get_deferred_trans to query for available frames on the  
camera
call dc1394_avt_set_deferred_trans with sendImage =true to make the camera  
transfer images to the DMA buffer (DMA transfer is still stopped  
afterwards)

The problem is registering a buffer on more then one camera:
Before the above sequence will work I figure you need to register a buffer  
first, I have used dc1394_capture_setup, however this fails on the next  
camera, if you don't call dc1394_capture_stop on the last camera.

so how should I allocate a DMA buffer for all 3 camera's at the same time  
- allocate the frames manually and use dc1394_capture_enqueue ?
	If so which fields of the frame do you need to set for  
dc1394_capture_enqueue to accept - not all of them are obvious.

-
Ole

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev

firmware bug

Hello all

Just coming back to the list because of the nasty bug that has been
bothering me for a bit now.
I have 2 Allied Vision cameras (Marlin, Stingray), the acquisition
machines are all based on AMD / gigabyte and opensuse.
Their BIOS come with a "cool and quiet" option.

I have had problems with acquisition (coriander) since open Suse 12.2;
so for now as I wrote previously I am stuck with open suse 12.1 where
everything works fine.

Unless .... I turn off the cool and quiet option; then the cameras are
not even detected when plugged.
Could it be the source of my problems ??

Many thanks
E

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

Mac OS X runloop for usb camera

So I did a little bit of work on this.
I added a capture_set_callback to the platform dispatch and added the dc1394_capture_set_callback to dc1394/capture.c
I had to move a few typedefs out of the macosx code into the main code and also added #ifdef HAVE_MACOSX /
#endif where needed.
So now I can call dc1394_capture_set_callback in my code and it routes the call to the right code (tested).

David, I might need some help on setting the runloop part if you have time, if not I'll try on my own.

Damien, will you accept a patch even if the code is not complete but doesn't break existing functionality or
feature ?

Thank you
Rodolphe

--

|        Rodolphe Pineau    RTI-Zone        |
|         http://www.rti-zone.org/          |
|   Robotics / Unix / Mac OS X / Astronomy  |

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

Fwd: Re: dc1394_avt_get_deferred_trans in dc1394 v2

Hi

How are you supposed to use dc1394_avt_set_deferred_trans and  
dc1394_avt_get_deferred_trans with dc1394 v2?

simplified  list of calls :

/*
	dc1394camera_t* camHnd[0], and camHnd[1] are setup, and tested working
*/

dc1394_avt_set_deferred_trans(camHnd[1],DC1394_TRUE,DC1394_FALSE,10,1,DC1394_TRUE);
dc1394_capture_setup(camHnd[0],10,DC1394_CAPTURE_FLAGS_DEFAULT);
dc1394_video_set_transmission(camHnd[0],DC1394_ON);
dc1394_video_set_transmission(camHnd[1],DC1394_ON);
dc1394error_t CaptureError  
=dc1394_capture_dequeue(camHnds[0],DC1394_CAPTURE_POLICY_WAIT,&frame);
while(numImg==0)
	dc1394_avt_get_deferred_trans(camHnd[1],&holdimg,&fastCap,&fifoSize,&numImg);

last call returns with fifosize=13, and numImg = 3 to 13

trying to dequeue (dc1394_capture_dequeue) a frame from camHnd[1] after  
the last call, seams to break the code

	is there a different method you should use to get the an image with  
deferred transfer, or are there others steps in the procedure I'm missing  
with regards to deferred transfer ?

I have working code from dc1394 v1 with deferred transfer, however it uses  
raw1394handle, and single capture - so it doesn't help much in updating  
the code to dc1394 v2 and video - I Have the cameras working  with video  
and single capture, but not simultaneously, however I need to run 3  
cameras simultaneously thus it seems deferred transfer is the only way to  
do it.

I know this is vendor specific -- hope someone can help anyway.

-
Thanks

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

bayer decoding questions

Hello everybody.
I'm running into some weird issue with the bayer decoding functions.
If I use dc1394_bayer_decoding_16bit I can't use the frame->image as the first parameter as it crash in the
code (and it depends on the algo I chose).
So I have to make a copy of the source image in a buffer… but the source buffer needs to be 3 times bigger (like
the destination RGB buffer) or it also crash
So I use this :

    uint16_t *rgbBuffer = malloc(w * h * 3); // RGB -> 3 byte per pixels
    unsigned char* src = malloc(w * h * 3); // Why do I need 3 times the space in the source !!! 
    memcpy(src, frame->image, frame->image_bytes);
    dc1394_bayer_decoding_16bit((const uint16_t *)src, rgbBuffer, w, h, DC1394_COLOR_FILTER_GBRG,
DC1394_BAYER_METHOD_SIMPLE, bits);

and this seems to not crash but the image looks wrong as the color are not correct.
Even though the source is passed as a const it looks like the code is modifying the source.

Also what is the bits parameter supposed to be ?

I'm testing with a SONY XCD-U100CR camera (my other cam are all monochrome). I know this cam output 10 bit of
valid data per pixels so some scaling is needed here.
I know it uses DC1394_COLOR_FILTER_GBRG as the bayer matrix (I have another app that display the color
correctly when choosing this mode..)

I also tried using :

dc1394_debayer_frames(frame, rgbFrame,DC1394_BAYER_METHOD_SIMPLE);
dc1394video_frame_t *rgbFrame = calloc(1, sizeof(dc1394video_frame_t));

but this gives me a black frame !!

any idea of what am I doing wrong here ?

Does the lib automatically deal with camera sending their data in big endian format ?
I ask because when I debug I see the the frame  little_endian param is set to DC1394_FALSE

Thank you for any help on this
Regards, Rodolphe

--

|        Rodolphe Pineau    RTI-Zone        |
|         http://www.rti-zone.org/          |
|   Robotics / Unix / Mac OS X / Astronomy  |

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb