Sizing ImageViews Based off of Image Size - android

I know that the title makes it sound like it is a duplicate, but I think I have a very specific situation here that I can't solve from all of my searches.
First, I have images that are specifically sized based off of a specific monitor (Yes, monitor. Not handheld device's screen). The images are based off of these specific settings:
1600x900 20" monitor at 96ppi
Now, all of the images must be sized in millimeters (they are square images btw, so Height=Width). Using these specific settings as a determining factor, 1mm = 3.78px. So, my images are sized using this. For example, for an image to appear as 65mm, I size the images to 246px. I tested this in Photoshop using these settings, and measuring the image on the screen did in fact come out correct.
So now in my Android application, I load up these images into ImageViews to be displayed. This is where I am stuck. The device is an MDPI device. If I load the images into the MDPI drawables folder, the images appear too large on the monitor. Using my above example, I convert the Drawable to a Bitmap and dump the Height of the image to my log. This is correct and shows 246px, but for some reason it is measuring well over 85mm instead of 65mm.
If I load all of my images into the HDPI (yes, I know it is an mdpi device so it will be sized by the Android OS), the height of the image (using my example) dumps as 164px and appears at roughly 50mm. This is more explainable, but still I am still confused on how to get these images to appear as they did in Photoshop.
So my question is, what is the best way to programmatically size the ImageView to be the exact size of the image? For my example, I need to find out why my 246px square image (at 96ppi) is not showing up as 65mm like it should.
Because these ImageViews are generated programmatically, I have tried the following two things:
Set the ImageView Height and Width (using LayoutParams) to the height of the image (246px). I did this thinking WRAP_CONTENT was not acting as it should.
Used ImageView.ScaleType.CENTER to try and make sure the ImageView is sized exactly to the image.
Neither of these things seem to have effected the output.
UPDATES:
I have verified that my device is a MDPI device. This means that there is not DPI to PX conversion (or vice versa) necessary because of the 1:1 relationship. Somewhere, the sizes are being increased and I cannot determine where. As I indicated in the comments for the answer below, when I pull my Drawable and convert it to Bitmap, it pulls the EXACT pixel Height that I made it. I am starting to figure out the percentage of size difference from what it should be (65mm vs 85mm) and it works out to be 23.529%. I am scaling my bitmaps subtracting this value, but it ruins the quality of my image.
I am beginning to give up.
The device I am utilizing is an MK802III Rockchip Device (Amazon Link)

Android modifies all images for display with the following formula:
px = dp * (dpi / 160)
Where "dpi" is the screen density in dots-per-inch of a device's display.
Additionally, Android looks through a hierarchy of drawable folders when deciding which image to display. As we all know, an HDPI device will use an image from the drawale-hdpi folder while an MDPI device will display the same named image from the drawable-mdpi directory.
However, when an MDPI device cannot find an image in the drawable-mdpi directory, it will eventually choose from the drawable-hdpi folder, but it will down-scale the image for display on the MDPI screen.
This explains why your image appears smaller when you saved it in the drawable-hdpi folder.
But, it does not explain why the image appears too large when correctly placed in the drawable-mdpi folder.
It so happens that:
65mm ~= 85mm * (120 / 160)
50mm ~= 85mm * (120 / 240)
This is the scaling that I would expect for your images if your device were LDPI (120dpi) instead of MDPI (160dpi) as reported.

I hate answering my own question, but I am just going to update everyone what I did. If someone comes up with a better solution, I am all ears. I had to force this along because I am on a tight deadline.
I created a dummy application that dumped boxes that I could measure. Using these, I determined that 1 millimeter is 3 density pixels. Let me repeat that, 1mm = 3dp.
Using this value, I resized all of my images (utilizing a PHP script) to this constraint. All of my images are appearing as normal. 195dp = 65mm, and it appears as such.
Like I said, any explanation as to why I had to do this and you get an upvote and answer.

Related

My app slows down when background image is added in the drawable folder

I have read on this forum that the answer is to split the image in different resolutions and put it in different folders and the other way is to put the image in one folder without splitting it up so that android doesn't resize it.
My question is in which folder exactly do we put it on so it doesn't resize itself and shows as it is?
My res folder looks like this
Based on your updated question with the image and the clarity.
You are asking how to avoid scaling. You can either use the drawable directory or the drawable-nodpi to avoid prescaling. Either one will work for you.
I made a document on this once for the UI team I was working with, so this document is a little specific to their request and that app, but it might help you.
https://drive.google.com/file/d/1gJjT-F5AU57TCAr5I18l0jAvNG5-vLUb/view?usp=sharing
For vector drawables just use "drawable" standard directory. Make sure you are not violating any of the unsupported tags such as gradients and linear tags or you will have issues.
Next the -24 -26, etc.. folders are used for version specific. For example, let's say you have one type of image for pre 24 Android, but a different type for post 24, you can use -24 for the post image, and all others will check standard folder for it. This sometimes happens when you use something bleeding edge that isn't supported back far enough for your app's minimum SDK. You are not likely to use this for images, I can't even think of a problem where this would arise in the image buckets, but it's there all the same.
For deciding what resolution you need for each bucket, there are a couple of options here. First you could simply do the math. Decide how many inches you want it to take up and determine how many pixels are needed to accomodate that size and label that MDPI, than scale from there using the multipliers. Another less mathematical solution would be to open a preview on Android select an MDPI device and start playing with width = 100px height = 100px and adjust until you like the size. Write that down, it is MDPI, and begin your scaling from there.
As for a rough estimate of pixels to size, you can see what an app icon looks like and see what Android uses for that below.
So even though each bucket has a different pixel by pixel resolution, they will be identical sized and pixels per inch resolution on all devices due to bucket placement.
Hopefully that all makes sense.
--I'll leave the below from the original answer in case it helps someone--
You may have gotten some bad information.
https://developer.android.com/training/multiscreen/screendensities
Android is a widely dispersed resolution and size market.
In order to accommodate this they allow for DP and Buckets.
There are buckets for languages, screensizes, orientation, and resolutions.
You are looking for resolution support.
drawable-ldpi -.75 multiplier on size (1dp = .75px)
drawable-mdpi -baseline 1dp = 1px
drawable-hdpi -1.5x multiplier on size (1dp = 1.5px
drawable-xhdpi -2x multiplier on size (1dp = 2px
drawable-xxhdpi -3x multiplier on size (1dp = 3px
drawable-xxxhdpi -4x mulipvlier on size (1dp = 4px
each bucket has a multiplier associated to help the image look the same approximate size on each device. So even though it is 1 inch by 1 inch on one mdpi phone with your 100px x 100px image (pseudo size, don't calculate it ;)
it will need to be 150px x 150px on the hdpi to have the same quality and resolution of pixels per inch.
Now if you put all your images in the drawable bucket. Android will just ignore the scaling of these and you end up with varying space consumption depending on the device which will be very inconsistent on how much space it takes up on each type of phone.
If you put all your images in the correct folder you will at least have better quality. For example, let's say you have maybe 750px x 750px image that is meant to fill up a 1 inch area. You would be better suited to put it in the XXHDPI folder or XXXHDPI folder so Android knows to scale it DOWN rather than UP. This will give you better resolution for each device resolution that it scales for.
However, this is still poor practice. You are relying on Android operating system which can be very slow and weak on many cheap devices to do your scaling for you. I would recommend using GIMP and scaling to each multiplier on your own, then putting it into the respective resolution buckets.
This way Android decides based on the device which bucket resolution image it needs which decreases the amount of scaling exponentially.
Now, if you have Vector Graphics that you have imported, those will end up in the drawable folder which tells Android to ignore the resolution, and just draw these as vector graphics. This is the best option in my opinion as you only need one set of images per image. Although, Vector graphics aren't quite as fast at loading as a JPG or PNG, but it keeps your package size down quite a bit and development maintenance is so much nicer.
Hope that helps.
Happy Coding.

Pixel dimensions for different DPIs for a full screen image?

I'm trying to make an activity with an image that is the same height as the screen. I tried going to easy route, and just using a really big image and then scaling it down within the app, but when I run it on a device with a smaller screen, I get an error saying the device ran out of memory. I was hoping to make several drawable folders for each dpi (drawable-mdpi, drawable-hdpi, etc.). I looked up the pixel dimensions for splash screens, but when I resize my image to fit those dimensions (https://stackoverflow.com/a/15744389/5909429), the image only fills about half the screen on my smaller device.
What dimensions should I actually use, or am I using the drawable folders wrong?
[...]or am I using the drawable folders wrong?
Yes and no. I don't know about any "perfect" values for your picture dimensions, and I doubt that there are any, due to the fact that there are too many different phones to support.
The usage of dpi ensures that everything has the same size. If you were to put a ruler on your screens on a xxxhdpi and a ldpi device, both pictures would be the same size. This is dpi.
What you are trying to do is filling a phone screen. This has not much to do with dpi, but is about the actual pixel size of the screen. If you have a 1920x1080 phone display, you want an image with the same resolution. This does not say anything about dpi or screen density, and it has frankly nothing to do with it.
To properly scale down your image—and not running into OOM—you can either use a designated image loading library, like Glide, or Picasso, or you can take a look at BitmapFactory which lets you supply a inSampleSize to load the image in the size needed yourself. The official documentation can be found here at Loading large bitmaps efficiently.

What is best way to create drawable asset?

If I put my application resources in drawable-xdpi then it is automatically down converted for hdpi, mdpi and ldpi by ration 0.75, 0.05 and so on.
Why we need to create extra resource if one type is enough only?
I believe it is enough if I create for xhdpi and let Android down scales automatically. I have gone through this question
What is the best way to create drawables for different dpi
but no one has given answer that yes you can go this way.
Suppose I kept my images in xhdpi and when app opens in hdpi it will reduce size to 0.75, when it opens in mdpi it reduces size to 0.5.
So what is best way to create draw able asset? Please suggest perfect way with valid reason.
If not needed why we are creating so many resources instead for one only like xdpi?
There are two reasons to provide more than one image:
it is more efficient to load an image that is already the correct size.
The automatic downscaling may produce artifacts, which can be disturbing especially for small images. So if you want a pixel perfect image it is better to provide one in the correct size.
If none of them is a problem for you, it is also fine to go just with one image.
If u want to display same image with different resolutions in devices
xhdpi image then place it drawable-xhdpi
hdpi image then place it in drawable-hdpi**
or to maintain a drawable folder place all the images what you want to display it will display with same size in all devices irrespective of the resolution.

Trick to supply resources to different drawable folders

Everytime, when I supply resource to drawable folder, here is what I did
drawable-xhdpi (96x96 px)
drawable-hdpi (72x72 px)
drawable-mdpi (48x48 px)
drawable-ldpi (36x36 px)
Most of the time, I merely use GIMP to perform dummy scale down from the largest size image from drawable-xhdpi. I do not perform any further pixel editing on the scaled down image.
Recently, I realize, if I only supply 1 highest resolution image, Android system will internally perform image size scale down.
drawable-xhdpi (96x96 px)
drawable-hdpi (empty)
drawable-mdpi (empty)
drawable-ldpi (empty)
I tested on 2 devices. It works for me. I was wondering is this a good technique to avoid cumbersome work to supply so many different size images? Any side effect on this technique?
I was wondering is this a good technique to avoid cumbersome work to
supply so many different size images? Any side effect on this
technique?
I imagine there are (at least) two:
This may not always work with 9-patches, especially if the stretchable area is defined by one or more single pixels. For example, if you would provide such a 9patch as xhdpi drawable, then on an mdpi device that single pixel will effectively be 'halved' and thus either disappear completely or blended with the surrounding transparent pixels. The latter is generally true for any upscale/downscale operation, so it's quite likely that your 9patch will not appear as intended.
Larger images will simply take up more space in memory. Especially on low(er)-end devices, with a limited amount of internal memory and a reasonably strict heap space limit, you're likely to run out of memory fast when loading images way larger than required for displaying.
Regarding your comment: it's fairly easy to come up with a sample 9patch that will not visually look as intended across all different screen densities if you supply it only as xhdpi resource. Consider the following 9patch:
Enlarged snapshot for the sake of visibility:
Obviously, the idea is that when this 9patch gets stretched, the result is a 1-pixel thick horizontal blue line. Now, drop this 9patch in just the xhdpi folder and compare the results on xhdpi vs. mdpi:
Clearly, the mdpi device has scaled down the 9patch from the xhdpi folder and the result doesn't look like intended.
Anyways, my point is that in a lot of cases not supplying 9patches for every density bucket may end up looking fine. Just be aware of the fact that there are definitely scenarios out there for which it may not give the desired result. Also, take into consideration the memory argument.
The technique you are using will work on fewer number of devices..
Because in market there are a lot of phones with different resolutions and different sizes.
In some low resolution devices whose screen size in smaller,the UI will not look proper...
Now take an example that you are using a background image for splash screen whose resolution is 720*1280(xhdpi) and you have put it in Xhdpi drawable folder than when you view this drawable in low end device like Samsung euopa or HTC wildfire the image would look squeezed type.
there would be a lot other situation where you would be required to use different set of images....
If the technique mentioned by you would work in all phones then why would had Android developed different folder for different set of images.... :P

Handling image resource size on Android

I am kind of confused about managing graphic resources in Android.
Tried to read this doc but It only confuses me more. Can anyone give me some example of how should I handle the following case?
Lets assume that I have an image in my layout that will be scaled to fill screen width. What image sizes (in pixels) should I produce and what configuration qualifiers (drawable-{qualifier}) should I apply to those resources to cover all major dpi and screen sizes (both for tablet and handset)?
Thanks.
If you want to have an image, that is supposed to fill the screen it is best to use 9-patch images. This way your image can automatically scale to fit the device. Because even if an image has the correct density, the actual screen size can vary. For example a smartphone and a tablet can both be hdpi, but have completely different screen sizes (and actual pixel count).
So the easiest way to target most devices, when it comes to images that are supposed to fill up the full width of the screen is to have a 9-patch image and create ldpi, mdpi, hdpi and xhdpi versions of it. This way the image will automatically be choosen depending on the density and then stretched to fit the device.
The android sdk also provides a tool that helps with creating 9-patch images http://developer.android.com/tools/help/draw9patch.html

Categories

Resources