Tại sao BitmapSource.Create lại ném một ArgumentException?

Question

Tôi đang cố gắng để có được một bitmap được tạo ra từ dữ liệu thô để hiển thị trong WPF, bằng cách sử dụng một hình ảnh và một BitmapSource:

Int32[] data = new Int32[RenderHeight * RenderWidth]; 

for (Int32 i = 0; i < RenderHeight; i++) 
{ 
    for (Int32 j = 0; j < RenderWidth; j++) 
    { 
     Int32 index = j + (i * RenderHeight); 

     if (i + j % 2 == 0) 
      data[index] = 0xFF0000; 
     else 
      data[index] = 0x00FF00; 
    } 
} 

BitmapSource source = BitmapSource.Create(RenderWidth, RenderHeight, 96.0, 96.0, PixelFormats.Bgr32, null, data, 0); 

RenderImage.Source = source; 

Tuy nhiên các cuộc gọi đến BitmapSource.Create ném một ArgumentException, nói rằng "Giá trị không nằm trong phạm vi dự kiến ​​". Đây không phải là cách để làm điều này? Tôi không thực hiện cuộc gọi đó đúng cách?

Answer 1

Sải chân của bạn không chính xác. Stride là số byte được phân bổ cho một quét của bitmap . Vì vậy, sử dụng như sau:

int stride = ((RenderWidth * 32 + 31) & ~31)/8; 

và thay thế các tham số cuối cùng (hiện 0) với stride như đã định nghĩa ở trên.

Dưới đây là một lời giải thích cho công thức sải chân bí ẩn:

Thực tế: scanlines phải được xếp trên ranh giới 32-bit (reference).

Công thức ngây thơ cho số byte cho mỗi scanline sẽ là:

(width * bpp)/8 

Nhưng điều này có thể không cung cấp cho chúng ta một bitmap xếp trên một ranh giới 32-bit và (chiều rộng * bpp) có thể thậm chí không có được chia hết cho 8.

Vì vậy, những gì chúng tôi làm là chúng tôi buộc bitmap của chúng tôi để có ít nhất 32 bit liên tiếp (chúng ta giả định rằng width > 0):

width * bpp + 31 

và sau đó chúng tôi nói rằng chúng tôi không quan tâm đến các bit có thứ tự thấp (bit 0--4) vì chúng tôi đang cố gắng căn chỉnh trên các ranh giới 32 bit:

(width * bpp + 31) & ~31 

và sau đó chia cho 8 để trở lại byte:

((width * bpp + 31) & ~31)/8 

Các đệm có thể được tính bằng cách

int padding = stride - (((width * bpp) + 7)/8) 

Công thức ngây thơ sẽ là

stride - ((width * bpp)/8) 

Nhưng width * bpp có thể không căn chỉnh trên một ranh giới byte và khi nó không công thức này sẽ hơn đếm padding bởi một byte. (Hãy suy nghĩ về một bitmap rộng 1 pixel sử dụng 1 bpp. Các bước tiến là 4 và công thức ngây thơ sẽ nói rằng padding là 4 nhưng trong thực tế nó là 3.) Vì vậy, chúng tôi thêm một chút để trang trải các trường hợp mà width * bpp không phải là một ranh giới byte và sau đó chúng tôi nhận được công thức chính xác được đưa ra ở trên.