FORMAT7, Y16 and FPS

[Grimmwolf]

Hi.

I started using pydc1394 recently (for an AVT Stingray 145b), so far
it worked, as long as I used the fixed mode of 1024x768xY16. To use
the full capabilities of the camera, (1388x1038, 14bit, greyscale), I
decided to switch my python scripts to FORMAT7. I programmed the
camera to:

cam0.program_format7_mode(0, offset = (0,0), mode = (1388, 1038,
"Y16"))

and set the camera to use FORMAT7_0.
Now I had two problems:
1) When I checked the resulting array, I noticed that the picture now
was of the correct dimensions, but the bit depth was just 8 bit. I
started coriander to check whether I can access the FORMAT7 mode
correctly and set the sizes accordingly. It displayed just fine.
Launching my script again, I noticed, that the settings for the
FORMAT7 slot were stored and now pydc was capturing images with bit-
depth of 16bit, and not just 14 bit (values up to 65K).
Is this a bug in camera.py or does it sound more like a camera
problem? (I am not a trained programmer)

2) How do I set the FPS in FORMAT7? I found out that one can set it in
Coriander by playing around with the bus speed and the packet size.
[1]
Is there an easy way to do the same in pydc, or do I have to live with
the frame rates I get by chance?

Thank you for your time and effort that went into writing pydc1394. It
made my work much easier. :)
Malte


[1] http://damien.douxchamps.net/ieee1394/libdc1394/v2.x/faq/#How_can_I_work_out_the_packet_size_for_a_wanted_frame_rate

[Tomio]

Hi,

To set a 16 bit format7 mode...
Last time something like the following worked for me:
First set the format7 mode using the cam0.mode = ... command
then

i,j,m = cam0.mode
cam0.program_format7_mode(0,mode=(i,j,"Y16"))

If I am not mistaken this should leave the camera at highest
resolution and 16 bit mode.

To set FPS: usually it does not exists like that in format7. Usually
you can set the shutter speed, and then get the frames as fast as it
gets. You can estimate the speed either experimenting and using the
time stamps of the frames, or from the manual of your camera.
I am using a Hamamatsu ORCA, and at FORMAT7_0 it has about 80 ms
conversion time, + shutter speed. This leaves me with about 8 - 10
frames pro second.

Out of format7 you should be able to set framerates using:
- cam0.get_framerates_for_mode() -> to get what possible is
- cam0.fps = rate, where rate is one from those above

I hope this helped...

Tomio

[Grimmwolf]

Hi,

> First set the format7 mode using the cam0.mode = ... command
> then
>
> i,j,m = cam0.mode
> cam0.program_format7_mode(0,mode=(i,j,"Y16"))

I just tried this. It didn't give me an error message, but it failed
to switch to 14/16 bit and recorded the images in 8 bit.
The programming of format7 seems to fail in pydc (for Y16), while it
works in Coriander.

> To set FPS: usually it does not exists like that in format7. Usually
> you can set the shutter speed, and then get the frames as fast as it
> gets. You can estimate the speed either experimenting and using the
> time stamps of the frames,

I am more or less looking for a simple way to limit the fps in pydc (I
only need 2 fps). I was hoping there was an internal calculation for
that in format 7 mode.

> Out of format7 you should be able to set framerates using:
> - cam0.get_framerates_for_mode() -> to get what possible is
> - cam0.fps = rate, where rate is one from those above

Trying to get the fps causes this error for me:

print cam0.get_framerates_for_mode()
File "/usr/local/lib/python2.6/dist-packages/pydc1394/camera.py", line
1241, in get_framerates_for_mode
return [ self.fps ]
File "/usr/local/lib/python2.6/dist-packages/pydc1394/camera.py", line
1144, in fget
return 1.0/fi.value
ZeroDivisionError: float division

I was unable to understand whether this is a camera or a pydc problem.

Thank you for your time,
Malte

[Tomio]

Hi,

The simplest way is using the camera interactively:
camera.start(interactive=True)

then cam.current_image can give you always the latest image, and you
do not have to worry about the frame rate.

Good -sad- news: I can reproduce the problem with the 8 bit - 16 bit
problem.
In our Basler 602f I can set the 16 bit mode, and the frame comes as 8
bit, so it falls back to 8 bit. Now, the Coriander records the 16 bit
image, but also behaves a bit weird. I have to look into this further
on, there must be a trick done by Coriander, something tiny but
important.

The framerates: get_framerates_for_mode it returns an error if you try
to call it in a format7 mode. This is from dc1394.

Tomio

[Grimmwolf]

Hi,

> The simplest way is using the camera interactively:
> camera.start(interactive=True)

Thanks for the hint, that's what I will use instead. Of course I have
to correct the time.sleep(1/fps) by the time it takes to grab and save
the previous picture, so the actual fps is closer to the set value. It
is not perfect, but much easier.

> Good -sad- news: I can reproduce the problem with the 8 bit - 16 bit
> problem.
> In our Basler 602f I can set the 16 bit mode, and the frame comes as 8
> bit, so it falls back to 8 bit. Now, the Coriander records the 16 bit
> image, but also behaves a bit weird. I have to look into this further
> on, there must be a trick done by Coriander, something tiny but
> important.

Good to know that it isn't just me.
As I pointed out in my first e-Mail, it is actually possible to record
in 16bit with pydc. After plugging in the camera one has launch
coriander, switch the format_7 mode to 16 bit and then close coriander
again. Now pydc will record in 16bit format_7. So setting 16bit/
format_7 in pydc doesn't disturb anything, but it doesn't switch it
either. Of course it would be more convenient without that coriander
step. :)

[Arjun Chennu]

On Mon, Jul 19, 2010 at 12:55, Grimmwolf <ryan...@gmx.de> wrote:

Hi,

> The simplest way is using the camera interactively:
> camera.start(interactive=True)

Thanks for the hint, that's what I will use instead. Of course I have
to correct the time.sleep(1/fps) by the time it takes to grab and save
the previous picture, so the actual fps is closer to the set value. It
is not perfect, but much easier.

You have to use time.sleep() indeed in order to adjust the rate of frame arrival indeed. However, if the camera is running with some settings, and you change something (shutter, gain, etc) then it can take up to several frames till this change is implemented. For example, with some point grey sensors, it can take up to 4 frames for the settings to be updated. This is important while settings are changed, and you would do some analysis on the subsequent frames, for example, to auto-expose.

This issue is of course hardware dependant, and not about pydc1394 per se. Checking with the camera manufacturer helps.

Arjun

[Tomio]

> As I pointed out in my first e-Mail, it is actually possible to record
> in 16bit with pydc. After plugging in the camera one has launch
> coriander, switch the format_7 mode to 16 bit and then close coriander
> again. Now pydc will record in 16bit format_7. So setting 16bit/
> format_7 in pydc doesn't disturb anything, but it doesn't switch it
> either. Of course it would be more convenient without that coriander
> step. :)

Hi, and wait a sec...

1. I have fixed some parts making the Basler working now as it does
with Coriander: 16bit images, just messed up endianness.
(Coriander is ignoring the frame data depth if it differs from the
data depth set in the camera.)

SirVer will have to audit this and add it to the main trunk some time
(fresh, I have just submitted the fresh code).

2. I am a bit confused from your post. Could you please, run the
following:

cam0.program_format7_mode(0, offset = (0,0), mode = (1388, 1038,
"Y16"))

print camera.numpy_dtype

It shold be "<u2" or ">u2".
If it is the case, then my new modifications will work.

Tomio

[M.W.]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> 1. I have fixed some parts making the Basler working now as it does
> with Coriander: 16bit images, just messed up endianness.

Cool, I can't wait to install the new version. :)

> 2. I am a bit confused from your post. Could you please, run the
> following:
> cam0.program_format7_mode(0, offset = (0,0), mode = (1388, 1038,
> "Y16"))
> print camera.numpy_dtype
>
> It shold be "<u2" or ">u2".

It looks good. I got ">u2" as a result.

Malte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxNMVYACgkQZ2ILQVnPodCEDwCfT5vKTB+uUsjgBdI/xpxRJN70
8lkAnjkkvHrX2qX084ItZEV5zQfxO2sp
=n0/p
-----END PGP SIGNATURE-----

[Grimmwolf]

Hi,

I just read your patch and your comments on it. I checked the results
with my camera, Coriander really messes up for my camera as well
(14bit grayscale), when forcing the format7 to 16 bit. The measured
intensities are way above the 14 bits it can record.
(I have not tried your fix to pydc yet, as I have many other
(unrelated) problems with my software.)
Grimmwolf

[Malte]

Hi,

I talked to AVT-support yesterday and received a reply. It seems that
they introduced >8bit cameras before it was officially supported by
the standard. Quote from the e-mail:

"At that time there was no definition for this, so there was a
decision made that the 12 bits will be transferred MSB aligned in an
16 bit unsigned value. For compatibility issues - we have many
customers who use several camera families - this never was changed;
although there was the definition that data should be LSB aligned in
the IIDC 1.31."

This might explain some of the weird behaviour I found in Coriander.
Dividing the resulting arrays by (16bit-bit-depth) or shifting the
bits to the right by the difference should give the real values. I am
still playing around with this at the moment.
I will continue to post the results until I fixed it or someone asks
me to stop.

Malte

[SirVer]

Hi,

> SirVer will have to audit this and add it to the main trunk some time
> (fresh, I have just submitted the fresh code).

Tomio, your latest changes make ./run_test.py fail on my system with a
NULL pointer access. Could you verify this?

Holger

[SirVer]

Hi,


> > The simplest way is using the camera interactively:
> > camera.start(interactive=True)
>
> Thanks for the hint, that's what I will use instead. Of course I have
> to correct the time.sleep(1/fps) by the time it takes to grab and save
> the previous picture, so the actual fps is closer to the set value. It
> is not perfect, but much easier.

My cameras (Point Gray Scorpions) have another property called
framerate. I can do something like this:
cam.framerate.mode = 'manual'
cam.framerate.val = 2.

and I get quite precisely 2 fps. I do not need to use mode 7 for this,
it works with any mode. Maybe you can use something like this?

Cheers,
Holger

[Malte]

> My cameras (Point Gray Scorpions) have another property called
> framerate. I can do something like this:
> cam.framerate.mode = 'manual'
> cam.framerate.val = 2.
>
> and I get quite precisely 2 fps. I do not need to use mode 7 for this,
> it works with any mode. Maybe you can use something like this?
>
> Cheers,
> Holger

Hi,

I tried it, but my camera doesn't support it. I now use a different
way to adjust the framerate. I just adjust the shutter value (and for
my camera the timebase) to 1/fps. This forces the camera to the
framerate I want. For my measurements, I need the camera to integrate
over the time anyway.

Malte

[Malte]

Hi,

I used tomio's revision to change the format7 mode to 16 bit and back.
I found a small typo in line 1310:
self._dll.dc1394_get_color_coding_from_video_mode(self.cam,\
needs to be changed to
self._dll.dc1394_get_color_coding_from_video_mode(self._cam,\
. The rest was ok and on my computer the ./run_test.py worked just
fine.

Malte

SirVer schrieb:

[Tomio]

On Aug 4, 3:01 pm, Malte <ryan2...@gmx.de> wrote:
> Hi,
>
> I used tomio's revision to change the format7 mode to 16 bit and back.
> I found a small typo in line 1310:
> self._dll.dc1394_get_color_coding_from_video_mode(self.cam,\
> needs to be changed to
> self._dll.dc1394_get_color_coding_from_video_mode(self._cam,\
> . The rest was ok and on my computer the  ./run_test.py worked just
> fine.
>
> Malte

Thanks Malte, I added this change in my branch. Indeed a typo, which
can mess things up badly 8*.

And a comment to the cameras: the real fun in the firewire standard
for me its dynamic nature. There are common features, but some cameras
are unique. It also stands for the format7 modes, which are quite
different between companies and models. There is no common solution:
read the manual... 8)