Questions and postings pertaining to the usage of ImageMagick regardless of the interface. This includes the command-line utilities, as well as the C and C++ APIs. Usage questions are like "How do I use ImageMagick to create drop shadows?".

Here's explanation of the steps, line by line:
// save the embedded profile to local disk
// read in the image to memory
// convert to linear gray space using a local profile
// resize the image
// create sharpened image in gamma 3 ("background" for the upcoming composite)
// create sharpened image ("source" for the upcoming composite)
// delete the original image at index 0
// create blend mask based on the "source" image
// blend background and source using mask (composite)
// convert back to original non-linear gray space using the previously saved profile
// set new resolution in meta-data
// add a comment to meta-data
// write the image to output file

As best I can tell, IM seems to have a problem at the profile conversion step (back to the original non-linear gray space). The error message seems to suggest IM was perhaps in an incompatible color space after the composite. Is IM making some bad colorspace assumptions during the cloning and composite steps? Or am I not understanding how to use "-profile" for the conversions in and out of linear space for grayscale files?

Now here's the interesting part: I modified line two above as follows:

and this eliminates the profile error message. My guess is that the addition of "-type Grayscale" somehow removes the confusion for IM, but I'd like some confirmation that including this is the proper way to fix the error, or if not, some guidance on the proper way to address it.

OK, the following should provide more specific information about where the error is occurring.
In a nutshell, the error occurs on the "-profile embedded.icc" which is converting back to the original non-linear gray space.

And finally, here is "test_magick_writes.bat" which is identical to the first failing script, but I've added "+write tmpX.tif" (X=0,1,2) on the processing steps starting with the last clone in the sequence:

After running the above script, I have files tmp0.tif and tmp1.tif, but not tmp2.tif. It means the error occurs on the "-profile embedded.icc" when cloning and composite are in the processing sequence.

As mentioned in an earlier post, if I add "-type Grayscale" at the beginning of the command, it works. It seems to me the cloning and/or composite is introducing the confusion for IM. Let me know if there is further testing I can do here.

After some further testing, I now see that the problem lies with the cloning, not specifically with the later "-profile".
I added +writes on each of the cloning steps to see what is output from each cloning step. When I look at the first cloned image, IT HAS BEEN CONVERTED TO Colorspace sRGB even though it is still Type Grayscale! Here's what Magick Identify reports on this tmp image:

Colorspace: sRGB
Type: Grayscale
Base type: TrueColor

So it looks like from that point forward in the processing we are in sRGB, but at the end when we try to do "-profile embedded.icc" to get back to non-linear grayspace, IM throws the error, complaining that there is a mis-match in colorspace.

So, my conclusion now is that the defect exists in "-clone". It should NOT do a colorspace conversion to sRGB on a Grayscale input image. What I would expect to see from the cloned image is Colorspace=LinearGray, Type=Grayscale in my case. (I'm not sure why the -clone causes the "TrueColor" base type data to be added).

Note that all tmp images are create, but no output.tif. I even tried stripping the image of all meta data and putting back the original profile. I also tried output as PNG and JPG, but they failed also.

I do not think it is a clone issue, but one having to do with the profiles you are using. Though I am not sure why.

This seems to me to be a bug and needs the IM developers to review comment further.

Fred,
Thanks for your testing and further information. Please see my last post on this thread (before this one) for more information in case you didn't see it.

I still think it is a -clone issue, because when I did a -verbose listing of info from each tmp file that I created on each step I can see that the first -clone does a conversion into sRGB colorpace (and from there the processing apparently stays in sRGB until we hit the "-profile" at the end when the error is thrown. I think -clone is the real source of the problem, not the profiles. If I take out the clone and composite steps, it works just fine, including assigning the original non-linear profile at the end.

datro wrote:I added +writes on each of the cloning steps to see what is output from each cloning step. When I look at the first cloned image, ...

I'm not sure what you mean. Did the "+write" create a file that you then examined? Or did you "+write info:"?

Each write created a differently-named "intermediate" tif file which I then examined with magick identify -verbose. That's how I noticed that on the first clone an unexpected conversion to sRGB was being done.

More info: Based on more testing I've just now completed, I am wondering if using -gamma on the first clone is somehow involved here.
My "tmp2_clone_first.tif" data reveals the conversion to sRGB, but "tmp3_clone_second" (without the -gamma settings) results in the expected Gray colorspace. The third clone also results in Gray, but then the Composite results in sRGB (most likely since one of the two images being composited is sRGB).

As you can see in the verbose output above, everything stays in "...Grayscale Gray..." throughout. (It does seem a bit odd that IM reports the profiles as being "sRGB" but I don't think that is the source of the problem...I suspect it is just an oddity of how -verbose works).

Case 2 (No resize, simple gamma conversion on the first clone)
This also WORKS:

In this case, something has happened on the first clone (with the gamma conversion) output (tmp2). Instead of "Grayscale Gray" being reported, we now see only "Gray". Furthermore, the composite output is now in sRGB!

I wrote a simple script to report selected "magick identify" information from each of the above tmp files and it produces the following:

On tmp2 I see the Colorspace as "sRGB" and the Type as "Grayscale". Something is not right here and it appears this incongruity just carries forward and ultimately convinces the composite to create sRGB output which apparently causes the last "-profile" to barf and IM aborts.

@Alan and Fred: I also tested the above scenarios with "-evaluate pow .." as you suggested; NO CHANGE. Same results whether the clone is using -gamma or -evaluate pow.

For me, the data above demonstrates there is some weird interaction going on between the resize and the clone with a gamma (or eavluate pow) conversion, and this results in incorrect colorspace behavior downstream in the processing. Where do we go from here?