Legacy ImageMagick Discussions Archive

If you are aware what kernel options are responsible for floating point calculations I could check my kernel for them

We tried quantum depths of 8, 16,32, and 64 and both your images converted properly without artifacts. DICOM uses floating point extensively. Perhaps there is a problem in the floating point conversion. May be, I don`t know. :? At least now I can convert dicoms without artifacts using quantum depth ...

We have an AMD dual processor (AMD Opteron Processor 844) and it produces the expected results. We're using gcc 4.6.1. We still have no idea why it fails for you. You are absolutely correct,it's not the processor! I forgot that i compiled imagemagic on intel machine with different options of ...

rnbc wrote:Try executing under qemu with your OS of choice. That way others will be able to exactly reproduce your environment, even if you have to post the qemu image...

Good idea
Thank you!

Well i think now that this problem is processor related. On my intell machine everything is fine and correctly rendered! Here are the details: cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU T6600 @ 2.20GHz stepping : 10 cpu MHz ...

Here is the debug output with dynamic linking : convert -debug module -define dcm:display-range=reset GEORGIEV_EMILIYAN.DCM -define png:color-type=4 -quality 100 -define png:compression-level=9 GEORGIEV_EMILIYAN.DCM1.png zsh: correct 'GEORGIEV_EMILIYAN.DCM1.png' to 'GEORGIEV_EMILIYAN.DCM.png' [nyae ...

No, the video driver doesn't matter. We tried your image under Windows and Mac with 6.7.3-0 and it converted properly. Check that 'ls -lt /usr/lib64/libMagickCore.so.5' reports today as the create date. Yes it's from today: ls -lt /usr/lib64/libMagickCore.so.5 lrwxrwxrwx 1 root root 22 окт 10 02:12 ...

We tried your compiler flags and still get expected results from the command you posted. We're clueless why its failing for you. Try ldd /usr/local/bin/convert and make sure the convert program is picking up the correct libMagickCore.so library. Note, ImageMagick 6.7.3-0 is now available. No change ...

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 ...

magick wrote:We're using ImageMagick 6.7.2-10 and we get the correct results when converting your DICOM image.

Strange!

Can you tell me please:

1.What command line options do you use for the conversion?
2.Which dependencies of imagemagick can cause such artifacts into the image ?

Thank you!

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. This is how this image should look like: https://picasaweb.google.com ...

Disabling HDRI does not make any difference also

The new version makes no difference at all

Using :

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 ...

Upgrade to ImageMagick 6.7.2-9. It includes a DICOM patch that fixes the problem you reported. 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 ...