Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
images [2016/02/22 10:02] christian [Masked Images] |
images [2016/02/22 17:19] christian [To be done] |
||
---|---|---|---|
Line 98: | Line 98: | ||
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 ('' | 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 ('' | ||
- | This default implementation ('' | + | This default implementation ('' |
- | Some conversions can be greatly sped up by exploiting the internal byte organization of the image bits and transfering them directly. While this is possible for many useful forms, it is not possible in general (think of a Smalltalk image with a big palette of more than 255 colors). The following conversions are currently optimized: | + | Some conversions can be greatly sped up (one or two orders of magnitude) |
+ | |||
+ | The following conversions are currently optimized: | ||
* Depth1Image for Black and white images and masks | * Depth1Image for Black and white images and masks | ||
* Depth24Image with 8 bit RGB | * Depth24Image with 8 bit RGB | ||
* Depth32Image for 8 bit RGB and BGR images taken from the '' | * Depth32Image for 8 bit RGB and BGR images taken from the '' | ||
* Depth32Image for 8 bit ARGB and ABGR | * Depth32Image for 8 bit ARGB and ABGR | ||
- | ===== Disclaimer ===== | + | * Depth{2 4 8)Image with a MappedPalette. |
- | Not covered | + | The direct conversion of an image with a mapped palette is special. Since RGB color components |
+ | |||
+ | 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. | ||
+ | ===== To be done ===== | ||
+ | |||
+ | Although all Smalltalk images can be used for PDF, not all PDF images can be transformed to Smalltalk images. For one, several | ||
* **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. |
- | + | ||
- | These are not implemented (yet), so 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. Just the basic **FlateDecode** filter is used by default to compress | + | |
+ | 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. | ||
+ | Secondly, PDF can have images in other colorspaces than RGB or Grayscale; most notable is ''/ |