Apologies in advance if the question sounds dumb.Here's my problem
I want to make an OCR app for android smartphones.I am wondering if someone can tell me how much RAM and processor will be enough for image processing involved in it?I am trying to extract all the text from a printed A4 page in one go, how much should be the camera resolution for having a clear image of all characters?
In my experience the most important hardware requirement might not be RAM and processor but rather camera auto-focus feature. If mobile device does not have auto-focus feature then in majority of cases you can't get proper scanning results.
Second, mobile device cameras (at time of this writing) are not suitable for A4 document scanning in one pass (unless you have a very large font on the document :). The quality of scanning results will be poor even with top quality mobile devices. Good results can be achieved with documents that are about one third the size of A4 documents with mid and high-level devices.
Disclaimer: I work for a company that has developed own mobile OCR and other mobile vision software that are used across different industries.
Same as with most questions related to hardware requirements:
You'll probably find out by testing with different hardware setups.
As you'll need to test Android apps with various devices anyway, that should not be a big deal.
We can't know the font size and neither can we estimate the complexity of your algorithms. Also I assume that the font(s) which you use has an important influence, depending on the distinctness of their chars rendering.
Plus, if the image is blurred, that'll negatively influence the resources you need.
Related
I was checking the feasibility of number of computer vision model that can run on the android devices simultaneously but could not find any resource for it.
I have two computer vision models, one is doing classification of images about 20 classes and another one I want to integrate is the image depth map model. Both of them will work on real time. Thus I want to know will they able to run on Android devices with limited ram of 1 Giga Byte.
My own experience is that this is highly dependent on hardware as well as the neural network architectures themselves and optimization methods performed on them. So there is not exact answer to your question.
However, I can tell you that 10 FPS will be very hard to achieve, specially with 1GB of RAM on an old device I assume. I have a TFLite Yolov5s model, quantized to INT8 which I pass 320x320 images to, running on an old Samsung tablet from 2015 (3GB of RAM), achieving an average inference time of 0.47 seconds. This is only one model.
Is there a way in android to publish different APKs based on various heuristics such as
Total available memory
CPU speed/type
Storage space
Even brand name (Samsung or Nexus or whatever)
I know there's a way to do it for different screens but let's say you would like to have more animations and better resolution images and more graphic/CPU intensive operations for higher end phones and tablets but still provide basic level functionality (albeit with reduced function set or a more basic UI) for older/less powerful phones.
Is this possible? If not, I fear I have to cater for the lowest end of the market and won't be able to make use of the better hardware that some users may be using.
Many thanks,
p.s. I'd seen this before I posted my question http://developer.android.com/google/play/publishing/multiple-apks.html but it doesn't quite answer this question which is why I posted my question.
Why it doesn't answer my question is because it only mentions the following attributes for determining which APK would be available for a device:
OpenGL texture compression formats
Screen size (and, optionally, screen density)
Device feature sets
API level
CPU architecture (ABI)
However, it does not mention the memory, storage space or the CPU speed (though CPU architecture may... I have no idea) which would be ideal to have to decide whether or not to load a reduced set of resources and functionality or not which is why I don't believe the mentioned link quite answers my question.
I want to control the aperture, shutter speed and ISO on my android phone. Is there a way in which I can access the hardware features?
I won't say it's impossible to do this, but it IS effectively impossible to do it in a way that's generalizable to all -- or even many -- Android phones. If you stray from the official path defined by the Android API, you're pretty much on your own, and this is basically an embedded hardware development project.
Let's start with the basics: you need a schematic of the camera subsystem and datasheets for everything in the image pipeline. For every phone you intend to support. In some cases, you might find a few phones with more or less identical camera subsystems (particularly when you're talking about slightly-different carrier-specific models sold in the US), and occasionally you might get lucky enough to have a lot of similarity between the phone you care about and a Nexus phone.
This is no small feat. As far as I know, not even NEXUS phones have official schematics released. Popular phones (especially Samsung and HTC) usually get teardowns published, so everyone knows the broad details (camera module, video-encoding chipset, etc), but there's still a lot of guesswork involved in figuring out how it's all wired together.
Make no mistake -- this isn't casual hacking territory. If terms like I2C, SPI, MMC, and iDCT mean nothing to you, you aren't likely to get very far. If you don't literally understand how CMOS image sensors are read serially, and how bayer arrays are used to produce RGB images, you're almost certainly in over your head.
That doesn't mean you should throw in the towel and give up... but it DOES mean that trying to hack the camera on a commercial Android phone probably isn't the best place to start. There's a lot of background knowledge you're going to need in order to pull off a project like this, and you really need to acquire that knowledge from a hardware platform that YOU control & have proper documentation for. Make no mistake... on the hierarchy of "hard" Android software projects, this ranks pretty close to the top of the list.
My suggestion (simplified and condensed a bit): buy a Raspberry Pi, and learn how to light up a LED from a GPIO pin. Then learn how to selectively light up 8 LEDs through an 74HC595 shift register. Then buy a SPI-addressed flash chip on a breakout board, and learn how to write to it. At some point, buy a video image sensor with "serial" (fyi, "serial" != "rs232") interface from somebody like Sparkfun.com & learn how to read it one frame at a time, and dump the raw RGB data to flash. Learn how to use i2c to read and write the camera's control registers. At this point, you MIGHT be ready to tackle the camera in an Android phone for single photos.
If you're determined to start with an Android phone, at least stick to "Nexus" devices for now, and don't buy the phone (if you don't already own it) until you have the schematics, datasheets, and sourcecode in your possession. Don't buy the phone thinking you'll be able to trace the schematic yourself. You won't. At least, not unless you're a grad student and have one hell of a graduate-level electronics lab (with X-Ray capabilities) at your disposal. Most of these chips and modules are micro-BGA. You aren't going to trace them with a multimeter, and every Android camera I'm aware of has most of its low-level driver logic hidden in loadable kernel modules whose source isn't available.
That said, I'd dearly love to see somebody pull a project like this off. :-)
Android has published online training which contain all the information you need:
You can find it here - Media APIs
However, there are limitations, not all hardware's support all kind of parameters.
And if I recall correctly, you can't control the shutter speed and ISO.
I want to transplant a 3D program written in OpenGL on windows platform to Android, but I wonder if it can run smoothly on general Android platforms, so i want to estimate how much hardware resource is sufficient for it to run smoothly. It is some kind like the hardware requirements for a software or 3d game that a company will recommend the users. I don't know how can i get a hardware requirements of my program when transplant to Android.
i used gdebugger and it gave me some information but i don't think that is enough for me. Anyone here have some idea or solution? Many thanks in advance!
If your program is simple enough, you could write up some estimates about texture fill rate, which is a pretty basic (and old) metric of rendering performance. Nearly every 3D chip comes with a theoretical fill rate, so you can get the theoretical numbers of both your desktop system and some Android phones.
The texture memory footprint is another thing that you can estimate, especially using gdebugger. Once again, these numbers are known for most chips.
This is a quick way to produce some numbers, obviously without any real life performance guarantees.
The best way would be to test it on an actual device, and get an idea of what hardware works well. You could distribute a beta app and get some feedback too.
Depends on feature set that you use. For example, if you use FBO, the device will have to support framebuffer extension. If you use MSAA, smooth line, the device will have support corresponding extensions.
After listing down your requirements, you can use glGet to check for the device suppport
http://www.opengl.org/sdk/docs/man/xhtml/glGet.xml
I'm interested in using Android for a E-Ink
based platform. I know it has been demonstrated once by MOTO, but I'm interested in using it for a commercial grade product and not 'just' a technology demo. I have got a question on the ability to change the platform to cope with specific display effect caused by E-Ink. I'm asking this question from the role of system architect and have no prior experience with Android.
E-ink has several characteristics which are very different than the common LCD displays:
time to update display (50-700ms)
it costs power to change the display (none to maintain)
display life time is determined by number of display updates!
tradeoffs can be made between quality, performance and display lifetime
grayscale versions available
The great thing: it costs no power to retain display information and they can be read in bright sunlight with no backlight. Also the display can be literally as thin as paper...
This means that the platform software needs to have a degree of control over the number of display updates and the type of display updates to get the best performance. Otherwise, an application which is unaware of the display characteristics could quickly drain the battery, or worse, shorten display life time to months instead of years. Conceptually I'd be interested in replacing a display driver, but I'm not sure if this part is open. I know it is hard to get info on the Qualcomm chipsets....
My question: can this be done? Can the Android platform be modified to support a drastically different display effect? Any pointers to an android roadmap?
The reason I find Android interesting for this application is because there is a significant overlap in functionality (from cell phone to browser).
Thanks!
I cannot agree more and started to lobby with app and OS developers on improving readability on e-ink:
Make scrolling and page turns e-ink friendly http://github.com/aarddict/android/issues/28#issuecomment-3512595
Looking around on the web I find a recurring theme "we had to rebuild WebView from scratch to adapt it to the e-ink display"
There are already coding solutions which reduce flicker and page refreshes. Most of them are kept by those who market the e-ink readers who prefer to keep them as frontends to their shops.
I contacted the author(s) of cool reader on their implementation of
smooth scrolling on e-ink devices and got the following reply:
Hello, Look at N2EpdController.java Author
is DairyKnight from xda-developers. At least you can use it under GPL.
For use in closed project I would recommend to contact him.
Ideally, display components for e-ink devices should be part of the Webkit's WebView framework. I've submitted a feature request via
http://bugs.webkit.org/show_bug.cgi?id=76429
fyi, E-Ink has an Android on E-Ink development kit, AM350 that's being sold now. http://www.eink.com/sell_sheets/AM350_Kit_Sell_Sheet.pdf
http://www.linuxworld.com/news/2007/112707-kernel.html
In this case the application domain is e-reading, in which case the advantages of E-ink are more imporant than the disadvantages (slow display updates).
I've done some further studies of Android. I believe the trick is to perform display updates asynchronously; to provide applications with an environment which mimicks immediate display updates, whilst detecting the relevant updates (i.e. by using graphics processor and/or MMU) to have an intelligent display update. Not all types of applications would be suitable; i.e. games and video playback require immediate display updates.
Making such a platform will be less than trivial; however, with the growing number of different hardware platforms, abstractions are becoming better all the time.
I know this is an old question, but I have found it through Google - others might want to know this too.
PocketBook Pro 902/903 are based on Android and feature e-ink screen. You might want to check them out. There might be other models too - I am interested in these because of their 10" screen. YMMV.