Legacy ImageMagick Discussions Archive

I am using Magick.NET Q8 to work with a variety of images from .NET, and I've noticed that when loading an 8-bit grayscale JPG it reports the ColorType as Palette, with a ColormapSize of 256. To the best of my knowledge, JPEG doesn't support any palette color, and 8-bit grayscale really is stored as ...

Do you have any opinions about which format delegates and compression libraries to build in? I have it working with zlib, libjpeg-turbo, libtiff5, libpng16, and libwebp. Anything else you definitely do (or do not) want to see supported out of the box? LZMA, BZ2, etc? I've also waffled a little about ...

I want to do a little more testing on my end first, but I'll send you a PR soon, hopefully this week.

I have a proof of concept static version of Magick.NET-Q8-x64.Native.dll.so working now on my system. In a nutshell, the Dockerfile for building the base ImageMagick library needed tweaking to let the format delegates build correctly, and then I was able to just add a flag to compile PIC (which ...

Continuing to poke at this, and it seems to all come down to DLL-hell (or, so-hell, I suppose). I have the Magick.NET.Native library loading, but the underlying ImageMagick libraries are still failing with 'ImageMagick.MagickMissingDelegateErrorException: no decode delegate for this image format ...

When loading an image on Linux (Ubuntu 16.04) under .Net Core, I'm getting an exception: Unable to load DLL 'Magick.NET-Q8-x64.Native.dll': The specified module or one of its dependencies could not be found.\n (Exception from HRESULT: 0x8007007E) I am using Q8-AnyCPU 7.3. I see there is a Magick.NET ...

It would be a worthwhile project someday to try and do a faithful port of Exiftool to something more modern (or at least more interop friendly) than Perl 5. Today is probably not the day :) . I've got a working C# Exif copier now. IM/libtiff is stripping a few other non-Exif related tags as well, so ...

We've used exiftool in the past as a workaround, but being Perl based you're stuck with some ugly hacks to make it work reliably in .NET Core. Just to summarize what I've learned since, this is a problem with libtiff rather than ImageMagick. Libtiff (and it's derivatives) is deeply broken when it ...

Well, reading http://www.imagemagick.org/discourse-server/viewtopic.php?t=30518 it sounds like people just gave up on writing Exif to TIFFs with ImageMagick. Unfortunately preserving metadata is a hard requirement for us, so I'll have to look at alternatives. Fingers crossed we can just use LibTiff ...

When saving a TIFF, it seems EXIF data is being scrubbed. Is there a way to prevent this? I've come across some discussions about this with the command line tools that suggested using the "-define exif-properties=true" option, but haven't had any luck with it or the Magick.NET equivalent. It is ...

Another puzzle: For a grayscale JPEG, Magick.NET is reporting a ColorSpace of Gray, and the Channels collection on MagickImage has only a single value (Channel 0), as expected. However, ChannelCount == 2, and if I take GetPixels().ToArray() I get 2 channels worth of image data, with two identical ...

Sure, that's what I'd expect, and I can understand why dlemstra might not want to pack the PixelChannel enum with every possible permutation for every colorspace. I just want to make sure I'm making reasonable assumptions before I hardcode them in.

How about LAB? PixelChannel doesn't seem to cover LAB/YCbCr/etc, but my LAB samples seem to reliably load into channels 0-2 anyway.

Gotcha. So, can I assume then that the underlying byte order will always be fixed for a given ColorSpace? IE, it will always be RGB or RGBA, and never BGR or ARGB, etc? Or is there another lookup to map a Channel index to a position in the byte order?

So, the call to SetPixels() needs to have the bytes in the original channel order? That should be doable, if I can get the order reliably. Looking at the .Channels collection, it seems a little funky. For a grayscale image, it reports a single Cyan channel. For an sRGB it reports Cyan, Green, and ...