Bump. Similar issue here. I construct a custom backing buffer for preview frames, and would actually like to keep it even after the (higher resolution) picture is taken. Because there is also no Camera.removeCallbackBuffer function (could do this just before takePicture), the only 'work around' I can think of right now is: - user clicks 'take picture' - set pictureTakenFlag=true somewhere - wait until onPreviewFrame is called for the next preview frame - onPreviewFrame checks pictureTakenFlag, if true - doesn't reattach callback buffer - takePicture()
This is ugly, introduces unnecessary latency, etc. Any suggestions or good advise, and I owe you a beer :). / Emiel On Friday, January 7, 2011 9:49:08 AM UTC+1, Robert wrote: > > Bumping again.... > > I have the same issue... Looking at the JNI-layer both the > picturetaken and previewframe callbacks seem to end up running > > JNICameraContext::copyAndPost > > And that uses the size and buffer set by the call to > addCallbackBuffer.... Setting a large enough buffer able to hold both > preview-frames and encoded pictures solves the problem.... > You will only see the problem if the preview-frames are smaller than > an encoded picture... In my case I have a preview of 640x480 and 16bpp > --> 614400bytes.... the encoded pictures are roughly 1Mb ... --> No > callback! > > Since one can never know how big the encoded pictures are (you can > only calculate an upper limit, if you expect the encoded image to be > smaller than RAW format)... So if you have a picture size of 8MPixels > and 24bit colors, you need to actually have 24MiB buffers allocated to > be sure.... overkill! > > I really think that we should have two different methods to set > preview callback buffers and picture callback buffers. > > i.e. > add: addPreviewCallbackBuffer and addPictureCallbackBuffer > deprecate: addCallbackBuffer > > I also think that if the buffers are too small the JNI layer should > fallback to the old allocation-mode, print a warning, and return the > buffer anyway! Not discard it. > > Regards // Robert > > On Dec 14 2010, 11:14 pm, Stephen Lebed <srle...@gmail.com> wrote: > > In the app I'm working on, I'm using Camera.addCallbackBuffer and > > Camera.setPreviewCallbackWithBuffer to control the camera preview. > > BTW, this has been one of the best fixes in Froyo yet! No more GC > > anymore! > > > > I'm trying to take a picture, and sometimes it works, saving the image > > to the sd card, and sometimes it doesn't. When it doesn't work, the > > preview is frozen, but the app is still running. For instance, I can > > still call up the menu. So its not locking up the app at all. I've > > tracked it down to a memory allocation issue I believe. It seems that > > the camera is using the buffers from the preview to store the picture > > data. I could be wrong about this. I've upped the memory buffers > > used in the addCallbackBuffer, and it seems it fix the problem, but > > shouldn't there be a seperate buffer for the snapped picture data? > > > > Is there a way to allocate a buffer for the Camera.takePictureCallback > > routine to store the data into? > > Is there a better way to make sure the Camera has enough memory to use > > the addCallbackBuffers and take a full size photo? > > Is anyone else experiencing this problem using the camera preview > > buffers and taking a full size picture? > > > > Any help is greatly appreciated. > > > > Best, > > Stephen Lebed > > Developer of 'On The Level' and 'SL DigiSlate' -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
