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 [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
-~----------~----~----~----~------~----~------~--~---
