http://groups.google.com.br/group/grupomdo?hl=pt-BR ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Android Developers" <android-developers@googlegroups.com> Sent: Thursday, November 13, 2008 1:13 PM Subject: [android-developers] Re: G1 camera preview issues uncovered
> > A bug has been filed to correct the documentation. > > On Nov 13, 1:52 am, blindfold <[EMAIL PROTECTED]> wrote: >> I hope to have clarified the importance of defining a hardware- >> independent standard for preview images, for processing of preview >> images by applications (i.e., image processing, computer vision, >> augmented reality, etc). A standard preview image format is an >> absolute requirement for making Android future-proof for when other >> Android phones with other image sensors hit the market. Application >> developers cannot and should not keep track of increasing diversity in >> (future) native image sensor formats. Under Microsoft Windows too, it >> is the responsibility of the webcam manufacturer/vendor to provide >> drivers that offer standard VfW or WDM programming interfaces to the >> Windows application developer, no matter what the native image sensor >> data format is for the webcam's sensor. >> >> I do not care *what* standard you pick, YCbCr420SP, YCbCr422, >> whatever, as long as there will be at least ONE documented standard >> preview format for the data[] in onPreviewFrame() that must be >> supported at application level by all Android camera phones, plus for >> performance reasons matching support by BitmapFactory.decodeByteArray >> (). Mapping between any native preview format and standard preview >> format (in data[]) must be done at camera device driver level. Lacking >> that, development of camera-based processing on Android phones will >> become a maintenance headache (read: an unmanageable mess and a reason >> to pick another platform). >> >> I am surprised that the Android Team does not yet indicate that they >> will tackle this key issue. There is more to it than mere bug fixing. >> I can today already work around the current G1 camera bugs after I >> recently reverse engineered its peculiarities with testing help from >> other developers represented in this group, so that is much less >> important to me than ensuring that my (and other people's) apps will >> not immediately break on the next Android phone because of non- >> standardized/unspecified/unsupported camera preview formats in Google >> Android, and the lack of a clear minimum spec with respect to required >> support for at least one standard camera preview format. >> >> The Android SDK 1.0 r1 documentation for setPreviewFormat() currently >> reads "pixel_format - the desired preview picture format >> (PixelFormat.YCbCr_422_SP, PixelFormat.RGB_565, or PixelFormat.JPEG). >> Apart from the asynchronous processing quirks, the T-Mobile G1 >> currently supports NONE of these documented formats (with their >> corresponding format headers), or else one could have applied >> BitmapFactory.decodeByteArray(). Instead, the G1 generates that >> undocumented headerless "YCbCr 420 semi-planar" variant that one must >> decode pixel-by-pixel at application level, and it is unclear which of >> the documented formats an Android phone should in the future support >> as a minimum? >> >> Regards >> >> On Nov 12, 8:10 pm, "[EMAIL PROTECTED]" >> >> <[EMAIL PROTECTED]> wrote: >> > Bug reports have been responded to. Summary: >> >> > Camera preview is actually YCbCr 420 semi-planar. Preview frame size >> > issues is a known bug. > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
