Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=79246 --- shadow/79246 2006-09-01 10:55:20.000000000 -0400 +++ shadow/79246.tmp.5043 2006-09-05 01:45:55.000000000 -0400 @@ -2,16 +2,16 @@ Product: Mono: Class Libraries Version: 1.1 OS: All OS Details: Status: NEW Resolution: -Severity: +Severity: Unknown Priority: Normal Component: libgdiplus -AssignedTo: [EMAIL PROTECTED] +AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] TargetMilestone: --- URL: Cc: Summary: Bitmap.LockBits doesn't behave like MS @@ -30,6 +30,48 @@ How often does this happen? *always Additional Information: * this happens for every codec (see unit tests) + +------- Additional Comments From [EMAIL PROTECTED] 2006-09-05 01:45 ------- +I took a look at the test cases for the BMP codec, and noted the +following things: + +1. The "almogaver1bit.bmp" file is actually a 4-bit BMP file. This is +most evident when opening the file in a viewer: It actually has +colours! The test for this seems to express confusion over why a 1- +bit BMP file would result in a 4-bit PixelFormat. Well, the reason is +that it's not a 1-bit BMP file! :-) + +2. The Bitmap24bitData() test is inherently broken because it assumes +that all implementations of a BMP codec will return the same in- +memory stride. This is clearly not the case; the only rule, apart +from that it be wide enough for all the bits in each row, is that the +stride be a multiple of 4 bytes. The test jumps forward randomly by +1009 bytes and ends up with a different (x, y) coordinate depending +on the stride of the bitmap data, which differs between MS +GDIPLUS.DLL and libgdiplus. + +3. The Bitmap32bitData() test seems to have uncovered a possible bug +in Microsoft's BMP loader, or else a misinterpretation in our +bmpcodec.c of the 32-bit data. Unless the alpha is inverted, so that +its interpretation is as how transparent the pixel should be rather +than how opaque it should be, every pixel in that bitmap should be +completely transparent. Look at the file in a hex editor and it's +quite plain: the 4th byte of every quad is 00h, not FFh. + +So, to summarize, the fact that Bitmap.GetPixel() within than test +returns pixels with an alpha of FFh means one of three things: a) MS +GDIPLUS.DLL has a bug in it, b) BMP files store tranparency values +instead of opacity values, or c) MS GDIPLUS.DLL simply calls into the +underlying GDI32 code for loading bitmaps, which has no support +whatsoever for translucency. + +Unless b) is the case, I put forth that we should continue to "do the +right thing" here, because I doubt anybody will actually want alpha +forced to 255 in BMP files (and if they do and they complain about +it, we can change it then). + +I have yet to look at the other System.Drawing.Imaging test cases +marked [NotWorking]. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
