我把大家对于ImageList的问题归纳了一下，主要都是关于：
1.ImageList里面的图片的颜色
2.ImageList里面的图片的大小
/********* １）ImageList里面的图片的颜色的问题 ********/
引起ImageList里面图片颜色失真的原因是在Design-Time就在VS.NET中往ImageList里面添加了Images。
当用户一边在“Image Collection Editor”对话框里面添加图片，VS.NET一边就已经把这些图片装载到resource文件里面了。这样，以后程序运行时就只需要访问resource文件就可以载入所有图片而不需要依赖原始的图片文件。
但是问题在于从结果看，当VS.NET在Design-Time往resource文件里面添加图片时并没有使用用户指定的ColorDepth（例如Depth32Bit），而用了ImageList.ColorDepth的默认值(Depth8Bit)。这样，等程序运行时，即使ImageList.ColorDepth指定了Depth32Bit也无济于事，因为原始的素材本身只有8bit的颜色。这基本上就是waki的问题的原因。
因此，解决方案是：不在Design-Time用VS.NET往ImageList里面添加图片，而是在程序运行时先指定32Bit的ColorDepth，然后再添加图片，如以下例子代码：
this.imageList1.ColorDepth=ColorDepth.Depth32Bit;
this.imageList1.Images.Add(Image.FromFile(@"C:\Inetpub\wwwroot\winxp.gif"));
this.imageList1.Images.Add(Image.FromFile(@"C:\Inetpub\wwwroot\images\init_dotnet.gif"));
this.imageList1.Images.Add(Image.FromFile(@"C:\Inetpub\wwwroot\images\mslogo.gif"));
this.imageList1.Images.Add(Image.FromFile(@"C:\Inetpub\wwwroot\images\mslogo2.gif"));
这里需要注意的是，必须先指定ColorDepth，然后再添加图片。因为对ColorDepth赋值会清空所有图片。BTW，ImageList.ColorDepth的默认值是Depth8Bit，而非文档上所述Depth4Bit。这一点很容易可以通过写一段例子代码来验证，也可以通过很多Decompiler来查看ImageList的构造函数的实现来验证。
/********** ２）ImageList里面的图片的大小 ************/
的确，通过ImageList.Images[i]获得图片的大小都是统一的，都等于ImageList.ImageSize。这个问题的原因在于ImageList在返回Images[i]的过程中并没有返回原始的图片，而是按照ImageList.ImageSize创建了一个新的Bitmap，并把原始图片的内容重新绘制上去以后再返回给用户。关于这一点，可以用一些Decompiler工具如ILDASM.exe或者Anakrino通过察看私有函数ImageList.GetBitmap(int index)来验证。我想现在paulluo0739应该能够理解为什么ImageList里面的图片都是一样大的了。
ImageSize同ColorDepth类似，也不宜在运行时改动，一旦重新赋值，就会清空所有的图片。因此，如果程序运行时需要某一图片的不同大小的版本，可以考虑使用多个不同ImageSize的ImageList。
1.ImageList里面的图片的颜色
2.ImageList里面的图片的大小
/********* １）ImageList里面的图片的颜色的问题 ********/
引起ImageList里面图片颜色失真的原因是在Design-Time就在VS.NET中往ImageList里面添加了Images。
当用户一边在“Image Collection Editor”对话框里面添加图片，VS.NET一边就已经把这些图片装载到resource文件里面了。这样，以后程序运行时就只需要访问resource文件就可以载入所有图片而不需要依赖原始的图片文件。
但是问题在于从结果看，当VS.NET在Design-Time往resource文件里面添加图片时并没有使用用户指定的ColorDepth（例如Depth32Bit），而用了ImageList.ColorDepth的默认值(Depth8Bit)。这样，等程序运行时，即使ImageList.ColorDepth指定了Depth32Bit也无济于事，因为原始的素材本身只有8bit的颜色。这基本上就是waki的问题的原因。
因此，解决方案是：不在Design-Time用VS.NET往ImageList里面添加图片，而是在程序运行时先指定32Bit的ColorDepth，然后再添加图片，如以下例子代码：
this.imageList1.ColorDepth=ColorDepth.Depth32Bit;
this.imageList1.Images.Add(Image.FromFile(@"C:\Inetpub\wwwroot\winxp.gif"));
this.imageList1.Images.Add(Image.FromFile(@"C:\Inetpub\wwwroot\images\init_dotnet.gif"));
this.imageList1.Images.Add(Image.FromFile(@"C:\Inetpub\wwwroot\images\mslogo.gif"));
this.imageList1.Images.Add(Image.FromFile(@"C:\Inetpub\wwwroot\images\mslogo2.gif"));
这里需要注意的是，必须先指定ColorDepth，然后再添加图片。因为对ColorDepth赋值会清空所有图片。BTW，ImageList.ColorDepth的默认值是Depth8Bit，而非文档上所述Depth4Bit。这一点很容易可以通过写一段例子代码来验证，也可以通过很多Decompiler来查看ImageList的构造函数的实现来验证。
/********** ２）ImageList里面的图片的大小 ************/
的确，通过ImageList.Images[i]获得图片的大小都是统一的，都等于ImageList.ImageSize。这个问题的原因在于ImageList在返回Images[i]的过程中并没有返回原始的图片，而是按照ImageList.ImageSize创建了一个新的Bitmap，并把原始图片的内容重新绘制上去以后再返回给用户。关于这一点，可以用一些Decompiler工具如ILDASM.exe或者Anakrino通过察看私有函数ImageList.GetBitmap(int index)来验证。我想现在paulluo0739应该能够理解为什么ImageList里面的图片都是一样大的了。
ImageSize同ColorDepth类似，也不宜在运行时改动，一旦重新赋值，就会清空所有的图片。因此，如果程序运行时需要某一图片的不同大小的版本，可以考虑使用多个不同ImageSize的ImageList。
