0

The title may be unclear, but I'm using this awesome library by CommonsWare(nice meeting you at DroidCon btw) to deal with the notorious issues with Android's fragmented camera api.

I want to take 5 photos, or frames..but not simultaneously. Each frame should capture another shot a few milliseconds apart, or presumably after the previous photo has been successfully captured. Can this be done?

I'm following the standalone implementation in the demos, and simply taking a photo using 

  mCapture.setOnClickListener(new View.OnClickListener() {
        @Override
        public void onClick(View view) {

            try {


                takePicture(true, false);


            }catch(Exception e){
                e.printStackTrace();
            }
        }
    });

Passing in true to takePicture() because I will need the resulting Bitmap. I also disabled single shot mode since I will want to take another photo right after the previous has be snapped, and the preview is resumed

By default, the result of taking a picture is to return the CameraFragment to preview mode, ready to take the next picture. If, instead, you only need the one picture, or you want to send the user to some other bit of UI first and do not want preview to start up again right away, override useSingleShotMode() in your CameraHost to return true. Or, call useSingleShotMode() on your SimpleCameraHost.Builder, passing in a boolean to use by default. Or, call useSingleShotMode() on your PictureTransaction, to control this for an individual picture.

I was looking for a callback like onPictureTaken() or something similar inside CameraHost, that would allow me to go ahead and snap another photo right away before releasing the camera, but I don't see anything like this. Anyone ever done something like this using this library? Can the illustious CommonsWare please shed some light on this as well(if you see this?)

Thank you!

Jade Byfield
  • 4,668
  • 5
  • 30
  • 41

1 Answers1

1

Read past the quoted paragraph to the next one, which begins with:

You will then probably want to use your own saveImage() implementation in your CameraHost to do whatever you want instead of restarting the preview. For example, you could start another activity to do something with the image.

If what you want is possible, you would call takePicture() again in saveImage() of your CameraHost, in addition to doing something with the image you received.

However:

  • Even with large heap enabled, you may not have enough heap space for what you are trying to do. You may need to explicitly choose a lower resolution image for the pictures.

  • This isn't exactly within the scope of the library. It may work, and I don't have a problem with it working, but being able to take N pictures in M seconds isn't part of the library's itch that I am (very very slowly) scratching. In particular, I don't think I have tested taking a picture with the preview already off, and there may be some issues in my code in that area.

  • Long-term, you may be better served with preview frame processing, rather than actually taking pictures.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • thanks for the reply. I'm trying to test how many photos I can take in succession starting with just 2, and as you said..calling takePicture() again in saveImage(). Still, only 1 photo gets taken and saved. I may not need the images to be saved to disk, and may only need a reference to the byte array of each..maybe keep a static list or something. Do you think removing the call to super.saveImage() would help here? At least in taking more than one photo? – Jade Byfield Oct 14 '14 at 15:24
  • I looked into the preview frame processing, but that would take me back to my initial reason for using your library...making the camera experience consistent as possible across most devices. It would have to be sort of a last resort kinda thing... – Jade Byfield Oct 14 '14 at 15:25
  • @JadeByfield: "Do you think removing the call to super.saveImage() would help here? At least in taking more than one photo?" -- possibly, but I doubt it. Whether the limitations are with my library or with the underlying `Camera` stuff, I couldn't say, as I have never tried what you're proposing. Also bear in mind that even if you get it to work, it will not be in a "few" milliseconds, at least in how I define "few". I would except cycle times measured in dozens to hundreds of milliseconds. – CommonsWare Oct 14 '14 at 19:42
  • 1
    @JadeByfield: "It would have to be sort of a last resort kinda thing" -- bear in mind that even with preview frames, 30fps or so is pretty decent. Hence, you're already looking at a couple dozen milliseconds there, and that's *without* the overhead of the actual picture-taking logic. Short of manufacturer-specific burst modes, you aren't going to get better than that. So, it comes back to how important the "few milliseconds" is. – CommonsWare Oct 14 '14 at 19:44