I have been investigating the possible replacement of Kakadu (kdu_compress) with ImageMagick (convert). The developers of our web application agree that removing kdu_compress from the submission workflow would be a positive step, as it would simplify things. However, we would need to keep the Kakadu decoding component because we use IIP image server which does not yet support OpenJPG decoding.
Testing has shown that ImageMagick crashes when trying to convert certain tiff files to jp2 files. I cannot identify anything particular about those tiff files but I have found a fix - set the bit depth to 8, e.g.:
convert -depth 8 input.tiff output.jp2
This could possibly be expanded to something like the following, including minimal 'image data only', as one of the examples at http://www.imagemagick.org/Usage/formats/#BMP suggests, though I'm not sure it's necessary:
(As an aside, we've found that for particular images, typically those with handwritten text, the output file generated by kdu_compress is of poor quality; replacing that image with one that has less compression resolves this - as one might expect!)
It is interesting to see Kris Bulman's equivalent command line for convert - see this post. However, the current ImageMagick jp2 options page at http://www.imagemagick.org/script/jp2.php suggests that many of the switches employed in Kris's command line no longer exist, and I'm really not sure what are sensible values to use with the current options. Compare with a (presumably older) ImageMagick jp2 options page at this page which lists the options that Kris suggests.
Has anyone else moved over to using convert for the creation of derivative non-archival jp2 files for IIP image streaming/deepzoom? Any tips/experiences you would be willing to share?
Would there be any problems keeping a minimalist command line such as 'convert -depth 8 input.tiff output.jp2'? We're not too worried about file size. Limited testing shows IIP server handles ImageMagick-generated jp2s okay.
Thanks for any replies, and I'm new to a lot of this so please be gentle :)
thanks,
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Just for info: we have very positive experiences with kakadu. It's so much faster then imagemagick and very stable. We have a very large number of TIFF's and started our project with Imagemagick but that was troublesome. When switching to kakadu the conversion ran very smooth and lightning fast with zero maintenance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have been investigating the possible replacement of Kakadu (kdu_compress) with ImageMagick (convert). The developers of our web application agree that removing kdu_compress from the submission workflow would be a positive step, as it would simplify things. However, we would need to keep the Kakadu decoding component because we use IIP image server which does not yet support OpenJPG decoding.
Testing has shown that ImageMagick crashes when trying to convert certain tiff files to jp2 files. I cannot identify anything particular about those tiff files but I have found a fix - set the bit depth to 8, e.g.:
convert -depth 8 input.tiff output.jp2
This could possibly be expanded to something like the following, including minimal 'image data only', as one of the examples at http://www.imagemagick.org/Usage/formats/#BMP suggests, though I'm not sure it's necessary:
convert input.tiff depth 8 ppm: | convert - output.jp2
The resulting image quality is very good.
Currently in our live environment we use the following kdu_compress command line:
./kdu_compress -i input.tif -o output.jp2 -rate 0.5 Clayers=1 Clevels=7 "Cprecincts={256,256},{256,256},{256,256},{128,128},{128,128},{64,64},{64,64},{32,32},{16,16}" "Corder=RPCL" "ORGgen_plt=yes" "ORGtparts=R" "Cblk={64,64}" Cuse_sop=yes
(As an aside, we've found that for particular images, typically those with handwritten text, the output file generated by kdu_compress is of poor quality; replacing that image with one that has less compression resolves this - as one might expect!)
It is interesting to see Kris Bulman's equivalent command line for convert - see this post. However, the current ImageMagick jp2 options page at http://www.imagemagick.org/script/jp2.php suggests that many of the switches employed in Kris's command line no longer exist, and I'm really not sure what are sensible values to use with the current options. Compare with a (presumably older) ImageMagick jp2 options page at this page which lists the options that Kris suggests.
Has anyone else moved over to using convert for the creation of derivative non-archival jp2 files for IIP image streaming/deepzoom? Any tips/experiences you would be willing to share?
Would there be any problems keeping a minimalist command line such as 'convert -depth 8 input.tiff output.jp2'? We're not too worried about file size. Limited testing shows IIP server handles ImageMagick-generated jp2s okay.
Thanks for any replies, and I'm new to a lot of this so please be gentle :)
thanks,
Jim
Hi,
Just for info: we have very positive experiences with kakadu. It's so much faster then imagemagick and very stable. We have a very large number of TIFF's and started our project with Imagemagick but that was troublesome. When switching to kakadu the conversion ran very smooth and lightning fast with zero maintenance.
Hi Edu,
Thank you for sharing that with me; all helpful!
Jim