我觉得应该去掉对FreeImage的依赖，可否考虑一下

[Charltsing]

PDF的图片基本就是DCT、CCITTFax、Flate、LZW、JPX几个编码，除了DCT直接保存jpg之外，其它的都是解码成原始图像数据。

根据原始图像数据和调色板数据，可以使用C#重建图像。Tif、png都可以直接使用C#生成，而无需第三方库。

不知道补丁丁是不是有什么特殊原因必须要Freeimage的支持。至少导出图像功能，我测试是可以摆脱FreeImage的依赖的。

因为下一版要改成64位，所以不如趁这个机会去掉FreeImage。如果需要啥代码，可以联系我（liucq@163.com）。

顺便说一下，你这个项目是我在网上看到的最有技术价值的PDF开源代码，谢谢作者。

[wmjordan]

主要是图片兼容性，有些图片（特别是TIFF图像）用.NET内置的Bitmap或者iText的Image都加载不了，造成合并图片失败，而这些图片用FreeImage就能读取

[Charltsing]

可以直接读tif，至少八位tif没啥问题。至于16位的应该也不是我们这种开源软件的责任范畴，或者挂个转换插件之类的方式会更好。
网上的例子（读CMYK，8207格式，这个格式出于某种原因，没有被Gdi支持）：

`private unsafe void CreateFromBitmap(Bitmap map)

{

int height = map.Height;      
int width = map.Width;     
const int PixelFormat32bppCMYK = 8207; 
PixelFormat format = map.PixelFormat; 
if (this.Width != width || this.Height != height)     
{      
    return;      
}     Bitmap newMap = map;     
Int32 step = SizeOfT();     switch (format)     
{      
    case PixelFormat.Format24bppRgb:      
        break;      
    case PixelFormat.Format32bppArgb:      
        break;      
    default:      
        if ((int)format == PixelFormat32bppCMYK)      
        {      
            format = PixelFormat.Format24bppRgb;      
            newMap = new Bitmap(width, height, format);      
            using (Graphics g = Graphics.FromImage(newMap))      
            {      
                g.DrawImage(map, new Point());      
            }      
        }      
        else      
        {      
            format = PixelFormat.Format32bppArgb;      
            newMap = map.Clone(new Rectangle(0, 0, width, height), PixelFormat.Format32bppArgb);      
        }      
        break;      
}     BitmapData data = newMap.LockBits(new Rectangle(0, 0, width, height), ImageLockMode.ReadOnly, format);     
Byte* line = (Byte*)data.Scan0;   
//…… 

}`

[wmjordan]

软件要面对的不是“至少”的问题，而是所有用户。
诚然，FreeImage 虽然对图片格式的支持比较丰富，但还有很多需要改进的场合。例如最近一个问题就是用 FreeImage 也无法处理的，得调用 C 写的 libtiff。由于 .NET 生态系统的原因，对于图像格式的支持目前还不算得上很成熟，得依赖其它语言开发的开源项目。

[Charltsing]

如果你决定用libtiff了，那就更不需要FreeImage了。
其实PDF涉及的图像格式也就需要tif、jbig2、jpeg2000这三个原生库，其它的基本gdi都能支持了。
在我最近的项目中，也就用到jbig2和openjpeg，tif没有用到。

去掉FreeImage会让你的代码变得更纯粹，这对开源项目的发展有好处。

[wmjordan]

如果有人可以帮做 .NET 上对 libtiff、libjpeg 等图像格式库的调用库就好了。

[Charltsing]

libtiff.net
BitMiracle/libjpeg.net
takuya-takeuchi/OpenJpegDotNet

github上面应有尽有，挨个抄呗

[wmjordan]

前两个是用.NET重新实现libtiff和libjpeg的功能，可以说是移植版。移植版的问题也是不再更新。
例如 #164 用 libtiff.net 就解决不了。我之前已经了解过这俩，否则也不会说没那么简单。
最后一个倒是挺有希望，今年还有更新。

[wmjordan]

不是这么简单的。

[Charltsing]

从商用软件卖钱角度来说，当然是功能越多越好。

但是从开源角度来说，代码技术越纯粹越好，除了底层必备的图像库(openjpeg、jbig2、tif等)，不要掺杂一些中间库。

既然已经开源了，有时间整理一下祖传代码，借着升级64位的机会，抛弃一些没必要的功能，尽可能走技术路线而不是功能路线，这样开源才会持续。毕竟开源没有啥大的收入，走功能路线慢慢就疲惫了。技术路线还有激情。

如果还想照顾老用户，可以考虑在64位版本中开放插件功能（其实老用户暂时用32位足够了）。

我看很多著名的PDF库也不是面面俱到，各种格式和功能事无巨细全都支持，应该是有一定道理的。

现在补丁丁的代码历史负担很重，是时候精简一下了。

[lelandyang]

我认为能够做一个专门用于PDFPatcher的图像库是有意义的，原因在于FreeImage这个项目已经很久没有更新了，内部的组件libtiff以及libjpeg等上游却在更新，有必要维护一个imagecodecs.dll实现对PDF的图像支持，顺便把jbig2.dll合并到里面，提高软件耦合度。
但是这个工作量不小。

[wmjordan]

同意。就是工作量不少。