Search found 103 matches
- 2011-08-31T17:25:30-07:00
- Forum: Developers
- Topic: MIFF format for grayscale images?
- Replies: 2
- Views: 8062
MIFF format for grayscale images?
The MIFF documentation does not say how grayscale images are formatted, but IM can successfully write and read them. By experimentation, I see that, for various color types, the samples in a scanline have the following arrangements: RGB: RGBRGBRGBRGBRGBRGBRGBRGB Gray: gggggggg0000000000000000 RGBA: ...
- 2011-08-12T19:57:33-07:00
- Forum: Bugs
- Topic: [Windows] Can not open/read files with non-asci filenames
- Replies: 10
- Views: 24273
Re: [Windows] Can not open/read files with non-asci filename
@Jason, Magick, what do you think? What I think is that I'm not qualified to figure out what problems this might cause. I don't know enough about how IM handles character encodings, or about all the different platforms and configurations that need to be reviewed. But I went ahead and tried it. Befo...
- 2011-08-10T08:39:07-07:00
- Forum: Bugs
- Topic: [Windows] Can not open/read files with non-asci filenames
- Replies: 10
- Views: 24273
Re: [Windows] Can not open/read files with non-asci filename
Was it really possible to open files (standalone identify and convert) with unicode filename under windows? No; not by using 'convert' or 'identify', anyway. If you wrote your own program that calls OpenMagickStream() directly, then you could have done it by encoding the filename in UTF-8. The patc...
- 2011-08-09T19:08:52-07:00
- Forum: Bugs
- Topic: [Windows] Can not open/read files with non-asci filenames
- Replies: 10
- Views: 24273
Re: [Windows] Can not open/read files with non-asci filename
This change just seems like a bad idea to me. Having a function like OpenMagickStream() support Unicode filenames is a good thing, and you've broken that. I would either 1) Implement wmain() instead of main(), and convert the (UTF-16) command-line parameters to UTF-8 using WideCharToMultiByte(CP_UTF...
- 2011-07-21T07:36:59-07:00
- Forum: Digital Image Processing
- Topic: Image resizing with LCD sub-pixel awareness (aka ClearType)
- Replies: 18
- Views: 80795
Re: Image resizing with LCD sub-pixel awareness (aka ClearTy
Here's my writeup about a simple form of subpixel-aware resizing. It may not be the best you can do, but it was surprisingly easy to implement the "offset" feature that makes it possible.
- 2011-04-19T16:02:53-07:00
- Forum: Developers
- Topic: Compiling ImageMagick (64 bit libraries?)
- Replies: 3
- Views: 16257
Re: Compiling ImageMagick (64 bit libraries?)
I don't fully understand what "--enable-delegate-build" does. As far as I can tell, it looks in special subdirectories such as "png" for library and header files. But simply installing libpng into the "png" subdir didn't work, apparently because IM didn't like the direc...
- 2011-03-25T15:09:48-07:00
- Forum: Bugs
- Topic: DICOM RLE bug causes 4 images in one
- Replies: 13
- Views: 32470
Re: DICOM RLE bug causes 4 images in one
I have no opinion about how far the ImageMagick team should go toward support for uncommon DICOM formats like this. But I respectfully disagree that IM is behaving correctly. Transfer Syntax UID "1.2.840.10008.1.2.5" means the image uses RLE compression. Referring to the documentation at h...
- 2011-03-24T20:56:40-07:00
- Forum: Bugs
- Topic: DICOM RLE bug causes 4 images in one
- Replies: 13
- Views: 32470
Re: DICOM RLE bug causes 4 images in one
I can guess what IM is doing wrong. Say there are N pixels in the image. It's interpreting the uncompressed data as N 16-bit integers. The correct interpretation is N 8-bit integers (the MSBs) and then N more 8-bit integers (the LSBs). I don't know what it would take to change it. As for the endian ...
- 2011-03-24T16:32:04-07:00
- Forum: Bugs
- Topic: DICOM RLE bug causes 4 images in one
- Replies: 13
- Views: 32470
Re: DICOM RLE bug causes 4 images in one
I'm pretty sure your DICOM file is bad. It has the least-significant bytes in the first RLE segment, and the most-significant bytes in the second. That's backward. The most-significant bytes always go in the first segment, regardless of the endianness of the file. In other words, the "Sante, an...
- 2011-03-03T14:46:59-07:00
- Forum: Developers
- Topic: Imagemagick 6.5.4 static compile
- Replies: 6
- Views: 18889
Re: Imagemagick 6.5.4 static compile
By design, --disable-shared disables the creation of shared libraries, not the use of shared libraries. I'm not an autoconf/libtool expert, so take that into account. If you really want to statically link everything, including libc, the logical thing to try would be LDFLAGS="-static" ./con...
- 2011-01-17T10:08:14-07:00
- Forum: Bugs
- Topic: PNG 16-bit RGB binary transparency ignored
- Replies: 0
- Views: 4749
PNG 16-bit RGB binary transparency ignored
IM 6.6.7-1 does not seem to support reading bitdepth=16 RGB PNG images with binary transparency. Running such an image through "convert" with no parameters (for example) causes the transparency to be removed. An example of such an image is here . I tested PNG images with all 15 combination...
- 2011-01-05T20:01:38-07:00
- Forum: Users
- Topic: DICOM Multiframe to png or avi
- Replies: 5
- Views: 14991
Re: DICOM Multiframe to png or avi
The 1.dcm file seems to have been truncated around the 230th frame.
With a recent version of ImageMagick, I wasn't able to read any images from it. I tried an older version (6.5.4), and it converted 229 images before reporting the error.
With a recent version of ImageMagick, I wasn't able to read any images from it. I tried an older version (6.5.4), and it converted 229 images before reporting the error.
- 2010-12-28T18:54:27-07:00
- Forum: Bugs
- Topic: Black pixels in some PNG images become transparent
- Replies: 8
- Views: 19750
Black pixels in some PNG images become transparent
Start with an 8-bit RGBA PNG image in which all the pixels are fully opaque, and all the pixels are shades of gray, some of which are black. Run it through 'convert': convert in.png out.png My result: The output image is an 8-bit grayscale image with no alpha channel, and with a 'tRNS' chunk that ma...