CODEWITHSUNDEEP
androidandroid-imagebitmapfactory
DeeV
DeeV

Reputation: 36035

BitmapFactory.Options#outWidth returns different size than actual bitmap

I am writing a custom class. There is a bitmap that needs to be calculated for some pre-processing and sizing before it actually gets drawn. The bitmap itself is a pre-processed 9-patch image. In the constructor, there is this code:

BitmapFactory.Options bmpOptions = new BitmapFactory.Options();
bmpOptions.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), BITMAP_ID, bmpOptions);
Bitmap bmp = BitmapFactory.decodeResource(getResources(), BITMAP_ID);
        
Log.d(getClass().getSimpleName(), "width: " + bmp.getWidth() + " " + bmpOptions.outWidth + "; height: " + bmp.getHeight() + " " + bmpOptions.outHeight);

Output on the 7" Samsung Galaxy Tab 7 running Android 3.2.2:

width: 556 556; height: 890 890

Output on the 10" Motorola Xoom running Android 4.1:

width: 556 556; height: 890 890

Output on the 7" Nexus 7 running Android 4.2.2:

width: 740 834; height; 1185 1335

The actual dimensions of the bitmap are:

mdpi: 558 x 892

hdpi: 836 x 1337

The bitmap is a pre-processed 9-patch which is why the sizes are off by 2 pixels. I can not understand why the hdpi assets on the Nexus 7 would make this much of a difference.

I have tried these configurations as well:

bmpOptions.inScaled = false;

and

bmpOptions.inTargetDensity = getResources().getDisplayMetrics().densityDpi;

and

bmpOptions.inTargetDensity = getResources().getDisplayMetrics().densityDpi;
bmpOptions.inDensity = getResources().getDisplayMetrics().densityDpi;

and

bmpOptions.inTargetDensity = 0;
bmpOptions.inDensity = 0;

I have also tried the opposite approach and create a second BitmapFactory.Options for the decoded bitmap and tell it to not scale at all.

All of these provide the same exact results.

Upvotes: 1

Views: 3629

Answers (3)

Ruslan Yanchyshyn
Ruslan Yanchyshyn

Reputation: 2784

To get the actual image size using inJustDecodeBounds option, you need to multiply returned outWidth and outHeight by scale coefficient, which equals to inTargetDensity/inDensity. The sample code is:

public static void getBitmapDims(Resources res, int resId, Holder<Integer> width, Holder<Integer> height)
{
    BitmapFactory.Options opts = new BitmapFactory.Options();
    opts.inJustDecodeBounds = true;
    BitmapFactory.decodeResource(res, resId, opts);

    float scale = (float) opts.inTargetDensity / opts.inDensity;

    width.value = (int) (opts.outWidth * scale + 0.5f);
    height.value = (int) (opts.outHeight * scale + 0.5f);
}

Upvotes: 5

android developer
android developer

Reputation: 116402

The first 3 lines don't affect the 4th line since the 4th line don't use any of the variables above it. also the "bmpOptions" doesn't get used or filled at all. maybe you've renamed the variables while posting this question?

also, is it possible that the bitmap image file is located on folder that has a density qualifier (or the default one which is like mdpi) ?

only if you put the file into the drawable-nodpi, you will always get the same number of pixels for width&height.

Upvotes: 2

Streets Of Boston
Streets Of Boston

Reputation: 12596

Could it be the fact that the Nexus 7 screen is tv dpi and loads the bitmaps from drawable-h dpi? It is still weird, though, that the outXXXX values don't match the final width/height of the bitmap.

Upvotes: 1

Related Questions