Hi blindfold, could you please post your decoding algorithm for "YCbCr 420 semi- planar", so we can all profit from your findings.
Cheers On 13 Nov., 10:52, 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
