BitmapFactory.Options＃outWidth返回與實際位圖不同的大小

我在寫一個自定義類。有一個位圖需要在實際繪製前進行一些預處理和大小計算。位圖本身是一個預處理的9貼片圖像。在構造函數中，有這樣的代碼：BitmapFactory.Options＃outWidth返回與實際位圖不同的大小

寬度：：在7" 三星Galaxy Tab 7運行Android 3.2.2

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);

輸出556 556;高度：890 890

運行Android 4.1的10英寸摩托羅拉Xoom的輸出：

width：556 556;高度：890上890

輸出7" 的Nexus 7運行Android 4.2.2：

寬度：740 834;高度; 1185 1335

位圖的實際尺寸有：

MDPI：558 X 892

ħ dpi：836 x 1337

位圖是一個預處理的9貼片，這就是爲什麼尺寸偏離2像素。我不明白爲什麼Nexus 7上的hdpi資產會使這種差異變得更大。

我已經嘗試了這些配置，以及：

bmpOptions.inScaled = false;

和

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

和

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

和

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

我也嘗試了相反的方法，併爲解碼的位圖創建了第二個BitmapFactory.Options，並告訴它根本不能縮放。

所有這些提供了相同的確切結果。

來源

2013-03-01 DeeV

前3行不影響第4行，因爲第4行不使用任何上面的變量。「bmpOptions」也不會被使用或填充。也許你在發佈這個問題時重新命名了變量？

此外，位圖圖像文件可能位於具有密度限定符的文件夾（或默認的文件夾，如mdpi）？

僅當您將該文件放入drawable-nodpi時，您將始終獲得寬度爲&高度的相同像素數。

來源

2013-03-02 10:39:17

我在這裏做的是一個測試。基本上，我解碼兩次相同的位圖。一旦只有邊界和其他直線。如果你將'inJustBounds'設置爲true，理論上（根據文檔），我應該能夠得到所產生的位圖的大小，而不用使用時間和內存來創建它。但是，如圖所示，情況並非如此。事實上兩者互不影響是重點。 – DeeV 2013-03-02 14:37:34

當我將它放入'no-dpi'文件夾時，我會看到會發生什麼，但是我發現奇怪的是'BitmapFactory'在縮放另一個時不縮放。它*應該*都做。 – DeeV 2013-03-02 14:39:04

我把圖像放在nodpi文件夾中，它工作。我發現它非常令人不安，因爲'inJustBound'的整個目的是爲了給你圖像的尺寸而不用完全解碼**。 – DeeV 2013-03-04 13:35:18

難道是事實的Nexus 7屏幕電視 DPI並加載從位圖drawable- ^h DPI？不過，這仍然很奇怪，outXXXX值與位圖的最終寬度/高度不匹配。

來源

2013-03-01 22:32:07

這應該沒關係。這顯然是以某種方式縮放位圖，但是我明確地告訴它並且位圖仍然收縮。同樣，BitmapFactory.Options應該以與真實方式相同的方式解碼位圖。 – DeeV 2013-03-02 00:53:50

您可以更改原始示例代碼段中的代碼，因爲它不會進行編譯（例如，您聲明bmpOptions但使用maskOptions ...），這樣我們可以查看確切的代碼並找出發生了什麼問題。你說得對，這種行爲看起來很奇怪，但它看起來好像與你的代碼在Nexus 7上運行時沒有drawable-tvdpi dir（而是使用drawable-hdpi）有關。 – 2013-03-02 15:50:13

我把圖像放在nodpi文件夾中，它工作。我發現它非常令人不安，因爲'inJustBound'的整個目的是爲了給你圖像的尺寸而不用完全解碼**。通過文檔（或至少暗示），將'inJustBounds'設置爲'true'應該與圖像尺寸相同。 – DeeV 2013-03-04 13:36:17

要獲得使用inJustDecodeBounds選項的實際圖像大小，則需要通過比例係數，它等於inTargetDensity /強度氣體繁衍返回outWidth和outHeight。示例代碼是：

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); 
}

來源

2013-07-09 13:30:54

BitmapFactory.Options＃outWidth返回與實際位圖不同的大小

回答

相關問題