I have trained a deep-learning model using alexNet to classify car models. The data was collected from the web,including google image, flicker,.. etc.
The model was tested on a separate test set collected from the web 'many comes from flicker', and it works fine. However, I have build a simple android app, that takes a photo 'with landscape mode' and send it to the server to recognize the car. The performance on the mobile images are very poor. I have tested the images with the alexNet model trained on imageNet and the model didn't answer correctly these images.
I wonder, if there is any think i missed when applying mobile images.
Thanks.
You may want to add photos taken with a mobile device to your training data. If this is not possible maybe you can preprocess the image in a way to make it more like the images used for training (e.g. normalization).
Edit:
mean-image subtraction is not normalization. Normalization is subtracting the mean image and then dividing by the standard deviation. Both computed from the training set.
You should analyze both images. Maybe there are resolution / lightning changes etc. Without having a sample of both images it is hard to tell what exactly the difference is. However deep learning is notorious to being bad with changes in data acquisition.
2nd Edit:
Another point that might fail on mobile images is the resolution. CNN work on any resolution and if you pass in a 4000x2000 image to an imagenet it will probably find something different than on an 224x224 image. For this reason you might want to post a web image and a mobile image and we on stackoverflow might be able to tell you the difference.
Related
So, I've been researching on bitmap scaling using the bitmap factory.
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html
I'm doing so because the application I'm working on requires a gallery that allows users to submit their photos to be added to the gallery. These photos will then be read from a URL.
My theoretical problem is this: Considering the android devices can have as low as 16MB of memory, even scaling down the images is only delaying the inevitable unless only handling a single image. Whereas in my case, the amount of images that will be loaded could be hundreds. Meaning that even if they're scaled down, eventually one will reach that limit.
My only idea thus far are to load one image at a time, which is not preferable since users will have to wait between photo transitions.
That being said, is there anyone who has experience developing applications on android that handle 100's of images? If so, is there any theory you could share on handling all these images fluidly? It can obviously be done, as there are gallery applications available. I am just unsure how they accomplished it given the restraints.
Please note this is not a request on how to use the bitmap factory to scale images, as that question has been answered many times.
Rather a request on handling data amounts you know will exceed limitations.
The gallary apps should not be storing all thousands of images in memory. Use the Viewholder pattern such that the image views displayed will get recycled (this is forced upon you if you use RecyclerView). On backend use an image cache and keep a limit on it size.
See e.g. What is the benefit of ViewHolder? and How to release memory of bitmap using imageloader in android?
The Android gallary app source may be a good reference: https://android.googlesource.com/platform/packages/apps/Gallery/+/android-5.1.1_r18/src/com/android/camera
I have a server that communicates with my android app.
In a certain tab of the app it asks for pictures from the server.
The server sends in return all the URLs for the pictures, and the app displays the pictures in the same page.
A problems accures if I have too many pictures, then the app crashes.
I have one solution in mind - to keep two versions for every picture, one with high resolution (Full HD) and another with very low resolution just for preview.
When the app asks for all the pictures, the server will send the URLs for low resolution pics and only if user askes to enlarge a picture then the app will ask the server for the high resolution pics.
What do you think of this solution?
could you reccomend a best practice for this sort of things?
Use a specialized library. They'll handle the complexity behind dealing with remotely loaded images (download, show only when loaded, caching, resizing, etc.).
These come to my mind, investigate and choose the one you like better, but there are others
http://square.github.io/picasso/
https://github.com/nostra13/Android-Universal-Image-Loader
I am making an app and part of it will view PDF's. The pdf's are on a web server and downloaded to the app. I am trying to understand what happens when a viewer loads a pdf. If it is converted to an image then I would like to try converting the pdf to a png on the server and just using that copy to view in app as png is a lot less hassle to deal with.
The only reason I would not convert to png is if an android pdf viewer maintains the vector nature of the file as zooming is critical and I want a nice crisp image.
Ultimately someone is always going to convert the PDF to an image. Or better said to pixels because that is what you need to display on the tablet screen (or any screen that I know of). The question is who does the conversion, when it is done and how well and quickly it is done.
For a tablet viewer, the challenge is to do the conversion quickly enough not to bother the user with load times and that often goes at the price of quality. There are virtually no PDF viewing applications on either iOS or Android at this point that do a really good job at showing all intricacies of the PDF file format.
That being said, the quality is usually good enough and if the viewer is well implemented, zooming for a PDF file should be a no brainer. Zooming simply means for the application that the viewport (the part of the PDF page that is visible) is different, but it doesn't really change the algorithm used to convert the PDF page elements into pixels.
That is also the difference between you converting the PDF to an image on the server and the app converting it to pixels on the device. Your server likely has more calculation power (at least it might have :-)) but the application knows at which resolution it needs to convert to pixels and what part of the page it has to convert to pixels. And a good viewing application can use these details to adapt how it does the conversion to pixels. There are lots of optimisation algorithms that can be used to only render visible elements and take shortcuts based on knowing exactly what resolution will be used for rendering.
In short, yes, you can do the rendering on the server and feed an image to your viewer. But keep in mind that - especially while allowing the user to zoom - you'll get lots of data and probably poorer quality than when you let a good viewer handle things in PDF...
I have an app that uses a lot of images for drawables. However, because they are in high definition quality they take a lot of space. Is there anyway in android that I might be able to convert these images into text or since I am using Maya save them in a different format so that my app can draw them? In other words is there a way to create a code that draws the image via points given by text yet still has a good quality?
I am building a mobile application that will target iPhone/iPad and Android phones. The application will involve users taking photos and uploading to my server and later on the users will be able to look at those photos on their mobile devices (although not necessarily their own photos so an Android user might be looking at a photo taken with an iPhone).
Which sizes should I save the photos to be able to cover the most use cases? iPads are 1.333 W/H, most mobile phones are 1.5 or 1.333 W/H with some rare 1.666 W/H. Specifically:
iPad: 1024x768, iPad3: 2048x1536, iPhone and some other phones: 960x640, 480x320, 800x480.
To be able to keep it manageable, I need to decide on a few certain image sizes and save the photos in those sizes. I am not really looking for help on the technical side. I can do image scaling on the server side etc. I am looking for recommendations / best practices / lessons learned about image sizes before I go too far into building it.
Which sizes should I save the photos in to cover the most use cases?
Do you recommend any client side scaling before uploading to server to save on transfer time (for example scaling down 2048x1536 iPad photos) or should I always transfer originals?
How should I handle incompatible image sizes (showing a picture taken with an iPad on an Android device for example)? Should I pre-cut those images on my server before sending to client or should I let the client phone handle image resizing?
There is also the issue of UI. There will be other things on the page other than the photo maybe a button or two for navigation. Should I go for something smaller than the full screen size while keeping the same aspect ratio when saving pictures?
I know some of these questions don't have one answer and the answers are relative but I wanted to get some opinions. Thanks.
For Android, I think the best place for you to start would be here, it has a lot of information including standard screen sizes and how to display images while keeping them in the best possible quality.
http://developer.android.com/guide/practices/screens_support.html
I'd also suggest doing as much image manipulation as possible on your server. Images are a pain to work with on Android due to memory constraints and fragmentation. Two phones may store pictures taken the same way with different orientations, and there is no simple way to handle rotations, though it can be done (thankfully, I've yet to encounter a phone that incorrectly records Exif data, but I wouldn't be surprised if they existed...). The more you rely on the phone to do, the more chances you have for error due to manufacturers putting wrappers around and otherwise customizing how it handles media.
As for how to display, ideally if your back end is already doing a bunch of different resizes, you can include your screen density when you request the images and send the best size based on the dev guide. If you want to keep differences to a minimum, at least support med or high density for phones, and extra high density for tablets.
Just my two cents, I'm sure you'll have a lot of opinions. Good luck.
I don't have a full answer for you, but I do have some thoughts...
1) I'd suggest reducing the image sizes before uploading. If I were using your application and I had to upload a 4 meg photo, everytime I wanted to use your application, I'd probably pass. And as we venture forward, we're hitting much better technology in terms of camera phones; Nokia has released a 41 megapixel camera, which I'm guessing will create rather large images. Users having to download a 4-6 MB image is also not a great idea. Just some thoughts from a user point of view.
2) I wouldn't cut the images. You don't necessarily know what parts of the image aren't important, so how would you know where to crop it? Let the phone size the pictures accordingly and rely on the ability to zoom into pictures to see things at a larger size.
3) You could try to make a UI that hides buttons. If you have something really simple (like just going forward or backwards) you could rely on gesture controls (swiping) to move around your application. You can implement sliding drawers and menus that take up space temporarily, when in use, but give you the space back when you want to look at the main content (pictures, in your case). I've typically found that hiding buttons doesn't work well and people seem to want/search for buttons that let them navigate, but the Android gallery works just fine with menu + swiping only, so who really knows.