你好,游客 登录 注册 搜索
阅读新闻

式2.1式2.2中参数a、d别离为x、y向比例系数

[日期:2019-11-08] 浏览次数:

  第二种的代表软件包罗Adobe Acrobat Professional(菜单项:Advanced-Export All Images)。若是喜好开源代码,也能够看看Xpdf组织供给的pdfimages。从我利用的成果看,Acrobat略显,不管本来的图像是什么格局,转换出来都成了一种格局。pdfimages稍好一点,JPG数据流 能够间接导出成JPG文件,其它无损数据流解码后导出为ppm文件,不外对于某些特殊色彩空间(ColorSpace)的JPG数据流,间接导出会导致偏色,只能解码后导出为ppm文件。 其实部门特殊色彩空间能够导出为JPG压缩的TIFF文件,从而避免对数据进行解码、再压缩,pdfimages不晓得为什么没有考虑。

  图像的偏移量,即图像左上角点距离页面左上角点的距离,这同样是一个取设备的物理分辩率无关的逻辑量,单元为1/72英寸。

  用户正在阅读时将PDF Reader设置为单页、适合宽度,如许每一页城市从动缩放到Reader的窗口宽度。若是嫌麻烦,也能够正在生成PDF时就指定“初始视图”中的“页面结构”为“单页”,“放大率”为“适合宽度”。这种方式的错误谬误是前后翻页时不如“持续”模式顺畅。

  这个该当算比力老的尺度了,因为扫描、出书界保守上就习TIFF格局,所以将多页TIFF做为电子文档的一种尺度格局,该当是顺理成章的事,国内部门省市先行制定的电子档案办理相关也曾要求用多页TIFF做为扫描电子文件的存储格局。

  看来ACSEE对它的JPG转换引擎还实不是一般地有决心!但从表1.2所列数据看,这种转换也不是没有问题:

  阅读的顺畅性问题:供给矫捷多样的页面结构供用户按需选择,包罗固定纸张大小、固定纸张宽度、按照图像大小定制页面等。页面大小的分歧不该对原始图像数据流(图像的物理暗示)形成影响,而是通过定义图像的逻辑暗示,由PDF Reader本身来完成需要的图像缩下班做。

  对于LZW和Flate压缩,PDF还支撑预告器(Predictor),预告器暗示按照图像的某些特征,先对图像进行某些预处置后再对处置成果进行压缩,以获取更高的压缩比。正在《PDF Reference 5th edition》中定义的预告器见表2.2。小于10的预告器称TIFF预告器,源自libtiff;10以上的称PNG预告器,源自libpng。因而若是PDF文件中定义图像的物理暗示时利用了Predictor属性,多半能够猜到原始图像的格局。 正在表3.1和表1.3中,为了更好地进行比力,采用PNG预告器的Flate解码器均标注为FlateDecode/PNG。

  为了验证我提出的上述问题及其处理方式,我开辟了一个免费的图像转PDF东西FreePic2Pdf,有需要的能够到我的网坐下载。该软件考虑的优先挨次顺次是:图像质量、PDF文件大小、转换速度。

  对于PNG图像,Word似乎有本人的暗示方式,存正在解码、从头压缩的过程,而且将BitsPerComponent小于4的PNG转换成BitsPerComponent等于4的图像,这点取CxImage很象。

  对于彩色BMP文件,全数从头压缩成JPG数据流,正在色彩数较多、色调过渡天然时可以或许减小文件长度,不然会添加文件长度。当然非论哪种环境画面质量城市丧失。

  缺乏需要的代码支撑,严沉障碍了该尺度的推广普及。取其它图像格局分歧,目前还没有一个开源组织供给线压缩支撑:Markus Kuhn供给的JBIG-KIT只支撑JBIG1,并曾经遏制更新;jbig2dec只供给解码代码(俺思疑PDF的JBIG2解码代码就来自这里),不供给编码代码。

  对于间接读取图像数据的转换东西,因为能够从原始图像文件中获取丰硕的图像消息,包罗原始数据压缩算法等,因而能够针对分歧的文件格局或分歧的图像环境做出选择;基于虚拟打印道理实现的转换东西,若是打印机只能获得解码后的数据流,选择的余地就会小一些:只能从bitmap数据流中获取色深等消息,然后自行选择算法从头压缩数据。

  JBIG2的道理雷同OCR:先对图像进行朋分、婚配,正在识别出子图像(如文字)后,将整幅图像看做子图像及其的调集,存储时只存储子图像和子图像呈现的,其它布景消息全数过滤掉,因而不只可以或许供给很高的压缩比,并且可以或许实现雷同文字检索的图像全文检索。

  缺乏便利的浏览东西。家喻户晓IE不支撑TIFF格局,所以网上浏览TIFF只能借帮特地开辟的控件。即便只正在当地机上浏览,也只要ACDSEE等为数不多的图像浏览软件支撑多页TIFF,浏览时想做标注、笔记很坚苦。

  前面说的图像的物理暗示是用象素点来暗示图像,可是若是间接按照象素点对图像进行显示、打印,可能会呈现问题。以用例1中的第二 幅图像为例,象素点阵为3315×2334,若是正在分辩率为96 DPI的显示器上显示,尺寸是34.5英寸×24.3英寸(1英寸=2.54厘米,现实英寸数=象素数÷DPI,如3315÷96=34.5英寸),而正在分辩率为300 DPI的打印机上打印,打出来只要11.1英寸×7.8英寸,这明显取PDF要求的“正在任何平台上均可获得不异的结果”不符。因而正在用物理暗示定义出图像的象素点阵后,正在现实需要显示图像的处所,不只要给出图像物理暗示的对象ID,还需要给出图像的逻辑暗示,包罗:

  对于低色深(BitsPerComponent 4)的PNG图像,转换成BitsPerComponent=4的索引色图像,形成轻细的文件膨缩。

  双层PDF是如许的PDF文件:PDF文件的每一页都包含两层,基层是从纸质文件扫描出来的原始图像 ,上层是用OCR软件对扫描图像进行识别后发生的文字成果,但字体结果设置成通明。如许用户正在阅读PDF文件时看到的是扫描图像,能够100%保留原始版面结果(包罗公章、签名),正在需要的时候,又能够通过 通明的文字消息支撑选择、复制、检索等功能。

  对于无损压缩的图像文件,口角图像解码后压缩为G4,其它解码后压缩成ZIP数据流嵌入PDF文件。虽然解码/压缩需要耗损一些时间,可是正在大都环境下能够减小PDF文件长度。

  能够指定生成的PDF文件的页面大小(除A4、B5等,还支撑国内常用的32开、16开、大32开)及页边距,这种指定不会更改图像的物理暗示,只影响PDF中对图像的逻辑暗示。

  因为问题的根子出正在TIFF文件上,所以我的目光很快集中到源代码中包含的tiff2pdf.c。这份代码是我见过最简练的PDF生成代码,并且因为是libtiff本人供给的,敷衍了事算是身世名门、血统纯正,对TIFF文件的支撑当然很可不雅,我就是用它填补了PDFLib不支撑JPEG/OJPEG压缩TIFF文件的问题。当然这份代码也不是一点问题没有:

  图像数据流从头压缩形成的问题:对压缩图像数据,应尽量将原始数据流嵌入PDF文件,避免从头压缩形成图像质量衰减;对无损压缩图像数据,能够按照图像特征选择合适的无损压缩算法从头压缩图像数据,以节流存储空间,也能够间接将原始图像数据嵌入PDF,以节流从头压缩所需的时间。

  DjVu的道理是先对图像进行阐发,然后按照内容分层,包罗布景层、文字层、图像层等,对分歧的层利用分歧的压缩算法和参数,以获得最好的图像质量和压缩比。

  因为上文中黑体部门的描述,及诸多公司、组织卷入取Unisys的专利胶葛,因而正在我见到的图像转PDF东西中,没有利用LZW压缩算法的,都甘愿将用LZW压缩的GIF图像解码后再压缩成Flate数据流。这种转换正在大都环境下能获得更好的压缩比,但破例老是有的(所以上文用的词是usually,而不是always),如用例1中的06.gif,LZW就比ZIP无效得多,如许的图片我还有几张,不外限于篇幅和空间,就不多此一举了。

  取JBIG2分歧,DjVu不只有djvuzone组织正在,并且有开源项目DjVuLibre做为支持,因而现正在不只有分歧平的编码、解码器,连查看DjVu文件的IE插件都发布了,将来该当大有但愿。

  以用例1为例,正在ACDSEE 8 PDF建立插件转换的PDF中,用如表2.4所示的布局定义第二页。

  从表2.5的六元组参数看,ACDSEE 8 PDF建立插件用一种很偷懒的方式构制该六元组:间接用图像的物理象素尺寸做为逻辑尺寸。因为屏幕DPI凡是为96 DPI,而PDF为72 DPI,这种偷懒形成的后果就是图像正在PDF Reader中按照“现实大小”显示时,看起来会比正在ACDSEE中按照“完整大小”显示更大一些。切确一点说,这张图片正在PDF中的“现实大小”达到了46.04英寸×32.42英寸。此中46.04=3315÷72,32.42=2334÷72。

  其它图像转PDF的软件我还试过一些,不外根基取以上几种东西雷同,都可能由于对图像数据流从头压缩而发生一些问题,不同只正在问题的多取少、严沉取不严沉:

  从表2.1看,其实对大大都常见图像格局,都能够将原数据流间接嵌入PDF文件,不需要再从头编码。当然某些数据,如JPG文件中的正文、PNG文件的文件头/文件尾,正在PDF文件中没用,能够先剔除再将残剩部门嵌入PDF文件。而对于TIFF文件,需要针对具体压缩算法,将实正图像数据抽取出来再嵌入PDF文件。

  间接利用原始数据流而不再从头编码,不只可以或许节流图像转换成PDF的时间,并且对于压缩,能够避免由于频频压缩而形成图像质量的衰减。可是对于GIF格局的LZW压缩来说,环境有点复杂:因为Unisys公司声称对LZW算法具有专利权,导致良多软件,包罗赫赫有名的xpdf正在内,放弃 对LZW的支撑,改用开源的Flate压缩算法。Flate其实是Winzip等软件利用的ZIP压缩算法的别的一个名字。《PDF Reference 5th edition》中对这两种算法的描述如下(黑体结果是我本人加的):

  对于压缩的JPG文件,转换成PDF后的质量取发出打印号令的软件亲近相关。如象ACDSEE如许先解码再打印,必然会由于图像的再压缩而形成质量衰减或文件膨缩。而象Word如许间接将JPG数据流发送到虚拟打印机,则取软件内部的打印设置相关,设置好了能够间接将数据流完整嵌入PDF而不形成丧失或膨缩,设置欠好则同样可能形成丧失。别的打印机对JPG数据流的支撑受平台,我猜这就是为什么包罗ACDSEE正在内的大大都软件甘愿先解码后打印的缘由:解码成bitmap再打印能够不受平台。

  注1. 图像01.tif经ACDSEE转成PDF后,图像物理暗示的高度变成2206,缘由后面会加以注释。

  从转换成果的对比来看,Word和ACDSEE的打印成果正在TIFF、JPG、PNG方面存正在较大差距:

  这种格局特地针对以文字为从、口角扫描的图像文件,属无损压缩,据称比G4压缩算法的压缩率高良多,目前已成为ISO尺度,PDF从1.4版(Acrobat 5.0)起头答应内嵌JBIG2图像,将来的TIFF尺度也筹算接收JBIG2压缩算法。

  对于喜好较实的人来说,ACDSEE的这种偷懒形成了更深条理的失线中的第二幅图像是一张扫描构成的TIFF图像,正在TIFF文件布局中记录了扫描时扫描仪利用的DPI值200 DPI。正在ACDSEE 8中打开此图像文件,点击“文件-属性”菜单,正在显示出来的文件属性中即可看到扫描DPI,及按照扫描DPI换算,这张图片对应原始纸质页面的大小16.57英寸×11.67英寸。这个尺寸取46.04英寸×32.42英寸比拟,实正在是差得太远了一点。

  ACSEE的转换插件结果很令我失望,为了比力其它嵌入式东西的转换结果,我又用用例1测试了verypdf的Image2Pdf v1.7,转换成果见表1.3。

  第一种的代表软件包罗verypdf公司的PDF2HTML等。PDF2HTML除了将页面转成图像,还能生成包含图像和翻页按钮的HTML页面,便利正在没有安拆PDF Reader的机械上浏览原PDF文件的内容。不外正在这种“眉毛胡子一把抓”的转换成果里要取出某幅图像的内容,大要只能用Photoshop慢慢抠了。

  以用例1为例,正在ACDSEE 8 PDF建立插件转换的PDF中,用如表2.3所示的XObject定义第二 幅图像(数据来自PdfView,左侧双斜杠后面是我本人加的正文):

  从《计较机图形学》学问可知,式2.1式2.2中参数a、d别离为x、y向比例系数,实现从物理尺寸到逻辑尺寸的映照;c、b为扭转系数,暗示图像显示时的扭转角度;e、f为平移系数,暗示图像到页面左上角的偏移量。

  对08、09两个PNG文件,Word打印后成了4位索引色图像(BitsPerComponent=4,Indexed),压缩算法仍然为ZIP。10~12三个PNG文件转换成果取ACDSEE类似。

  处理阅读的顺畅性问题的:制做东西供给矫捷多样的页面结构供用户按需选择,包罗固定纸张大小、固定纸张宽度、按图像大小调整纸张大小等。页面大小的分歧不该对原始图像数据流(图像的物理暗示)形成影响,而是通过定义图像的逻辑暗示,由PDF Reader本身来完成需要的图像缩放。

  好正在这份代码比力简单,布局中规中矩,改起来不是太难。最终我以它为根本实现了新邦畿像转PDF内核,并连系赫赫有名的CxImage,将对图像格局的支撑从TIFF扩展到了JPG、PNG、BMP和GIF,成为公开辟行的免费软件FreePic2Pdf,可以或许实现:

  以IT界的目光来看,电子文档成长到现正在汗青也不算短了,并且因为庞大市场前景的,各厂家也都纷纷推出了本人的格局。纯真从以支撑扫描图像为从的电子文档来说,格局虽多,可是可以或许成天气、构成尺度的,除了PDF格局外,还有多页TIFF、JBIG2、DjVu等。这些格局的配合点是:

  具体到PDF文件格局上,正在一个页面上显示一幅图像,除了前面说过的图像的物理暗示对象外,还需要定义页面(Page)对象,然后正在Page对象中:

  一幅图像正在PDF文件中凡是用一个XObject对象暗示(某些TIFF图像可能要用多个对象暗示),这个对象描述图像的原始象素点阵消息,由于这些点阵消息由发生图像的设备本身的物质(如扫描仪的DPI、 数码相机的无效象素数等)决定,因而正在这里称为图像的物理暗示,正在《PDF Reference 5th edition》中又称为采样暗示(Sample Representation)。

  为了确认能否所有软件正在利用虚拟打印机转换PDF时,均会对JPG图像进行再压缩,我进行了第二个试验:正在Word 2003中插入用例1中的13张图像(Word 2003不支撑03.tif),每张图像前面再插入一点文字(图像编号),然后打印到Acrobat PDF虚拟打印。限于篇幅,这里不列举具体成果(用例1是公开的,Word 2003、Acrobat也不难找,想要较实的人能够本人脱手试一下),仅申明成果:

  Panda的功能、接口都很是简练了然,生成的PDF文件也没几多费话,所以我花时间细致试了一下。成果发觉一个小小的小错误谬误:它的内存缝隙实正在是太多 了点,补都补不外来,最初只好放弃。

  以libtiff源代码为根本,针对这些图像不规范的处所,逐渐批改libtiff代码。这就是为什么前段时间我本人写的ComicEnhancer Pro一曲正在升级的缘由。我以至思疑,可能就是由于TIFF格局支撑起来太麻烦,所以IE才不支撑。

  对于本来就是JPG压缩格局的图像,用ACSEE转换后也会呈现文件膨缩的问题,莫非是ACSEE转换插件用的JPG质量系数比力高?

  比拟之下,PDFlib可谓内容丰硕、功能强大,某些高级功能(web优化、权限节制等)虽然要付费才能看到,但就算是免费开源出来的PDFLib Lite,对于各类图像格局的支撑也脚够一般性利用了,并且根基上没什么较着的内存缝隙。因而我正在DACapturer中试用了一把。可是正在利用一段时间后就发觉一些问题:

  从表1.1能够看出,对于ACDSEE发送过来的数据流,Acrobat PDF虚拟打印机进行如下处置:

  正在PDF文件中,图像点阵消息以压缩数据流的形式存正在,PDF通过过滤器(filter)对数据流解码。正在《PDF Reference 5th edition》中,共引见了十种过滤器,此中取图像相关的如表2.1所示。

  对压缩的jpg文件及采用JPEG/OJPEG算法压缩的TIFF文件,能间接将原始JPEG数据流嵌入PDF文件,避免由于从头采样而形成图像质量下降。

  比力原始图像数据和PDF中的图像数据,成果见表1.1表1.1中各类“解码器”的注释见本文后续的“PDF支撑的图像格局”部门,“PDF中的图像数据”各栏中的数据来自开源的PdfView。若是您有乐趣查看PDF文件内部细节,用UltraEdit-32,仅看PDF文件布局 用PdfView脚矣。

  PDF中的每个对象均有一个ID(编号),吉祥彩通过对象ID,能够对对象本身进行援用。如一个LOGO图像可能做为布景呈现正在每一个页面上,正在每一页中没有需要都包含这个LOGO图像的现实数据,只需援用这个LOGO图像的ID即可。如许无疑能够提高PDF文件的存储效率。上例中图像的对象ID就是9。

  总之,对于象我如许有特殊要求的人来说,正在目前的环境下要想获得对劲的成果,仍是只能贯彻“人要靠本人”的准绳。当然也没有需要从头发现轮子,正在我看来最抱负的环境就是可以或许正在现有开源项目根本上,通过需要的点窜和弥补,就能达到我的要求。可是google的成果令我稍微有点惊讶:虽然目前最权势巨子的图像codec开源项目都是基于C的,包罗JPEG LIBlibpnglibtiff等,可是恰恰正在PDF生成范畴,JAVA似乎比C多,包罗iText等一多量开源项目,而C只要PDFlibClibPDFPanda等无数的几个。

  取通俗PDF文件比拟,双层PDF可以或许同时兼顾视觉结果和利用便利性,因而正在国内办公、档案范畴正正在惹起注沉,我小我相信会有夸姣的“钱途”。

  其实这些文件还算好,终究是libtiff组织供给的,至多它本人的源代码还能解出来。但正在我接触到的国内专业扫描外包公司中,大大都公司供给的TIFF文件只需采用了压缩,多半就连libtiff也解不开,ACDSEE更是想都不消想。有些以至连特地显示TIFF文件的Microsoft Office Document Imaging(微软Office 2003所带附件之一)都解不开。

  宣传和市场工做做得不敷。PDF正在成为ISO尺度前有Adobe公司正在花大气力鞭策,现正在更有N家公司卷了进来,市场的大饼越做越大,比拟之下其它格局就显到手艺不足,市场不脚。

  Contents属性凡是定义一个六元组,暗示为[a, b, c, d, e, f],则从图像物理坐标(x, y)映照为逻辑坐标(x, y)的映照关系能够暗示为如下矩阵运算:

  格局不规范,这个生怕是最为致命的问题。从我接触的环境看,因为汗青的、手艺的和其它的缘由,目前国内浩繁扫描外包揽事公司供给的扫描TIFF文件, 口角图像用G4压缩不会有什么问题,可是灰度、彩色图像正在压缩时多半都用OJPEG压缩,并且格局多取规范不符,这就形成扫描出来的图像只能用该公司供给的图像浏览软件才能浏览,极大地了TIFF文件的。俺正在现实工做中为了处置客户遍及全国的分支机构委托本地外包商扫描的档案文件,取这些非尺度TIFF文件进行了持久的、艰辛卓绝的斗争(看看俺的ComicEnhancer Pro比来的更新记实就晓得了), 相信有资历说这句话。我相信正在《中华人平易近国行业尺度DA/T312005 纸质档案数字化手艺规范》中灰度和彩色图像用JPG存储,也就是为了避免发生这些不规范的压缩TIFF文件。

  明显,双层PDF的内容检索、内容复制取OCR识别成果有间接的关系。先不说目前国内OCR软件的识别率若何,最环节的一点是目前没有任何一个中文OCR引擎是免费、开源的(英文的则有gocr等一批),所以双层PDF生成东西也都不是免费的,而是“面向企业市场”,我相信穷困的小我用户正在不违法的环境下很难消受得起。

  将16位色深简化成8位色深。这个正在凡是24位/32位显示器上看不出问题,由于这些显示器最多只支撑8位色深,可是未来高端显示成本降低后可能就会被人看出差别了。PDF文件也是从PDF 1.5版(Acrobat 6.0)起头才支撑16位色深。

  若是不指定页面的纸张大小,能够指定页面的固定宽度(长度随图像大小伸缩),持续阅读时不会由于页面宽度变来变去而影响阅读。

  因为各种缘由,目前图像转PDF东西容易呈现图像数据流从头压缩形成的问题阅读的顺畅性问题对特殊图像格局的支撑问题等。

  对04、05两个JPG图像,Word将原始文件完整地嵌入了PDF文件,但正在结尾添加了一个\r(0AH)字符。明显,Word并没有对原始JPG文件进行解码、再压缩。

  PDFLib生成的PDF文件中废话太多,导致文件膨缩。DACapturer对此不是很正在乎,可是正在需要处置的文件数以万、十万做单元的营业系统中就需要考虑了。

  正在生成PDF文件时为页面指定一个固定宽度,页面的长度按照原始图像的长宽比从动伸缩。这种方式能正在以“持续”模式阅读时页面不会跳来跳去,当然打印出来仍是会正在纸张的上下或摆布发生空白。

  ClibPDF从参考手册上看,正在画图等功能方面很有特色,可是对于图像文件的支撑较差,并且要付费,所以我粗看了一下,没有深究。

  对于无损压缩的图像文件,如GIF、PNG、BMP等,实彩图像往往会被转换成压缩的JPG数据流,形成图像质量丧失;灰度、索引色图像往往会被解码后再压缩成某种无损压缩数据流,若是虚拟打印机所选压缩算法的压缩效低于原图像压缩算法,则可能形成PDF文件的膨缩。

  这张图片正在宽度标的目的上的扫描DPI约为长度标的目的的两倍(204/98),若是对这种差别处置欠好,会带来不测的成果。以ACDSEE为例,5.0.1版显示该图片时就会变形,页面顶部的圆变成了扁椭圆,到8.0版时显示出了正圆,可是图像的长度从1103变成了2206,并且正在ACDSEE 8打印和用PDF建立插件转换成PDF后,正在PDF文件的图像物理暗示中,这张图片的长度均描述为2206象素。明显,ACDSEE内部对图像数据流进行了更改(沿长度标的目的放大一倍),以合适原长宽比,这对于图像显示软件来说无可厚非,可是对于PDF转换软件来说就有点多余,会添加最终PDF的文件长度。Image2Pdf没有对这张图片的物理暗示进行更改,而是试图通过调整图片的逻辑暗示,由PDF Reader正在显示时进行长宽比调整。但倒霉的是,Image2Pdf v1.7似乎把比例算反了,成果导致最终PDF显示出来后,圆变成了长椭圆。FreePic2Pdf吸收了这些教训,可以或许通过对图像逻辑暗示的准确设置,正在不改变物理暗示的环境下, 以准确的长宽比例显示该图像。

  对于口角图像,CCITT G4的压缩比凡是比灰度JPG高很多,终究它是专为压缩口角图像而研发的压缩算法。因而将CCITT G3/G4转换成灰度JPG无疑将会形成文件膨缩,并且膨缩得很较着。这点对电子文档来说比力主要:大大都的纸质文档扫描后都是口角图像。

  对于TIFF图像,Word对图像进行了切割,这个估量取Word对图像的显示体例相关;别的Word没有改变图像的物理暗示, 这取下面要谈的“间接将图像嵌入PDF文件”的转换软件雷同。

  这里说的“特殊图像格局”,其实次要就是TIFF格局。正在常见的图像格局中,JPG、GIF、PNG、BMP等都有严酷的格局,能够阐扬的余地不多。可是对于TIFF来说,因为尺度本身但愿可以或许包涵尽可能多的工具,可是对实现细节没有给出具体的,所以各家软件生成的TIFF文件八门五花,令人头疼。

  对于低色深(如16级灰度)图像来说,转换成灰度JPG(256级灰度)同样可能形成文件膨缩。

  综上所述,目前图像转PDF东西遍及存正在一些共性的问题,包罗图像数据流从头压缩形成的问题生成的PDF文件的阅读顺畅性问题对特殊图像格局的支撑问题等。为了更好地舆解这些问题,并找四处理法子,下面先简单引见一下PDF中取图像相关的根基概念。

  而若是用verypdf的Image2Pdf v1.7对统一张图片进行转换,能够看出转换后的PDF页面大小为16.57英寸×11.67英寸,即正在PDF Reader当选择按照“现实大小”进行显示,显示出来的图像大小,正好取原始纸质文件的大小一模一样。明显如许的成果更合适文档电子化的要乞降习惯。

  改变文件数据流的压缩方式,正在某些环境下能够减小文件长度,正在某些环境下则会形成文件长度膨缩。环节是看数据取压缩方式的搭配能否合适。

  PDFLib对JPG、PNG的支撑很好,可是对TIFF的支撑能够用“”来描述:不支撑JPEG/OJPEG压缩的TIFF还能够填补(俺正在DACapturer中通过正在PDFLib Lite之外打补丁的办决),可是将TIFF中的每个strip当做一个对象来处置,就有点过度了,以至发生过如许的事:用PDFLib转换十几页TIFF成为PDF,竟然正在PDF中建立了几千个obj,后来用iText对如许的PDF文件进行归并操做, 以至活活把iText拖垮了。所以用了没多久,俺就下定决心必然要和PDFLib说再见。

  压缩率严沉依赖于图像本身的内容和压缩引擎的模板表。对于字母文字来说,字母总数终究无限,因而沉码率很高,天然压缩比也很高,可是对于中文来说,可能就没这么抱负了。不外从我试用的环境看,至多不会比CCITT G4的压缩比差。

  除TIFF外,PNG文件也是一种可能会形成潜正在麻烦的格局。可是取TIFF分歧,PNG的麻烦不正在于文件格局本身或数据压缩算法,而正在于它丰硕的色彩暗示:PNG支撑灰度、索引、彩色、Alpha通道彩色图像,而且色深除低端的1、2、4、8位外,还支撑16位色深。有乐趣又喜好较实的人,能够到libpng下载一份libpng源代码,里面的contrib\pngsuite文件夹下就包含了一堆图片,特地用于测试软件对PNG色彩支撑的能力。

  灰度、索引色(调色板)图像压缩为Flate(ZIP)数据流,色深(BitsPerComponent)不变。

  处理图像数据流从头压缩形成的问题的:对压缩的图像数据,应尽量将原始数据流嵌入PDF文件,避免从头压缩形成图像质量衰减;对无损压缩图像数据,能够按照图像特征选择合适的无损压缩算法从头压缩图像数据,以节流存储空间 ,也能够间接将原始图像数据嵌入PDF,以节流从头压缩所需的时间。

  响应的支撑东西和软件不脚。PDF虚拟打印机用起来多便利,其它格局的虚拟打印机则少得多。就算是用公用东西辛辛苦苦做出来,想和其它人分享的时候,还得问问他的机械上有没有拆响应的浏览软件,不免太麻烦。当然浏览的问题和前一个问题相关,几年前也不是所无机器上都拆PDF Reader的。

  图像的逻辑尺寸。这个尺寸的单元是1/72英寸,因而是一个逻辑概念,即非论正在什么样的设备上输出图像,图像的大小都是固定的英寸值,而不会跟着输出设备的DPI值而变化。

  对01、02两个TIFF文件,Word转换成CCITT G4压缩,并且01.tif物理暗示的高度未变,这 比ACDSEE强。可是这两个图像均被分化成了多个对象(01.tif分成2个,02.tif分成8个),相当于将原始图像切割成多个程度横条,每个对象代表一条。

  对于PNG文件,数据流压缩算法不变(PNG压缩算法正在PDF中对应/DecodeParms[/Predictor 15]),但数据流长度会稍小一些,估量是去掉了PNG文件中的无关消息。

  不要正在TIFF文件中利用压缩,特别不要用各品牌专业高速扫描仪所带扫描软件生成压缩TIFF文件。因为汗青缘由,这些软件遵照的多半是陈旧的TIFF尺度,生成的文件大要只要它们本人的阅读软件能打开。若是有需要对图像进行压缩,间接存储为尺度JPG格局即可,这个很难玩什么花腔。

  非索引色(如15位色、24位色)图像压缩为DCT(JPG)或Flate数据流。似乎Acrobat PDF虚拟打印机能从动识别压缩为哪种数据流更有益,但压缩成JPG数据流时似乎质量系数很低:文件更小,质量更差。

  可是对于TIFF格局的生命力,我小我从未暗示思疑:取某些静态图像格局分歧,TIFF尺度一曲正在取时俱进,不竭将先辈的图像压缩手艺接收进来,目前曾经支撑支流的CCITT、JPEG、LZW、ZIP等手艺,新版本的草案中则打算包含对JPEG 2000、JBIG2等先辈算法的支撑。这些都让我充满等候。

  对于JPG文件,底子就没有解压、再压缩的过程,间接将原始JPG文件一个字节不改就嵌入PDF文件,从而避免由于再次压缩而形成质量衰减,并且解压、再压缩的时间也省了。

  非论本来的图像格局是什么,颠末ACSEE的转换插件转换后全数解码再从头压缩成的JPG数据流,无疑会对图像质量形成毁伤。

  注2. 对于索引色(Indexed)图像,“数据流长度”仅包含图像数据流长度,不包含索引(调色板)数据流长度。严酷说来这会形成一些误差,但影响不大。以下各表取此不异,不再特殊申明。

  对比表3.1和表1.3,能够看出FreePic2Pdf优先考虑图像质量,其次考虑压缩比、生成速度。

  可是从现实环境看,实正用多页TIFF存储的电子文档并不多,正在2005年公布施行的《中华人平易近国行业尺度DA/T312005 纸质档案数字化手艺规范》中,干脆就没多页TIFF什么事:

  对libtiff源代码进行了更改,以尽可能支撑各类特殊格局的TIFF文件;间接挪用libpng对PNG图像进行处置,以支撑特殊色深的PNG文件。

  对于GIF文件,解压后压缩为RLE(行程编码)。因为RLE的压缩率远不如GIF本身的LZW算法,因而这种再压缩会形成文件膨缩。估量这种费劲不奉迎的做法取传说中LZW压缩算法的版权相关。

  以我供给的测试用例2为例,这个其实是支撑TIFF文件最权势巨子的开源项目libtiff3.7.1版所带测试图片,不外去掉了一张caspian.tif(该图片共3通道,单通道采样位数高达64位浮点数,我的32位实彩显示器单通道采样位数只要8位整数,显示不了这么高级的图片)。但仅凭剩下的这些图片,曾经能够难倒包罗verypdf的Image2Pdf正在内的一多量图像转PDF软件,就算是ACDSEE如许“专业”的图像浏览器,5.0.1版正在看这些图像时也会呈现比例失调(x2d.tif、g3test.tif)、看不了(quad-tile.tif)、颜色失实(smallliz.tif、zackthecat.tif)等问题;8.0版虽然批改了上述问题,但又呈现新的问题:看dscf0013.tif时颜色失实。

  811采用口角二值模式扫描的图像文件,一般采用TIFF(G4)格局存储。采用灰度模式和彩色模式扫描的文件,一般采用JPEG格局存储。存储时的压缩率的选择,应以扫描的图像清晰可读的前提下,尽量减小存储容量为原则。

  事先声明:本部门所有内容均来自Adobe公司发布的《PDF Reference 5th edition》, 说白了就是我看这份文档时做的笔记的一部门,所以看起来可能有点无头无尾,列位看得懂就看,看不懂就去看《PDF Reference 5th edition》原文吧。