Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspiyuv always taking two pictures #640

Open
Ismael2878 opened this issue Jul 24, 2020 · 9 comments
Open

Raspiyuv always taking two pictures #640

Ismael2878 opened this issue Jul 24, 2020 · 9 comments
Labels
Close within 30 days Issue will be closed within 30 days unless requested to stay open

Comments

@Ismael2878
Copy link

Ismael2878 commented Jul 24, 2020

It seems to be the raspiyuv command is always taking 2 pictures. Therefore the needed time is twice as big as expected.

E.g. when executing next command:
raspiyuv -drc off -mm matrix -rgb -set -st -ex off -n -ss 50000000 -md 3 -t 1 -dg 2.0 -ag 2.0 -awb off -awbg 2.0,2.0 -o ~/output.raw

There are 2 camera control callbacks:
Camera control callback cmd=0x48435045mmal: Exposure now 49999693, analog gain 512/256, digital gain 512/256
mmal: AWB R=512/256, B=512/256
Camera control callback cmd=0x48435045mmal: Exposure now 49999693, analog gain 512/256, digital gain 512/256

Time needed is almost 2 minutes what is actually more than twice the defined shutter time.

System Information

Raspberry Pi Zero W Rev 1.1
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"

Used camera: IMX477

@JamesH65
Copy link
Collaborator

Why have you set -t to -1? What are you trying to achieve with that?

@Ismael2878
Copy link
Author

My excuses, this is a paste error. The used value was -t 1.

@JamesH65
Copy link
Collaborator

What about camera buffer callbacks - they are the ones that save the image, and you may get more than one of those depending on how much data needs to be saved. But it all ends up in the same file.

@Ismael2878
Copy link
Author

In the end we get indeed one file, but the time to make the file takes twice as long as we would expect (based on the shutter time). When we put the preview on we can also see that the previews before both callbacks are different. Therefore we get the impression there are 2 images captured instead of one.

@JamesH65
Copy link
Collaborator

It seems to still be doing an AGC/AWB pass on the first frame, which sets it up to take the actual image. Perhaps.

@6by9
Copy link
Contributor

6by9 commented Jul 24, 2020

All the raspicam apps start preview by default. If as frame has been requested, then it will be completed, therefore you get one preview frame and one capture frame. The preview frame is also used to collect some stats for AE and AWB to work with.

If you have fixed all parameters, then raspistill gained a mode to drop immediately into burst mode (so no preview).
See https://www.raspberrypi.org/forums/viewtopic.php?p=1663899#p1663899 / 2fe4ca3

It looks like we missed out the equivalent change to RaspiStillYUV.c, but exactly the same change should be applicable there.

@Ismael2878
Copy link
Author

I can indeed confirm it is working well with raspistill in combination with the burst mode.
Do you have any suggestions where we can adapt this in the RaspiStillYUV.c so the behavior will be the same ?

6by9 added a commit to 6by9/userland that referenced this issue Jul 27, 2020
…res.

Adds the equivalent to "Add option to start in burst mode if AE settings
are manual" patch to RaspiStillYUV so it too can drop straight into
capture mode.

See raspberrypi#640
@6by9
Copy link
Contributor

6by9 commented Jul 27, 2020

I needed to create a PR for userland, so have tacked this patch in as well. #645

pelwell pushed a commit that referenced this issue Jul 28, 2020
…res.

Adds the equivalent to "Add option to start in burst mode if AE settings
are manual" patch to RaspiStillYUV so it too can drop straight into
capture mode.

See #640
@Ruffio
Copy link

Ruffio commented Sep 14, 2020

Has this issue been resolved and it can be closed?

@6by9 6by9 added the Close within 30 days Issue will be closed within 30 days unless requested to stay open label Mar 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Close within 30 days Issue will be closed within 30 days unless requested to stay open
Projects
None yet
Development

No branches or pull requests

4 participants