Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".
I would say there is a overflow bug somewhere in the pipeline...
Maybe you can avoid it by using the HDRI enabled version of ImageMagick (involves a recompile) since it uses floating point and allows whiter than white colors.
rnbc wrote:I would say there is a overflow bug somewhere in the pipeline...
Maybe you can avoid it by using the HDRI enabled version of ImageMagick (involves a recompile) since it uses floating point and allows whiter than white colors.
Thank you for the response!
But my imagemagick is already compiled with enabled hdri option :
media-gfx/imagemagick-6.7.2.6 was built with the following:
USE="X autotrace bzip2 corefonts cxx djvu fftw fontconfig fpx graphviz gs hdri jbig jpeg jpeg2k lcms lqr lzma (multilib) openexr openmp perl png q32 q64 q8 raw svg tiff truetype webp wmf xml zlib -opencl -static-libs"
I really want to use imagemagick for this kind of a job. It's powerful, quick, easy to use, well documented and offers great support and community.
I just can't figure this out alone
magick wrote:Upgrade to ImageMagick 6.7.2-9. It includes a DICOM patch that fixes the problem you reported.
fmw42 wrote:
I am using IM 6.7.2.9 Q16, but not HDRI, on Mac OSX tiger.
Have you tried converting to TIFF or some other format besides PNG to see if it is a PNG problem?
Have you upgraded your libpng?
I'll wait for few days till IM 6.7.2.9 comes to my distro and I'll report back here.
I tried other formats but the output is the same, my hopes are concentrated on the new IM version
fmw42 wrote:I know very little about DICOM files. The one app (GraphicConverter) that could view your source image showed a lot of noise and was inverted.
Several tools such as Photoshop and GIMP could not open it and a couple, such as GIMP, gave messages about not able to handle 4096 bpp data.
Don't even start with that!
I hate dicom files in the guts This format is for medical CAT scans, MRI scans, medical 3d imaging etc. http://en.wikipedia.org/wiki/Dicom
Making simple dental images (2d, grayscale image) as dicom is like killing a fly with a hydrogen bomb.
PNG or TIFF could be sufficient. And on top of that each hardware/software manufacturer makes different dicoms (there is no guarantee that you'll be able to open it with different software), for example Kodak produces *. rvg dicom files
Post a URL to a rendering of your image in the PNG or JPEG format so we can compare what you think is the correct rendering to what ImageMagick produces. That will help us identify any bugs in the ImageMagick DICOM coder.
magick wrote:Post a URL to a rendering of your image in the PNG or JPEG format so we can compare what you think is the correct rendering to what ImageMagick produces. That will help us identify any bugs in the ImageMagick DICOM coder.
Make sure you are running the proper version of ImageMagick. The behavior your describe is what is expected to versions of ImageMagick prior to a recent patch we applied to fix the problem you posted. The conversion command was simple: convert image.dcm image.png. The DICOM coder does not rely on any dependencies. ImageMagick 6.3.0 will be released within a day or two if you want to try it but it should not be necessary ImageMagick 6.7.2-10 works for us.
magick wrote:Make sure you are running the proper version of ImageMagick. The behavior your describe is what is expected to versions of ImageMagick prior to a recent patch we applied to fix the problem you posted. The conversion command was simple: convert image.dcm image.png. The DICOM coder does not rely on any dependencies. ImageMagick 6.3.0 will be released within a day or two if you want to try it but it should not be necessary ImageMagick 6.7.2-10 works for us.
I'm sorry but the 6.7.2-10 version does not change anything for me