"Bmp Conversion" is done for 16- and 24 bit images. 1, 2, 4 and 8 are on queue due to the color palette but that's not really a problem. Results are much better then I thought.
All files of the first test compressed with paq8p3 use switch 7. Second uses switch 5.
#First Test-file 1024x768. Packbits doesn't work well due to much details
Code:
original: 2,376,340
precompressed-bmp: 2,362,651 bytes
precompressed+bmp: 2,362,649 bytes
paq8p3+original: 1,008,408 bytes
paq8p3+precompressed-bmp: 975,990 bytes
paq8p3+precompressed+bmp: 659,243 bytes
#Second Test-file is the well known FlashMX.pdf converted to a multi-page TIFF and surely compressed with packjpg. It's not much better because the bmp model compresses only one bmp and the other one could use more data/redundancy I guess ?!?
Code:
precompressed+bmp: 587,895,156 bytes
original: 40,992,708 bytes
paq8p3+original: 2,840,049 bytes
paq8p3+precompressed+bmp: 2,578,709 bytes (90 bmp streams)
#Third Test file another one-page image. It's a psd high resolution resized image. I know those sort of pictures never will be saved as TIFF-files but still TIFF files could get much details and a high resolution. 4092x3069
Code:
precompressed: 37,699,877 bytes
original: 27,535,810 bytes
paq8p3+original: 5,342,787 bytes (1637.22 sec)
paq8p3+precompressed: 2,415,141 bytes (494.58 sec)
(Timings aren't absolutly right because I used the computer (no intensive use) but I started both the same time and the original had a lot of time alone at the end.
Does the paq model need DWORD padding? Then it's also limited to DWORD aligned pictures.
With this for the next release uncompressed images will get precompressed too.
Another idea is to convert images inside a multi-page document like FlashMX that are black-white only to 1bit. Image programs don't do this on there own.
EDIT:
Added test 3