Boris Conforty
Boris Conforty
@bkDJ Values were obtained on a Nokia 7.1 Android one.
@cristianoccazinsp The overhead here comes from processing the frame preview (YUV to RGB and resizing). The overhead is minimal in eco and fast modes, bigger in boost. The proposed implementation...
@cristianoccazinsp I did all my test using release 3.4.0. At what resolution do you get 0.5-1 second per capture?
@cristianoccazinsp I think no overhead can be perceived by the user in eco and fast modes
It seems your crash happens in ResolveTakenPictureAsyncTask.java, in the section of the code that handles the option `skipProcessing`. I'm not sure because I don't know what version of that file...
Line 75 (from your crash report above) is in the section that handles skipProcessing. Are you sure you've deactivated skipProcess? Are you sure that it's the same crash?
Oh, but I see, they did something wrong, they just check `mOptions.hasKey("skipProcessing")` instead of checking its value. Try to remove the option instead of setting it to false!...
It should be `mOptions.hasKey("skipProcessing") && mOptions.getBoolean("skipProcessing")` or something of the kind.
You can try, around line 75 of ResolveTakenPictureAsyncTask.java: ``` if (mImageData != null) { // Save byte array (it is already a JPEG) fOut.write(mImageData); } else if (mBitmap != null)...
As for the quality of the picture, no idea. I get very good pictures on my device.