Page 1 of 1
Bad TIFF?
Posted: 2007-08-29T08:31:46-07:00
by johnkarp
I'm trying to look at the full output of GOES weather satellites, presented in TIFF format, for example:
http://goes.gsfc.nasa.gov/goeseast/full ... G12I01.tif (74 MB)
The problem is that every image I look at is cut off; the bottom of every image is black. Since these files are unusually large (14400x12001) I wouldn't be surprised to see bugs popping up.
Can someone tell me whether these images are broken, or if its a ImageMagick/libtiff bug?
Re: Bad TIFF?
Posted: 2007-08-29T09:44:32-07:00
by el_supremo
I downloaded the image, viewed the original with PSP X and then used ImageMagick 6.3.5 to resize it down to 10% of its original size with no problems.
Pete
Re: Bad TIFF?
Posted: 2007-08-29T09:48:11-07:00
by magick
We resized and displayed the TIFF image without any problems. We're using ImageMagick 6.3.5-6.
Re: Bad TIFF?
Posted: 2007-08-29T11:00:48-07:00
by johnkarp
I'm using 6.3.5-6.
In particular:
Code: Select all
convert 0708281445G12I01.tif -resize 640x640 foo.png
produces an image where the bottom 3/4ths is blackened out.
The file opens properly in the gimp (although it takes a while).
Re: Bad TIFF?
Posted: 2007-08-29T18:12:09-07:00
by magick
You could be running out of temporary space. Set the MAGICK_TMPDIR environment variable to a path that has several gigabytes of free space. Also add -limit area 1 to your command line to force the conversion to disk rather than anonymous memory mapped I/O.
Re: Bad TIFF?
Posted: 2007-08-30T10:46:40-07:00
by johnkarp
Okay, that fixes it. Thank you.
(Shouldn't ImageMagick complain if it is forced to lose image data due to a memory shortage? Failing silently is bad behavior, IMO)
Re: Bad TIFF?
Posted: 2007-08-30T11:22:39-07:00
by magick
What OS are you using? When a memory map request fails, the system should generate a SIGBUS signal. It does for us under Fedora Core Linux.
Re: Bad TIFF?
Posted: 2007-08-30T13:54:28-07:00
by johnkarp
Gentoo.
Linux bouzouki 2.6.20.6 #1 Mon Apr 9 17:05:50 CDT 2007 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
gcc 4.1.2
glibc 2.5
Code: Select all
convert 0708281445G12I01.png -trim 0708281445G12I01.trim.png
gets a sigbus. valgrind output:
Code: Select all
==8224== Warning: set address range perms: large range 1030586368 (defined)
==8224==
==8224== Process terminating with default action of signal 7 (SIGBUS)
==8224== Non-existent physical address at address 0x73FC7FFF
==8224== at 0x4023347: memcpy (mc_replace_strmem.c:406)
==8224== by 0x41055BA: CopyMagickMemory (in /usr/lib/libMagick.so.10.0.8)
==8224== by 0x40697F1: ClonePixelCache (in /usr/lib/libMagick.so.10.0.8)
==8224== by 0x406C99B: SetCacheNexus (in /usr/lib/libMagick.so.10.0.8)
==8224== by 0x406CBF0: SetPixelCache (in /usr/lib/libMagick.so.10.0.8)
==8224== by 0x4064AD2: SetImagePixels (in /usr/lib/libMagick.so.10.0.8)
==8224== by 0x40F2E52: CloneImage (in /usr/lib/libMagick.so.10.0.8)
==8224== by 0x415F06E: CropImage (in /usr/lib/libMagick.so.10.0.8)
==8224== by 0x415F5A5: TrimImage (in /usr/lib/libMagick.so.10.0.8)
==8224== by 0x42AAEB2: MogrifyImage (in /usr/lib/libWand.so.10.0.8)
==8224== by 0x42AB732: MogrifyImages (in /usr/lib/libWand.so.10.0.8)
==8224== by 0x425AF07: ConvertImageCommand (in /usr/lib/libWand.so.10.0.8)
There is apparently no signal handler set for SIGBUS. Which is better than silent failure, but I think it would be best if the signal were caught and an actual error message printed.