I've build an application that uses Tesseract (V3.03 rc1) to identify some specific text strings. These are, unfortunately, printed on a custom font that requires that I build my own traineddata file. I've built the application on both iOS (using https://github.com/gali8/Tesseract-OCR-iOS for inspiration) and Android (using https://github.com/rmtheis/tess-two/ for inspiration as well).
The workflow for both platforms is as follows:
I select a bounding box on the preview screen for where I can crop out the relevant text, and crop the image accordingly.
I use OpenCV to get a binary image (using OpenCV's adaptive threshold function with the same parameters for both platforms)
I pass this binary image to Tesseract. Both platforms (Android and iOS) use the same traineddata file.
And yet, iOS recognizes the text strings perfectly, while Android keeps misidentifying certain characters (6s for Ss, As for Hs).
On both platforms, I use the same white list string, I disable load_type_dawg and load_system_dawg, and also choose to save the blob choices.
Has anyone encountered this kind of situation before? Am I missing a setting on Android that's automatically handled in iOS? Is there something particular about Android that hasn't crossed my mind?
Any thoughts or advice would be greatly appreciated!
So, after a lot of work, I found out what was wrong with my Android application (thankfully, it wasn't an issue with Tesseract at all). As I'm more familiar with iOS apps than Android, I wasn't sure how I could load the traineddata file onto the application without requiring the user to have the file loaded on their external storage device. I found inspiration in this project (http://www.codeproject.com/Tips/840623/Android-Character-Recognition), as they autoload the trained data file.
However, I misunderstood how it worked. I originally thought that the TessDataManager did a file lookup on the project's local tesseract/tessdata folder in order to get the trained data file (as I do this also on iOS). However, that's not what it does. It, rather, checks the internal file structure (data/data/projectname/files/tesseract/tessdata/traineddatafilegoeshere) to see if the file exists and if it doesn't, it copies over the trained data file it keeps in the Resources/Raw directory. In my case, it defaulted to the eng file, so it never read my custom font file.
Hopefully this helps someone else having similar issues. Thanks to Robin and RmTheis for all of your help!
Related
It's possible that we start an android project in which it's necessary after recognising an image by camera to visualise a content generated in unity.
The easy part would be to use webGL to display it, but there is the problem of devices that do not support it directly. My question is if from android (and later iOs). It's possible to download a content of unity, load and visualise it in runtime?.
Is possible that I had to direct all the effort to generate that content in a .jar and then use something like dependency injection to load it?
I have already a unity scene in an activity but of course in project definition not in run time.
Any help or guidance would be welcome.
Unity builds levels into the final runtime executable, so adding a downloaded 'scene' directly is not possible. The best way around this is to create a 'generator' scene which can accept input from a downloaded text file, such as JSON, and use that to render the level.
However, this method does assume that all the possible objects that can be rendered are in your game as prefabs. If you're wanting to pull images from the net to be loaded into textures, the WWW class might get you started down the right path:
https://docs.unity3d.com/ScriptReference/WWW.LoadImageIntoTexture.html
I am working on a localization strategy for our Android product. Once the core product is installed, I would like the user to be able to download additional language packs. Our resources are mainly strings. Essentially, I would like to keep the external file in xml format, similar to how it is done for embedded resources. This way, the translators can also test their translations right away and there won't be any need for sending them back-n-forth.
I am wondering if anyone has done something similar? The biggest challenge I see is that for embedded resources, the key gets converted to a numeric value. For example, getString(R.string.hello) may not work.
On second thought, it would be nice if I can compile the external resource file, similar to what Android framework does when building the .apk file.
I have an iOS App localized (with Localizable.strings files).
I've built now an Android version. I understand the way the i18n is made on android but I would like to avoid redoing the i18n, as almost all the Strings have the same meaning between iOS and Android.
Are there any tools that will do this conversion, or at least speed up the process?
Edit:
Ideally I would like to find a method/tool that would do the following
Input:
'iOS Localizable.strings files-(en,fr,it,pt,etc)'
'res/values/strings.xml'
Output:
'res/values-en/strings.xml'
'res/values-fr/strings.xml'
'res/values-it/strings.xml'
'res/values-pt/strings.xml'
'res/values-etc/strings.xml'
There is a specialised service here: Loco.
There are threads here on SO which deal with conversation:
Are there any tools to convert an Iphone localized string file to a string resources file that can be used in Android?
Any tool to convert Android's XML localization to iPhone's .strings file?
Another possiblity would be to use an online translation service. These services accepts text not only in Android and iPhone but also in many other formats. Upload the android text and download the iPhone text. A list of available services can be found on SO, see Any collaborative tool/website to localize an Android app? Some of these services are commercial, but even these provide a 30days test period. But note that the main focus is on translation and not on conversation.
Here is some code that does that: https://github.com/wrapp/LocalizedStrings2Android
Put it in a jar and it is ready to use.
You can use this tool I created on JSFiddle:
https://jsfiddle.net/danielgindi/x9njj9gj/
[StackOverflow requires me to write some code here because of the JSFiddle link]
Just paste in your localization strings inside the correct box, and you'll get the converted version in the other boxes (Between Android, iOS, and JS).
This tries to preserve comments too.
Cheers!
I'm making a illustrated instruction for how to use an app that will be needed
for Android/iPhone
I'm not much into coding for Android and I though the client just needed the
illustration but he asks:
"We will need the illustration saved to a file that we can run on mobile devices (iPhone/Android) as well as the source code."
Isn't jpg enough? is there some additional code that you android programmers are
aware of?
No. In Android you can just use a Drawable. This can be a number of different file formats, including your jpeg. It may be good to have a look at Android Asset Studio. With this tool you can get a nice zip file for all your different screen densities. If you keep the file structure that asset studio outputs then Android will do all the heavy lifting for you.
It might also help you to know something about 9-patches. This is how Android knows how to resize and stretch your image. Asset Studio has an option to set this as well.
I'm porting a rather large game engine written in C++ from Windows/Mac to Android. There is a lot of pre-existing code to read assets for games. In addition, there is quite a bit of code doing file system calls (stat'ing the files to make sure they exist, looking up all of the files and directories inside of a directory, etc.)
Right now, I'm focusing on just getting something up and running as quickly as possible, so I'd prefer not to have to rewrite a lot of this. What would be a good way of getting our game assets onto the device and accessing them with minimal changes to our existing standard C++ file system API usage?
I've got some basic support implemented already using the Asset Manager API, but that doesn't support the file system calls and I'm concerned that the 1 MB asset size limit is going to bite me at some point.
I've also looked at OBB, but the tools for creating an OBB file don't look like they are part of the current SDK/NDK. Otherwise, that looks like it would be perfect.
Is it a horrible idea to package up all of the files and just extract them on the SD Card the first time the app is run? Or is there some better way of dealing with this?
Update: I'm also not very concerned on being able to run on a broad range of devices, I am specifically looking at newish tablets, probably the 10.1" Samsung Galaxy tab.
We ran into a similar problem in developing our (data-file-heavy) app, and we ended up deciding to keep the APK tiny and simply download our data files on first run; they're going to have to be downloaded either way, but a small APK works much better on older devices without a lot of internal storage. Plus, you can potentially rig up a way for people to copy over the files directly from their computer if they have a limited data plan or a slow internet connection on their phone.
The "Downloader" sample app in apps-for-android (confusingly buried under "Samples") is almost a fully-implemented solution for this - you can pretty much just plug in the particulars of your data files and let it do the rest.
I wrote an app that relies on putting a good amount of native code into the Android filesystem. I did this by packaging the files into the APK as 'resources'. Instead of pushing them to the SD card, you can put then into the application's private namespace, I.E. /data/data/com.yourdomain.yourapp/nativeFolder.
For details on how to accomplish this, you can see my answer to this question.
It's fairly simple to package to just unpack them on the first run and never worry about them again. Also, since they're under the application's namespace, they should be deleted if/when someone were to decide to delete your app.
EDIT:
This method can be used to put anything into the app's private area; /data/data/com.yourdomain.yourapp/
However, as far as I know, your application has to be the one to create all the folders and sub-folders in this area. Luckily this is fairly easy to do. For example to have your app make a folder:
Process mkdir = Runtime.getRuntime().exec("mkdir " +localPath);
That works as it would in most linux shells. I walked through the assets folder I packaged into my APK, made the corresponding directories and copied all the native files to those directories.
What you might be more concerned with is the limited Android shell. There are many commands that you might want that aren't present. stat for example isn't available, so all of this may be moot if your native code can't make it's system calls.