7

I am working on some image processing and I am in need for the raw image data. But unfortunately this according to the documentation is optional and depends on the vendor.

I have been able to get the raw image on a LG Optimus Maha(mac / lu3000) android dev, are there any other devices out there in the market where it is supported?

Devices that do not support it (source - my experiments + google Issue 10910: Not able to Capture Raw Images)-

  • Motorola DroidX with Android 2.2.1
  • Samsung Galaxy
  • HTC Desire with Android 2.2
  • Nexus S
  • Nexus One

Would be great if someone has a different device and can try it..

More info on why the call back is not supported here

Community
  • 1
  • 1
bluefalcon
  • 4,225
  • 1
  • 32
  • 41
  • Have you tried using startPreview() and setPreviewCallback() instead of takePicture() ? – olivierg May 10 '11 at 12:22
  • My preview resolution is VGA (640x480) but the image I am trying to capture is 2M. If I use the setPreivewCallback will I not be getting the raw images at preview resolution? (I wanted 2M raw image data :) ) And increasing the preview resolution tends to make the app unstable across devices.. – bluefalcon May 10 '11 at 13:45
  • Sure, the preview resolution is lower, it's a... preview. But as you mentioned image processing, I thought you were maybe into feature extraction, image analysis... In which case, the quality and/or resolution may or may not be critical. – olivierg May 10 '11 at 13:49
  • You are pretty much on the dot, yes the feature extraction and image analysis can be done on the smaller image. I guess I was not clear, my end target needs to be on an image of resolution 2M. Any ideas on how I can do this? The only workaround I seem to come up with is to decode the compressed image and then use the raw image, which will have lost quite a bit of info... – bluefalcon May 10 '11 at 14:11
  • If you need high resolution, then decoding the compressed image is the only thing that comes to my mind indeed. But have you seen Camera.Parameters.setJpegQuality() ? – olivierg May 10 '11 at 14:34
  • I was thinking of the same thing. Hope that setting the quality to 100 the jpeg encoder will do a lossless compression. But really wanted to avoid this step.. well anyway thanks a lot! – bluefalcon May 10 '11 at 17:25
  • You're welcome! Thanks to this little discussion we had I was able to cook up an answer :) – olivierg May 10 '11 at 17:58

1 Answers1

6

The devices that you list are major ones. If raw image support isn't available on these then it affects a rather large market share. I don't have any precise numbers but according to my own market stats and the mails I've received over a year, I think that it's at the very least 30%.

Also, not only is it an important market share, but it is also some of the most powerful devices currently. Precisely the ones that power users have in their hands. If I tell you my feeling, it's 50% of app buyers (not necessarily 50% of devices), but it's just an intuition.

So my opinion is that you need to be able to handle JPEG data nicely, by decoding on the fly prior to image processing. Pay good attention and optimize this JPEG fallback. If you are worried about quality, give a try to Camera.Parameters.setJpegQuality()

Also, I'm not sure why you are looking for a device list. Maybe it's for your personal/business stats, but if it's about compatibility, then it's certainly better to discover if raw support is supported dynamically, when the camera is first accessed and cache this as long as some android.os.Build constants don't change.

That said, forgetting about raw image and relying only on JPEG could simplify your pipeline and ease testing. That's worth considering too. I think I would go that route, because if raw support is rare, then it's not used by many apps, poorly tested, and so "raw" could be anything. JPEG is very much used so it's properly tested, that's important.

olivierg
  • 10,200
  • 4
  • 30
  • 33
  • But I am still on the lookout for a list of devices.. :) – bluefalcon May 11 '11 at 05:05
  • Thanks for accepting my answer. At some point in time, a couple of other (audio) devs and I wanted to craft an application to gather statistics about audio characteristics of the devices. An app to install from the market, which some users could find useful to know more about their system. That app would also automatically send the characteristics to a server, to help us devs deal with massive "fragmentation". At some point I also thought about analyzing video support, etc... And in your case, that would be image formats. Not much time to start this project, but you might consider the idea. – olivierg May 11 '11 at 14:03