Possible Magic++ bug

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
Myrsloik
Posts: 7
Joined: 2015-01-13T16:23:29-07:00
Authentication code: 6789

Possible Magic++ bug

Post by Myrsloik » 2017-12-30T12:20:47-07:00

In magick++/lib/image.cpp

The depth method most likely incorrectly limits the max depth that can be set to MAGICKCORE_QUANTUM_DEPTH. Neither the c api or magic wand api does this. Likewise the Magick::Image::modulusDepth method doesn't limit it either. Most likely the correct solution is to remove the clamping of the depth value here.

Code: Select all

void Magick::Image::depth(const size_t depth_)
{
  size_t
    depth = depth_;

  if (depth > MAGICKCORE_QUANTUM_DEPTH)
    depth=MAGICKCORE_QUANTUM_DEPTH;

  modifyImage();
  image()->depth=depth;
  options()->depth(depth);
}

snibgo
Posts: 9618
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Possible Magic++ bug

Post by snibgo » 2017-12-30T12:31:30-07:00

But if, or example, MAGICKCORE_QUANTUM_DEPTH is 16, what do you expect setting depth to 32 to do? It can't fill out those extra bits, because it has been compiled to store pixel value in only 16 bits.
snibgo's IM pages: im.snibgo.com

Myrsloik
Posts: 7
Joined: 2015-01-13T16:23:29-07:00
Authentication code: 6789

Re: Possible Magic++ bug

Post by Myrsloik » 2017-12-30T12:43:48-07:00

This is mostly useful for Q16 HDRI builds where the storage type is float. By changing this you can then write 32bit float tiff files without issues. At least none that I found in my very limited testing.

User avatar
fmw42
Posts: 22484
Joined: 2007-07-02T17:14:51-07:00
Location: Sunnyvale, California, USA

Re: Possible Magic++ bug

Post by fmw42 » 2017-12-30T12:58:01-07:00

To write 32-bit tiff files in Q16 HDRI, one needs to specify -define quantum:format=floating-point (in command line mode). I do not know how one does that in any API. See TIFF at http://www.imagemagick.org/script/formats.php. Other formats that support floats and negative values are: PFM, MPC and MIFF (the latter also needs the define).

If you are in Q16 HDRI compile and do not want values to exceed 16 bits, then use -clamp equivalent in your API.

If you do -compose ... -composite equivalents and do not want them automatically clamped, then use -define clamp=off equivalent.

User avatar
dlemstra
Posts: 1412
Joined: 2013-05-04T15:28:54-07:00
Authentication code: 6789
Contact:

Re: Possible Magic++ bug

Post by dlemstra » 2017-12-31T08:06:47-07:00

I just pushed a patch to remove the restriction. This will be removed in the next release.
.NET + ImageMagick = Magick.NET https://github.com/dlemstra/Magick.NET, @MagickNET, Donate

Myrsloik
Posts: 7
Joined: 2015-01-13T16:23:29-07:00
Authentication code: 6789

Re: Possible Magic++ bug

Post by Myrsloik » 2018-01-06T15:49:05-07:00

I have one more question about the quantum:format=floating-point image attribute. Why isn't it always set when the source file is a floating point format? For example EXR images can contain it as well but it will never be set for them (I checked the source code and tried). Is this an oversight or an intentional decision for some reason?

User avatar
fmw42
Posts: 22484
Joined: 2007-07-02T17:14:51-07:00
Location: Sunnyvale, California, USA

Re: Possible Magic++ bug

Post by fmw42 » 2018-01-06T16:30:25-07:00

I do not know for sure, but for TIFF, IM uses libtiff and that may be its default situation. Or it may just be as follows for MIFF.

I am not sure for MIFF, why that was done, except that HDRI used not to be the default compile in IM 6. So it was probably not set to do that.

If you use MPC or PFM, they will automatically use floating point values for HDRI compiles for those output formats.

Post Reply