Thread: [GM-help] Error message: : Old-style JPEG compression support is not configured
Swiss army knife of image processing
Brought to you by:
bfriesen
Menu
▾
▴
graphicsmagick-help
|
From: Mark M. <mar...@gm...> - 2011-08-02 03:56:23
|
When I do the following:
gm convert foo.tif bar.png
(where foo.tif is a 200dpi color scanned file -- probably a Canon from what
I am reading about them using the 'old style')
I get the following message:
gm convert: Old-style JPEG compression support is not configured.
How do I configure my build to make this work?
When I am running the stable version of GM, I get that message. When I run
the latest snapshot I get a Segmentation fault.
Separately, If I process a large TIFF (33Megs --977 pages) using the
snapshot version of GM, it takes all the CPU and brings everything else to a
crawl and it uses a ton of swap space.
This is my configure command before building: ./configure -prefix=/usr
I am running the latest version of 64-bit Centos (5.6) with a quad core and
24G of RAM (which has been virtualized on XenCenter). Here are my
appropriate libraries:
0 lrwxrwxrwx 1 root root 11 Jul 27 01:33 libbz2.so ->
libbz2.so.1
0 lrwxrwxrwx 1 root root 15 Jul 27 01:33 libbz2.so.1 ->
libbz2.so.1.0.3
76 -rwxr-xr-x 1 root root 70404 Sep 21 2010 libbz2.so.1.0.3
4.0M -rw-r--r-- 1 root root 4.0M Jan 21 2011 libfreetype.a
4.0K -rwxr-xr-x 1 root root 947 Jan 21 2011 libfreetype.la
0 lrwxrwxrwx 1 root root 20 Jan 21 2011 libfreetype.so ->
libfreetype.so.6.6.2
0 lrwxrwxrwx 1 root root 20 Jan 21 2011 libfreetype.so.6 ->
libfreetype.so.6.6.2
520K -rwxr-xr-x 1 root root 514K Nov 16 2010 libfreetype.so.6.3.10
2.3M -rwxr-xr-x 1 root root 2.3M Jan 21 2011 libfreetype.so.6.6.2
0 lrwxrwxrwx 1 root root 17 Apr 26 22:19 libjpeg.so ->
libjpeg.so.62.0.0
4.0K lrwxrwxrwx 1 root root 17 Jan 19 2011 libjpeg.so.62 ->
libjpeg.so.62.0.0
140K -rwxr-xr-x 1 root root 132K Jan 5 2007 libjpeg.so.62.0.0
0 lrwxrwxrwx 1 root root 16 Jan 21 2011 libjpeg.so.8 ->
libjpeg.so.8.3.0
936K -rwxr-xr-x 1 root root 932K Jan 21 2011 libjpeg.so.8.3.0
196K -rw-r--r-- 1 root root 189K Jul 14 2010 libpng12.a
0 lrwxrwxrwx 1 root root 18 Jan 21 2011 libpng12.so ->
libpng12.so.0.10.0
0 lrwxrwxrwx 1 root root 18 Jan 21 2011 libpng12.so.0 ->
libpng12.so.0.10.0
156K -rwxr-xr-x 1 root root 149K Jul 14 2010 libpng12.so.0.10.0
924K -rw-r--r-- 1 root root 917K Jan 21 2011 libpng14.a
4.0K -rwxr-xr-x 1 root root 931 Jan 21 2011 libpng14.la
0 lrwxrwxrwx 1 root root 18 Jan 21 2011 libpng14.so ->
libpng14.so.14.5.0
0 lrwxrwxrwx 1 root root 18 Jan 21 2011 libpng14.so.14 ->
libpng14.so.14.5.0
524K -rwxr-xr-x 1 root root 519K Jan 21 2011 libpng14.so.14.5.0
0 lrwxrwxrwx 1 root root 10 Jan 21 2011 libpng.a -> libpng14.a
0 lrwxrwxrwx 1 root root 11 Jan 21 2011 libpng.la -> libpng14.la
0 lrwxrwxrwx 1 root root 11 Jan 21 2011 libpng.so -> libpng14.so
0 lrwxrwxrwx 1 root root 16 Jan 21 2011 libpng.so.3 ->
libpng.so.3.10.0
164K -rwxr-xr-x 1 root root 159K Jul 14 2010 libpng.so.3.10.0
0 lrwxrwxrwx 1 root root 10 Jul 23 22:36 libpng.a -> libpng12.a
0 lrwxrwxrwx 1 root root 11 Jul 23 22:36 libpng.so ->
libpng12.so
4 lrwxrwxrwx 1 root root 16 Jul 20 21:27 libpng.so.3 ->
libpng.so.3.10.0
168 -rwxr-xr-x 1 root root 162336 Jul 14 2010 libpng.so.3.10.0
1.7M -rw-r--r-- 1 root root 1.7M Jan 21 2011 libtiff.a
4.0K -rwxr-xr-x 1 root root 932 Jan 21 2011 libtiff.la
0 lrwxrwxrwx 1 root root 16 Jan 21 2011 libtiff.so ->
libtiff.so.3.9.4
0 lrwxrwxrwx 1 root root 16 Jun 17 18:40 libtiff.so.3 ->
libtiff.so.3.9.4
360K -rwxr-xr-x 1 root root 356K Mar 30 21:49 libtiff.so.3.8.2
1.1M -rwxr-xr-x 1 root root 1.1M Jan 21 2011 libtiff.so.3.9.4
100K -rw-r--r-- 1 root root 93K Jan 21 2011 libtiffxx.a
4.0K -rwxr-xr-x 1 root root 958 Jan 21 2011 libtiffxx.la
0 lrwxrwxrwx 1 root root 18 Jan 21 2011 libtiffxx.so ->
libtiffxx.so.3.9.4
0 lrwxrwxrwx 1 root root 18 Jun 17 18:40 libtiffxx.so.3 ->
libtiffxx.so.3.9.4
8.0K -rwxr-xr-x 1 root root 7.4K Mar 30 21:49 libtiffxx.so.3.8.2
68K -rwxr-xr-x 1 root root 61K Jan 21 2011 libtiffxx.so.3.9.4
136K -rw-r--r-- 1 root root 130K Jan 21 2011 libz.a
0 lrwxrwxrwx 1 root root 13 Jan 21 2011 libz.so -> libz.so.1.2.5
0 lrwxrwxrwx 1 root root 13 Jan 21 2011 libz.so.1 -> libz.so.1.2.5
80K -rwxr-xr-x 1 root root 74K Jan 9 2007 libz.so.1.2.3
108K -rwxr-xr-x 1 root root 104K Jan 21 2011 libz.so.1.2.5
Thanks,
Mark
|
|
From: Bob F. <bfr...@si...> - 2011-08-03 14:14:08
|
On Mon, 1 Aug 2011, Mark Miller wrote: > When I do the following: > gm convert foo.tif bar.png > (where foo.tif is a 200dpi color scanned file -- probably a Canon from what I am reading about them using > the ‘old style’) > > I get the following message: > > gm convert: Old-style JPEG compression support is not configured. > > How do I configure my build to make this work? Support for Old-style JPEG compression is totally dependent on the capabilities of the installed libtiff. Support for old-style JPEG is a configure option for libtiff. Different versions of libtiff have considerably-differing capabilities to read old-style JPEG. It will never be perfect because one reason why old-style JPEG was abandoned is because its design was so flimsy that interoperability was not assured. It may be that libtiff 4.0.0beta7 will do better with old-style JPEG and I know that there are patches submitted to the libtiff bug-tracker (and not yet applied) which may help libtiff read some old-style JPEG better. > When I am running the stable version of GM, I get that message. When I run the latest snapshot I get a > Segmentation fault. I am curious if the segmentation fault is in libtiff or GM. Is it possible that your stable version of GM is linked with an older version of libtiff? The version of libtiff (and libjpeg) used should be included in 'gm convert -list formats' output. You also have two major versions of libjpeg installed. Libtiff also links against libjpeg. It is possible that libtiff and GM are built with different versions of libjpeg, resulting in two versions of libjpeg in the same application. You can use 'ldd `which gm`' to see what libraries are actually used. > Separately, If I process a large TIFF (33Megs --977 pages) using the snapshot version of GM, it takes all > the CPU and brings everything else to a crawl and it uses a ton of swap space. Due to an architectural-shortcoming in GM, it loads all frames before it writes any frames. GM is therefore best used for processing a limited number of frames. It might help to use the array syntax to request only a sub-range of the input frames and then process the file incrementally. For example: 'file.tiff[2-3]' 'file.tiff[3]' gm convert 'file.tiff[3]' frame4.tiff However, streaming tools like 'tiffcp' will scale much better because they only load one frame at once. With some luck, you can find/build a working 'tiffcp' (perhaps based on libtiff 4.0.0beta7 or even libtiff CVS) which would allow you to convert your old-JPEG compressed TIFF to modern TIFF. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Mark M <mar...@ya...> - 2011-08-03 23:29:00
|
Bob, thank you very much for your detailed answer! I am using GM in a php worker script (using the exec function to call the command line; not the php extension) being controlled by gearman as a task manager to dispatch asynchronous conversion duties to worker scripts. I am converting pdf and tiffs, though I may add support for jpg, gif and png in the future. Does GM do anything special with the pdfs before or after passing them to ghostscript or is it simply a wrapper in the conversion? In other words, do I get any additional advantage of going through GM to get to ghostscript or it is simply a convenience so processing can have an common interface? I am using the array syntax to provide progress feedback, glad to know my approach is correct. I am currently processing in batches of five pages at a time, is that too low? Could I up it to 20-25 or 50 pages without affecting system performance? Is there a sweet spot between memory and cpu usage and the cost of restarting GM for each batch of pages? I am going to work on the old style jpeg problem using the clues you provided, if I find a working solution, I will post it back in this thread to help others who run across this problem. Also, I am thinking about using zbar to decode some barcodes, it needs ImageMagick to interpret raw image data, can I configure GM in a way so when I build this application, it thinks GM is ImageMagick so I don't have to install ImageMagick? -----Original Message----- From: Bob Friesenhahn [mailto:bfr...@si...] Sent: Wednesday, August 03, 2011 7:14 AM To: Mark Miller Cc: gra...@li... Subject: Re: [GM-help] Error message: : Old-style JPEG compression support is not configured On Mon, 1 Aug 2011, Mark Miller wrote: > When I do the following: > gm convert foo.tif bar.png > (where foo.tif is a 200dpi color scanned file -- probably a Canon from what I am reading about them using > the ?old style?) > > I get the following message: > > gm convert: Old-style JPEG compression support is not configured. > > How do I configure my build to make this work? Support for Old-style JPEG compression is totally dependent on the capabilities of the installed libtiff. Support for old-style JPEG is a configure option for libtiff. Different versions of libtiff have considerably-differing capabilities to read old-style JPEG. It will never be perfect because one reason why old-style JPEG was abandoned is because its design was so flimsy that interoperability was not assured. It may be that libtiff 4.0.0beta7 will do better with old-style JPEG and I know that there are patches submitted to the libtiff bug-tracker (and not yet applied) which may help libtiff read some old-style JPEG better. > When I am running the stable version of GM, I get that message. When I run the latest snapshot I get a > Segmentation fault. I am curious if the segmentation fault is in libtiff or GM. Is it possible that your stable version of GM is linked with an older version of libtiff? The version of libtiff (and libjpeg) used should be included in 'gm convert -list formats' output. You also have two major versions of libjpeg installed. Libtiff also links against libjpeg. It is possible that libtiff and GM are built with different versions of libjpeg, resulting in two versions of libjpeg in the same application. You can use 'ldd `which gm`' to see what libraries are actually used. > Separately, If I process a large TIFF (33Megs --977 pages) using the snapshot version of GM, it takes all > the CPU and brings everything else to a crawl and it uses a ton of swap space. Due to an architectural-shortcoming in GM, it loads all frames before it writes any frames. GM is therefore best used for processing a limited number of frames. It might help to use the array syntax to request only a sub-range of the input frames and then process the file incrementally. For example: 'file.tiff[2-3]' 'file.tiff[3]' gm convert 'file.tiff[3]' frame4.tiff However, streaming tools like 'tiffcp' will scale much better because they only load one frame at once. With some luck, you can find/build a working 'tiffcp' (perhaps based on libtiff 4.0.0beta7 or even libtiff CVS) which would allow you to convert your old-JPEG compressed TIFF to modern TIFF. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1518/3807 - Release Date: 08/03/11 |
|
From: Bob F. <bfr...@si...> - 2011-08-04 02:35:06
|
On Wed, 3 Aug 2011, Mark M wrote: > > Does GM do anything special with the pdfs before or after passing them to > ghostscript or is it simply a wrapper in the conversion? In other words, do > I get any additional advantage of going through GM to get to ghostscript or > it is simply a convenience so processing can have an common interface? The ghostscript user interface is not very user-friendly. It is indeed a convenience to have a common interface. You can see how gm runs Ghostscript by adding the -verbose option. > I am using the array syntax to provide progress feedback, glad to know my > approach is correct. I am currently processing in batches of five pages at > a time, is that too low? Could I up it to 20-25 or 50 pages without > affecting system performance? Is there a sweet spot between memory and cpu > usage and the cost of restarting GM for each batch of pages? I am not sure what the answer to this would be. Certainly you would not want to load more pages than can fit in memory. My previous testing with PDF showed that Ghostscript was quite fast at finding/selecting PDF pages so it was reasonably efficient to select one page at a time, even with documents of hundreds of pages. I have not done any testing with TIFF to know what the overhead is like. TIFF is quite a lot faster than Ghostscript so if there is overhead, it would become more noticeable. > I am going to work on the old style jpeg problem using the clues you > provided, if I find a working solution, I will post it back in this thread > to help others who run across this problem. Make sure to check the libtiff bugtracker and find discussions on the libtiff mailing list. > Also, I am thinking about using zbar to decode some barcodes, it needs > ImageMagick to interpret raw image data, can I configure GM in a way so when > I build this application, it thinks GM is ImageMagick so I don't have to > install ImageMagick? Looking at the Zbar code (zbarimg.c), it looks like the code uses the Wand API. At the C code level the Wand API is likely very close to working since it was originally developed using a Wand API very similar to the one that GM provides. The configure script would definitely not be your friend since it only knows about ImageMagick and it would not find/use GraphicsMagick. Someone needs to let Jeff Brown know about GraphicsMagick and suggest that zbar should support it. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Mark M <mar...@ya...> - 2011-08-08 01:10:25
|
An update on this issue. Thanks for the pointers, Bob, as it led to the fix of the problem. Now, this may not fix all Old JPEG issues, but it did for my Canon compressed color TIFF scans. Grab the jpeg62b tar ball from http://libjpeg.sourceforge.net/. The ijg version is 8c and there is no version history on this site. Bob, does GM build against 8c? Get the contributed patch (contrib/ojpeg) from the tiff-3.8.2 source. This patch was contributed by Scott Marovich. You don't actually need to grab this as all you need to do is add the following function to the end of jdhuff.c (as stated in the patch): ================================================================= GLOBAL(void) jpeg_reset_huff_decode (register j_decompress_ptr cinfo,register float *refbw) { register huff_entropy_ptr entropy = (huff_entropy_ptr)cinfo->entropy; register int ci = 0; /* Re-initialize DC predictions */ do entropy->saved.last_dc_val[ci] = -refbw[ci << 1]; while (++ci < cinfo->comps_in_scan); /* Discard encoded input bits, up to the next Byte boundary */ entropy->bitstate.bits_left &= ~7; } ================================================================= Build the jpeg library. If you are building on an x86_64, it may have a problem configuring. You can fix this by copying config.guess and config.sub into the jpeg source directory (on my Centos box, these files are located in the /usr/lib/rpm directory, YMMV). I am building 64bit versions of the libraries. If you are building on a 32-bit system you probably don't need to add the libdir parameter in the make statements that follow. Run the following from the command line: ./configure --enable-shared --enable-static make libdir=/usr/lib64 make test make libdir=/usr/lib64 install Get the tiff4.0.0beta7 tarball from http://download.osgeo.org/libtiff/ (this seems to build with gcc 4.4; 3.x versions required a lesser version of gcc IIRC). The patch mentions that the following needs to be done: ============================================================== o Uncomment OJPEG="yes" statement in config.site file or #define OJPEG_SUPPORT somewhere. This can be put in tiffconf.h for instance. =============================================================== I couldn't find a config.site file and I forgot to put in the define in tiffconf.h but it seems to not be a problem. Run: ./configure This is what I have after configure runs (the chevrons were added by me, note Old JPEG support): ============================================================================ =============== Libtiff is now configured for x86_64-unknown-linux-gnu Installation directory: /usr/local Documentation directory: ${prefix}/share/doc/tiff-4.0.0beta7 C compiler: gcc -g -O2 -Wall -W C++ compiler: g++ -g -O2 Enable runtime linker paths: no Support Microsoft Document Imaging: yes Use win32 IO: no Support for internal codecs: CCITT Group 3 & 4 algorithms: yes Macintosh PackBits algorithm: yes LZW algorithm: yes ThunderScan 4-bit RLE algorithm: yes NeXT 2-bit RLE algorithm: yes LogLuv high dynamic range encoding: yes Support for external codecs: ZLIB support: yes Pixar log-format algorithm: yes JPEG support: yes >>> Old JPEG support: yes <<< JPEG 8/12 bit dual mode: no ISO JBIG support: no LZMA2 support: no C++ support: yes OpenGL support: no ============================================================================ =============== make libdir=/usr/lib64 make check make libdir=/usr/lib64 install Interestingly, this shows up as libtiff.so.5.0.4 and libtiffxx.so.5.0.4, I would expect libtiff.so.4.x.x or something like that. I also built the latest version of libpng before building GM (not relevant I don't think, but why not have it). Build GM the usual way and you should have Old JPEG support in GM (I used the latest snapshot). You want to make sure there aren't conflicting versions of libjpeg or libtiff installed (if so remove them before building anything) Thanks again, Bob for your help. -----Original Message----- From: Bob Friesenhahn [mailto:bfr...@si...] Sent: Wednesday, August 03, 2011 7:35 PM To: Mark M Cc: GraphicsMagick Help Subject: RE: [GM-help] Error message: : Old-style JPEG compression support is not configured On Wed, 3 Aug 2011, Mark M wrote: > > Does GM do anything special with the pdfs before or after passing them to > ghostscript or is it simply a wrapper in the conversion? In other words, do > I get any additional advantage of going through GM to get to ghostscript or > it is simply a convenience so processing can have an common interface? The ghostscript user interface is not very user-friendly. It is indeed a convenience to have a common interface. You can see how gm runs Ghostscript by adding the -verbose option. > I am using the array syntax to provide progress feedback, glad to know my > approach is correct. I am currently processing in batches of five pages at > a time, is that too low? Could I up it to 20-25 or 50 pages without > affecting system performance? Is there a sweet spot between memory and cpu > usage and the cost of restarting GM for each batch of pages? I am not sure what the answer to this would be. Certainly you would not want to load more pages than can fit in memory. My previous testing with PDF showed that Ghostscript was quite fast at finding/selecting PDF pages so it was reasonably efficient to select one page at a time, even with documents of hundreds of pages. I have not done any testing with TIFF to know what the overhead is like. TIFF is quite a lot faster than Ghostscript so if there is overhead, it would become more noticeable. > I am going to work on the old style jpeg problem using the clues you > provided, if I find a working solution, I will post it back in this thread > to help others who run across this problem. Make sure to check the libtiff bugtracker and find discussions on the libtiff mailing list. > Also, I am thinking about using zbar to decode some barcodes, it needs > ImageMagick to interpret raw image data, can I configure GM in a way so when > I build this application, it thinks GM is ImageMagick so I don't have to > install ImageMagick? Looking at the Zbar code (zbarimg.c), it looks like the code uses the Wand API. At the C code level the Wand API is likely very close to working since it was originally developed using a Wand API very similar to the one that GM provides. The configure script would definitely not be your friend since it only knows about ImageMagick and it would not find/use GraphicsMagick. Someone needs to let Jeff Brown know about GraphicsMagick and suggest that zbar should support it. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1390 / Virus Database: 1518/3809 - Release Date: 08/03/11 |
|
From: Bob F. <bfr...@si...> - 2011-08-08 14:03:47
|
On Sun, 7 Aug 2011, Mark M wrote: > An update on this issue. Thanks for the pointers, Bob, as it led to the fix > of the problem. Now, this may not fix all Old JPEG issues, but it did for > my Canon compressed color TIFF scans. > > Grab the jpeg62b tar ball from http://libjpeg.sourceforge.net/. The ijg > version is 8c and there is no version history on this site. > > Bob, does GM build against 8c? Yes, it does. > Get the contributed patch (contrib/ojpeg) from the tiff-3.8.2 source. This > patch was contributed by Scott Marovich. You don't actually need to grab > this as all you need to do is add the following function to the end of > jdhuff.c (as stated in the patch): This sort of fix would be quite problematic as a fix to be included in the libjpeg distributed with an OS like Linux since it adds a new interface. Perhaps we could lobby to have it included in JPEG 8d? > Interestingly, this shows up as libtiff.so.5.0.4 and libtiffxx.so.5.0.4, I > would expect libtiff.so.4.x.x or something like that. Older libtiff actually did things wrong since the numbering is supposed to be based on API changes and not release numbering. The library is numbered appropriately starting with 4.0. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
|
From: Bob F. <bfr...@si...> - 2011-08-08 14:06:41
|
On Sun, 7 Aug 2011, Mark M wrote:
> Get the contributed patch (contrib/ojpeg) from the tiff-3.8.2 source. This
> patch was contributed by Scott Marovich. You don't actually need to grab
> this as all you need to do is add the following function to the end of
> jdhuff.c (as stated in the patch):
>
> =================================================================
> GLOBAL(void)
> jpeg_reset_huff_decode (register j_decompress_ptr cinfo,register float
> *refbw)
> { register huff_entropy_ptr entropy = (huff_entropy_ptr)cinfo->entropy;
> register int ci = 0;
> /* Re-initialize DC predictions */
> do entropy->saved.last_dc_val[ci] = -refbw[ci << 1];
> while (++ci < cinfo->comps_in_scan);
> /* Discard encoded input bits, up to the next Byte boundary */
> entropy->bitstate.bits_left &= ~7;
> }
> =================================================================
Absent some other unmentioned patch, I am not finding any code which
would invoke this function. I think that what got OJPEG working for
you is tiff4.0.0beta7, which includes substantially re-worked OJPEG
support.
Bob
--
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
|
|
From: Mark M <mar...@ya...> - 2011-09-02 22:13:15
|
Bob, You were correct in that the beta version handles this Old Style JPEG issue and the patch was unnecessary. So thanks again for the point in that direction. A couple of more questions that I have. Do you know of a source with a variety of tiff files with all the different types of compression (fax, old style, jpeg, and the other dozen that the libtiff can handle in single and multipage, color, gray scale and B&W formats, so I can use them as a collection of test files for GM to process? I use GM to split a multipage tiffs into individual pages. When I encounter a multipage Old Style JPEG file and GM breaks it out into individual page, the newer JPEG format makes the individual pages much larger. Case in point, if I do the following (24-bit color 200dpi with a single page tiff in the Old Style JPEG compression): gm convert old-style-jpeg.tif current-style-jpeg.tif it nearly triples in size. In my test file, it goes from 659K to 1.8M. I understand that the sum of the single page sizes will be greater that the multipage source it came from because it can't take advantage of shared tables and other resources of the multipage file will have, but triple? And this is a straight single page conversion so shared resources overhead wouldn't be a factor at all. Here are tiffinfo dumps on the files mentioned above: old-style-jpeg.tif: TIFFReadDirectory: Warning, Photometric tag value assumed incorrect, assuming data is YCbCr instead of RGB. TIFF Directory at offset 0x8 (8) Subfile Type: (0 = 0x0) Image Width: 1700 Image Length: 2200 Resolution: 200, 200 pixels/inch Bits/Sample: 8 Compression Scheme: Old-style JPEG Photometric Interpretation: YCbCr YCbCr Subsampling: 2, 2 Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 2200 Planar Configuration: single image plane JpegInterchangeFormat: 512 JpegInterchangeFormatLength: 623 JpegQTables: 537 606 606 JpegDcTables: 694 910 910 JpegAcTables: 727 943 943 JpegProc: 1 Current-style-jpeg.tif TIFF Directory at offset 0x1c8ee2 (1871586) Image Width: 1700 Image Length: 2200 Resolution: 200, 200 pixels/inch Bits/Sample: 8 Sample Format: unsigned integer Compression Scheme: JPEG Photometric Interpretation: RGB color Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 16 Planar Configuration: single image plane Page Number: 0-1 DocumentName: foo.tif Software: GraphicsMagick 1.4 unreleased Q8 http://www.GraphicsMagick.org/ JPEG Tables: (289 bytes) Is there a way to maintain the old-style JPEG compression across individual pages or a way to get the new jpeg compression to be comparable in size to the old? Thanks, Mark -----Original Message----- From: Bob Friesenhahn [mailto:bfr...@si...] Sent: Monday, August 08, 2011 7:07 AM To: Mark M Cc: 'GraphicsMagick Help' Subject: Re: [GM-help] Error message: : Old-style JPEG compression support is not configured On Sun, 7 Aug 2011, Mark M wrote: > Get the contributed patch (contrib/ojpeg) from the tiff-3.8.2 source. This > patch was contributed by Scott Marovich. You don't actually need to grab > this as all you need to do is add the following function to the end of > jdhuff.c (as stated in the patch): > > ================================================================= > GLOBAL(void) > jpeg_reset_huff_decode (register j_decompress_ptr cinfo,register float > *refbw) > { register huff_entropy_ptr entropy = (huff_entropy_ptr)cinfo->entropy; > register int ci = 0; > /* Re-initialize DC predictions */ > do entropy->saved.last_dc_val[ci] = -refbw[ci << 1]; > while (++ci < cinfo->comps_in_scan); > /* Discard encoded input bits, up to the next Byte boundary */ > entropy->bitstate.bits_left &= ~7; > } > ================================================================= Absent some other unmentioned patch, I am not finding any code which would invoke this function. I think that what got OJPEG working for you is tiff4.0.0beta7, which includes substantially re-worked OJPEG support. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ----- No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1391 / Virus Database: 1520/3820 - Release Date: 08/07/11 |
|
From: Bob F. <bfr...@si...> - 2011-09-03 01:26:49
|
On Fri, 2 Sep 2011, Mark M wrote: > Bob, > > You were correct in that the beta version handles this Old Style JPEG issue > and the patch was unnecessary. So thanks again for the point in that > direction. A couple of more questions that I have. > > Do you know of a source with a variety of tiff files with all the different > types of compression (fax, old style, jpeg, and the other dozen that the > libtiff can handle in single and multipage, color, gray scale and B&W > formats, so I can use them as a collection of test files for GM to process? Obtain http://download.osgeo.org/libtiff/pics-3.8.0.tar.gz and also various files from ftp://ftp.graphicsmagick.org/pub/tiff-samples/ some of which are not possible to read without a very special build of GraphicsMagick (e.g. 12-bit JPEG compression). > I use GM to split a multipage tiffs into individual pages. When I encounter > a multipage Old Style JPEG file and GM breaks it out into individual page, > the newer JPEG format makes the individual pages much larger. Case in > point, if I do the following (24-bit color 200dpi with a single page tiff in > the Old Style JPEG compression): > > gm convert old-style-jpeg.tif current-style-jpeg.tif > > it nearly triples in size. In my test file, it goes from 659K to 1.8M. I > understand that the sum of the single page sizes will be greater that the > multipage source it came from because it can't take advantage of shared > tables and other resources of the multipage file will have, but triple? And > this is a straight single page conversion so shared resources overhead > wouldn't be a factor at all. There seem to be two primary factors. One is that YCbCr Subsampling is used with a 2,2 sampling factor (very sparse sampling). Another is likely that the effective JPEG "quality" factor is different. The quality factor can be influenced with -quality (e.g. -quality 30) just like with a JPEG file. I am not currently seeing code in GraphicsMagick which will do anything useful with sampling factor for JPEG compressed TIFF. Perhaps it is possible to support it. > Is there a way to maintain the old-style JPEG compression across individual > pages or a way to get the new jpeg compression to be comparable in size to > the old? GM will not write old-style JPEG compression because libtiff does not allow it. With source code changes it may be possible to support specifying a sampling factor, and perhaps even preserving it. Bob -- Bob Friesenhahn bfr...@si..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X