User Tools

Site Tools


pdf:images

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
pdf:images [2016/02/22 10:49] – [Implementation] christianpdf:images [2016/03/02 15:19] (current) – [Implementation] christian
Line 2: Line 2:
  
 Bitmapped images are described in chapter 8.9 //Images// on page 203 of the {{pdf32000_2008.pdf#page=211|PDF specification}} on quite readable 14 pages. Bitmapped images are described in chapter 8.9 //Images// on page 203 of the {{pdf32000_2008.pdf#page=211|PDF specification}} on quite readable 14 pages.
 +
 +The implementation is in package ''PDF Images''.
 ===== Usage ===== ===== Usage =====
  
Line 23: Line 25:
     renderer paintXObject: anImage asPDF]].     renderer paintXObject: anImage asPDF]].
 </code> </code>
 +
 +{{demo20_ImagesUsage.pdf}} shows the result with an example image.
 +
 +{{demo21_Images.pdf}} shows some PDF features of images (masking, rotation, interpolation, inverting and alpha blended images).
  
 ===== Object Models ===== ===== Object Models =====
Line 95: Line 101:
  
 The conversion methods are implemented in the ''Graphics.Image'' hierarchy. To convert a Smalltalk image to PDF with ''asPDF'', the method ''writePixelsTo: anImageXObject'' transfers the actual pixels from the Smalltalk to the PDF image. The other direction uses the method ''readPixelsFrom: anImageXObject'' which transfers the PDF pixels to the Smalltalk image. The conversion methods are implemented in the ''Graphics.Image'' hierarchy. To convert a Smalltalk image to PDF with ''asPDF'', the method ''writePixelsTo: anImageXObject'' transfers the actual pixels from the Smalltalk to the PDF image. The other direction uses the method ''readPixelsFrom: anImageXObject'' which transfers the PDF pixels to the Smalltalk image.
 +
 +{{ :pdf:bitfiddling200x266.png?nolink|Work sketch for bit fiddling}}
  
 The default behavior is to transfer the pixels one by one. For each pixel, the bits are read from the specified location in the source image bytes and interpreted as color (''valueAtPoint:''). This color is then converted to the target bits which are written to the specified location in the target image bytes (''valueAtPoint:put:''). While these two pixel accessors are correct and well tested for any kind of image, they are very slow. The default behavior is to transfer the pixels one by one. For each pixel, the bits are read from the specified location in the source image bytes and interpreted as color (''valueAtPoint:''). This color is then converted to the target bits which are written to the specified location in the target image bytes (''valueAtPoint:put:''). While these two pixel accessors are correct and well tested for any kind of image, they are very slow.
Line 111: Line 119:
 The direct conversion of an image with a mapped palette is special. Since RGB color components are represented with 13 bits in Smalltalk, but using 8 bits in PDF, a Smalltalk palette may have more than one entry for one 8 bit RGB color. This is correctly handled when converting the image pixel by pixel, because each color is stored as 8 bit color in the PDF /Indexed colorspace, thereby aligning different 3x13 bit colors to the same 3x8 bit color. The direct conversion of an image with a mapped palette is special. Since RGB color components are represented with 13 bits in Smalltalk, but using 8 bits in PDF, a Smalltalk palette may have more than one entry for one 8 bit RGB color. This is correctly handled when converting the image pixel by pixel, because each color is stored as 8 bit color in the PDF /Indexed colorspace, thereby aligning different 3x13 bit colors to the same 3x8 bit color.
  
-When converting such image optimized by converting the palette and using the same indexes for the pixels allowing direct reuse of the image bytes, the /Indexed colorspace may contain several entries for the same color. Although this does not feel proper, it will not make much difference in practice. But the speed up of the optimization is worth it. +When converting such image optimized by converting the palette and using the same indexes for the pixels allowing direct reuse of the image bytes, the /Indexed colorspace may contain several entries for the same color. Converting such an ImageXObject back to Smalltalk will not recreate the least significant 5 bits leading to slightly different colors as in the original. But for 8 bit RGB usage, it will not make any difference. Although this does not feel proper, it will not make much difference in practice. But the speed up of the optimization is worth it. 
-===== Disclaimer =====+===== To be done =====
  
-Not covered are the special {{pdf32000_2008.pdf#page=22|filters}} for various kinds of images:+==== Filter ==== 
 + 
 +Although all Smalltalk images can be used for PDF, not all PDF images can be transformed to Smalltalk images. For one, several {{pdf32000_2008.pdf#page=22|filters}} specific to images are not implemented:
   * **RunLengthDecode** 8 bit monochrome images   * **RunLengthDecode** 8 bit monochrome images
   * **CCITTFaxDecode** CCITT encoded 1 bit monochrome images   * **CCITTFaxDecode** CCITT encoded 1 bit monochrome images
   * **JBIG2Decode** JBIG2 encoded 1 bit monochrome images   * **JBIG2Decode** JBIG2 encoded 1 bit monochrome images
   * **DCTDecode** JPEG encoded 8 bit grayscale or color images   * **DCTDecode** JPEG encoded 8 bit grayscale or color images
-  * **JPXDecode** JPEG2000 encoded grayscale or color images+  * **JPXDecode** JPEG2000 encoded grayscale or color images
 + 
 +This means that it is not possible to extract such images from PDF. Nor is it possible to store images in the most efficient way in a PDF. This feature is valuable and I hope to implement some of the filters in the not too distant future.
  
-These are not implemented (yet)so that it is not possible to extract such images from PDFNor is it possible to store images in the most efficient way in a PDF. Just the basic **FlateDecode** filter is used by default to compress images.+SecondlyPDF can have images in other colorspaces than RGB or Grayscale; most notable is ''/DeviceCMYK'' for print. For correctly extracting such images, proper color conversions to RGB need to be implementedThis feature is not intersting to me at the moment.
  
 +==== Inlined Images ====
  
 +Images in PDF can be inlined in the /Contents stream instead of storing them in the /Resources as /XObject. Only a subset of legal PDF images can be inlined and it is discouraged for large images. Even though, I have not seen such image in a real-world PDF, this feature should be implemented for completeness.
/var/www/virtual/code4hl/html/dokuwiki/data/attic/pdf/images.1456134559.txt.gz · Last modified: 2016/02/22 10:49 (external edit)