Please describe the problem:
The winicon plugin has 

Steps to reproduce:
1. Open an image with odd width (in my case 119) which contains transparent and
opaque pixels together on the same lines.
2. Save it as a .ico file (any bpp).
3. View the result in another image viewer (e.g. Windows image preview)

Actual results:
The transparency is slightly locally scrambled.

Expected results:
The transparency should be as in the original image.

Does this happen every time?
yes.

Other information:
Note that you won't notice a problem when you view the scrambled file in GIMP;
the bug is the same in the load and save operations and cancels out.

The problem is due to incorrect calculations in the functions that get and set
bits and nibbles in the winicon plugin. Here are context diffs for the source
files icoload.c and icosave.c that should fix the problem. (I didn't build the
entire program so I'm not 100% sure.)

=============================================
*** icoload.c	Fri Nov 26 18:37:26 2004
--- icoload_fixed.c	Fri Feb 10 17:53:00 2006
***************
*** 279,285 ****
    line = bit / line_width;
    offset = bit % line_width;
  
!   result = (data[line * width32 * 4 + offset/8] & (1 << (7 - (bit % 8))));
  
    return (result ? 1 : 0);
  }
--- 279,285 ----
    line = bit / line_width;
    offset = bit % line_width;
  
!   result = (data[line * width32 * 4 + offset/8] & (1 << (7 - (offset % 8))));
  
    return (result ? 1 : 0);
  }
***************
*** 300,308 ****
    line = nibble / line_width;
    offset = nibble % line_width;
  
!   result = (data[line * width32 * 4 + offset/2] & (0x0F << (4 * (1 - nibble %
2))));
  
!   if (nibble % 2 == 0)
      result = result >> 4;
  
    return result;
--- 300,308 ----
    line = nibble / line_width;
    offset = nibble % line_width;
  
!   result = (data[line * width32 * 4 + offset/2] & (0x0F << (4 * (1 - offset %
2))));
  
!   if (offset % 2 == 0)
      result = result >> 4;
  
    return result;
=============================================
*** icosave.c	Sat Apr  9 21:46:24 2005
--- icosave_fixed.c	Fri Feb 10 17:55:19 2006
***************
*** 295,301 ****
    offset = bit_num % line_width;
    bit_val = bit_val & 0x00000001;
  
!   data[line * width32 * 4 + offset/8] |= (bit_val << (7 - (bit_num % 8)));
  }
  
  
--- 295,301 ----
    offset = bit_num % line_width;
    bit_val = bit_val & 0x00000001;
  
!   data[line * width32 * 4 + offset/8] |= (bit_val << (7 - (offset % 8)));
  }
  
  
***************
*** 316,322 ****
    offset = nibble_num % line_width;
    nibble_val = nibble_val & 0x0000000F;
  
!   data[line * width8 * 4 + offset/2] |= (nibble_val << (4 * (1 - (nibble_num %
2))));
  }
  
  
--- 316,322 ----
    offset = nibble_num % line_width;
    nibble_val = nibble_val & 0x0000000F;
  
!   data[line * width8 * 4 + offset/2] |= (nibble_val << (4 * (1 - (offset % 2))));
  }
  
  
=============================================

As far as I can tell, this has nothing to do with Bug 172503. I verified that
when I make the above modifications, icoload.c generates the correct ARGB color
values, but even without the fix they are only locally scrambled, due to the
wrong bit shifts, and this cannot account for the more serious problems
described in Bug 172503.