Page 1 of 1
bug in composite -displace IM 6.5.2-7
Posted: 2009-05-20T16:47:57-07:00
by fmw42
IM 6.5.2-7 Q16 Mac OSX Tiger
Something has changed in composite -displace and all my scripts now need the arguments negated. I think this was in response to Rick Mabry email yesterday. But in my opinion, the code was fine before, it was the documentation that was in error on the options page.
Anthony please verify your examples and confirm my opinion.
Re: bug in composite -displace IM 6.5.2-7
Posted: 2009-05-20T17:42:16-07:00
by fmw42
OK, before any of us jump to conclusions and make changes, myself include, give me a few minutes to make a simple example as I believe that the documentation can be used to make the argument either. It depends upon whether one wants to talk about the displacement arguments as to how it affects the input image or how the code uses the offsets to retrieve pixels from the input image relative to the reference coordinates in the output. Note that this is an inverse transformation. It sequences through the output (i,j), finds the offset, retrieves that pixel in the input and places it at that (i,j) in the input.
So give me a few minutes to make a simple example from a gradient for further discussion.
I will report back in a few minutes.
Fred
Re: bug in composite -displace IM 6.5.2-7
Posted: 2009-05-20T18:14:22-07:00
by fmw42
OK, I am likely wrong about any changes to composite displace. The changes are somewhere else as my spherize scripts that use composite displace are all working backwards, but my cylinderize and bump scripts are working fine and unchanged. After a bit closer inspection, the component displacement images for my spherize seem to have mirrored, since my testing yesterday. So I need to look further to figure out what has changed.
My apologies for jumping to conclusions.
Nevertheless for education, here is a simple test of composite displace to help clarify what is happening and how it should be explained in the documents.
displacement image -- a gradient:
image to displace -- zelda
composite -displace 50x0 grad128.png grad128.png grad128.png grad128_d50_new_zelda.png
image to displace -- gradient
composite -displace 50x0 grad128.png grad128.png grad128.png grad128_d50_new.png
Thus dark represent a negative offset in the code, but a positive shift of the input data. Similarly, white represents a positive offset in the code, but a negative shift of the input data.
So again it depends upon how you want to describe the arguments to composite -displace. Are they to be shifts of input data or the offsets applied to the output pixel to get the location in the input image?
Re: bug in composite -displace IM 6.5.2-7
Posted: 2009-05-20T19:10:34-07:00
by fmw42
OK, I found what had changed and have fixed it in my spherize scripts.
Seems like in previous versions of IM, this worked to negate the first image before blending (to avoid writing to another image):
composite -blend 50% $tmp1a -negate $tmp1b ...
but in the current version it does not and I need to do the following (which adds the overhead of another image write):
convert $tmp1a -negate $tmp1a
composite -blend 50% $tmp1a $tmp1b ...
I see that the changelog still shows only up to IM 6.5.2-4. Could someone update it to show what has changed in IM 6.5.2-5,6,7
Thanks and again sorry for the false alarm regarding composite -displace
Re: bug in composite -displace IM 6.5.2-7
Posted: 2009-05-21T20:02:44-07:00
by anthony
Add some parenthesis with the -negate.
composite \( $tmp1a -negate \) $tmp1b -blend 50% ...
I also noticed a similar problem. But then composite is a simple command that really is only designed to do one task. Basically it has the same problems as the IM v5 convert command.
If I can get arguments into composition, then displace, dissolve and blend will also be directly usable from "convert", as they stand. Of course I would prefer to make -displace more like -distort, than have it as a -compose option
EG: -compose blend,50% -composite
The only reason I have not done this is I have not figured out how to 'save' the arguments internally for later use by -composite operator. That is adding it correctly to the -geometry argument save, without breaking anything.
Re: bug in composite -displace IM 6.5.2-7
Posted: 2009-05-21T20:27:13-07:00
by fmw42
anthony wrote:Add some parenthesis with the -negate.
composite \( $tmp1a -negate \) $tmp1b -blend 50% ...
Yep, that works.
But raises a new questions about the syntax above.
Should one specify the input images before -blend 50% or -blend 50% before the input images? What is the proper syntax for composite -blend and composite -dissolve. Perhaps both work, but what is the correct syntax for IM 6
Your example pages (
http://www.imagemagick.org/Usage/compose/#blend) show you using it the other way
composite -blend 50% image1 image2 ...
rather than
composite image1 image2 ... -blend 50%
anthony wrote:The only reason I have not done this is I have not figured out how to 'save' the arguments internally for later use by -composite operator. That is adding it correctly to the -geometry argument save, without breaking anything.
I understand and it is not urgent on my part, but sounds like a good idea at some point.
Re: bug in composite -displace IM 6.5.2-7
Posted: 2009-05-21T20:34:18-07:00
by anthony
As mentioned composite is not really following the normal IMv6 conventions, and still using code basied on IMv5. Especially as it is slowly being incorporated into "convert" which has very specific option and operation ordering.
Re: bug in composite -displace IM 6.5.2-7
Posted: 2009-05-21T20:57:58-07:00
by fmw42
anthony wrote:As mentioned composite is not really following the normal IMv6 conventions, and still using code basied on IMv5. Especially as it is slowly being incorporated into "convert" which has very specific option and operation ordering.
So what then is the correct ordering?