Legacy ImageMagick Discussions Archive

fmw42 wrote:Neither can I and the fact that they don't seem to give the same results raises questions about what composite displace is really doing.

I know for a fact what composite is doing and it is exactly as described in IM Example pages.

Code: Select all

  convert label.jpg  displace_map.jpg  -virtual-pixel Gray \
          -fx 'dy=10*(2v-1); p{i,j+dy}'   displaced.jpg

OR

Code: Select all

   convert label.jpg  displace_map.jpg  -virtual-pixel Gray \
          -fx 'dy=10*(2v-1); p[0,dy]'   displaced.jpg

Where '10' is the displacement vector. Comes out correct, and that is exactly what is happening in the library.

Could your -displacement vector be the wrong value? I can't see how an 'amp' of 40 relates between the DIY distortion example and your displacment mapping example! I think $amp would be directly related to the $xc value (which you use in your absolute distortion) and not to the radius of 40 (which you use in displacement map). That looks like where it is going wrong!

Add a amp=$xc and try again!

I will check this tomorrow.

That does not work either. Pretty much as before and not close.

Using fx:

Using amp=xc in compare displace

Actually it looks worse than before. But I definatally think it is the 'amp' size that is the problem.

Check for pixel 0,0 what -fx is looking up, and what the displace would look up.

I think the issue may be how composite displace sets the value to use from its argument. Is is an absolute amount in pixels are is it a percentage of the image size?

In the cylinder fx example, the argument of the arcsin ranges from -1 to +1 and when multiplied by xc=half width, this makes it range from the left side of the input to the right side of the input.

With composite displace, what happens with an argument of 100 using the arcsin scaled between range 0 and 1. Is this equivalent to the left and right sides of the input?

Here is a new test using a hybrid method.

Common Code:
radius=40
width=`identify -format %w $tmpA`
height=`identify -format %h $tmpA`
xc=`echo "scale=1; ($width - 1) / 2" | bc`
ipid2=`echo "scale=6; 1/(2*a(1))" | bc -l`
ffx="ffx=$ipid2*asin(xd);"

Method 1) pure fx
convert -monitor $tmpA -virtual-pixel $vp -fx \
"xd=(i-$xc)/$radius; $ffx xs=$xc*ffx+$xc; u.p{xs,j}" \
$outfile

Method 2) compare displace
convert -monitor -size ${width}x1 xc: -virtual-pixel $vp -fx \
"xd=(i-$xc)/$radius; $ffx xs=0.5*ffx+0.5; xd>1?1:xs" \
-scale ${width}x${height}! \
$tmp0

composite $tmp0 $infile -virtual-pixel black -displace ${amp}x0 $outfile

amp=100

amp=xc=74

amp=40

Method 3) hybrid -- compute same $tmp0 as used above but use it with fx
convert -monitor -size ${width}x1 xc: -virtual-pixel $vp -fx \
"xd=(i-$xc)/$radius; $ffx xs=0.5*ffx+0.5; xd>1?1:xs" \
-scale ${width}x${height}! \
$tmp0

convert $tmpA $tmp0 -monitor -virtual-pixel $vp -fx \
"xs=$xc*2*(v-0.5)+$xc; v==0||v==1?black:u.p{xs,j}" \
$outfile

This result is the same as from Method 1)
So the only oddball is Method 2) using composite displace

So still a puzzle. Anthony, see my previous post for particular questions.

Anthony, please help me understand this simple test of composite displace.

create gradient for displacement image:
convert -size 128x128 gradient: -rotate 90 grad128h.png

same size test image: mandril.png

composite grad128h.png mandril.png -virtual-pixel black -displace ${amp}x0 mandril_tmp_a${amp}.png

amp=10

Measuring the left edge of the mandril texture, it is shifted in to x=9, so close to 10 pixel shift (but not exact)

amp=50

Measuring the left edge of the mandril texture, it is shifted in to x=28, so not close to 50 pixel shift

amp=100

Measuring the left edge of the mandril texture, it is shifted in to x=39, so not close to 100 pixel shift, but as the image is only 128 wide, I am not sure what to expect.

I am really puzzled about the algorithm used by composite displace and how it scales values from the displacement image. I looked at the code, but cannot make too much sense of it. It looks more or less straightforward. But it has some scale factors called rho and sigma, but I suspect those are just the x and y displacement arguments.

Main code seems to be here:

horizontal_scale=geometry_info.rho;
vertical_scale=geometry_info.sigma;

and here
x_displace=(horizontal_scale*(p->red -
(((MagickRealType) QuantumRange+1.0)/2.0)))/
(((MagickRealType) QuantumRange+1.0)/2.0);
y_displace=(vertical_scale*(p->green -
(((MagickRealType) QuantumRange+1.0)/2.0)))/
(((MagickRealType) QuantumRange+1.0)/2.0);
(void) ResamplePixelColor(resample_filter,(double)
(x_offset+x+x_displace),(double) (y_offset+y+y_displace),&pixel);

I am not sure what x_offset and y_offset are?

Also, see other new posts above.

[quote="fmw42"]Measuring the left edge of the mandril texture, it is shifted in to x=9, so close to 10 pixel shift (but not exact)/quote]

The left edge of the mandrill in the resulting does not correspond to a pure black or white color in the displacement map at that location. The color of the displacement map is some what smaller than 100, that is some 2*(gray_value-0.5)*100 => -38 pixel displacement at that location.

AT pixel location 0, the color is pure black, so the color in the resulting image is the virtual pixel at -100

Remember locations in the displacement map corresponds to the generated result, and not to the source image. It is a pain, but that is the way it works.

I have now worked out the issues between the absolute distortion and the relative displacement approaches for the cylinder distortion and have a new script to do such called, cylinderize, at http://www.fmwconcepts.com/imagemagick/index.php

Fred, perhaps you can include the Y displacement as well to give the text the right sort of 'arc' it needs to represent the cylinder.

That is the vertical displacement should actually follow the curve sqrt(1-x^2)
where X goes from -1 to +1 over the width of the cylinder.
Or for a normalized range of 0 to 1 across the cylinder sqrt(1-4*(x-.5)^2)

Of course the Y displacement will need to be multiplied by some fraction such as 0.5 for a isometric view of the cylinder.

That is if the image only contains the cylindical view over its width.
y_displacement = sqrt(1-4*(i/w-.5)^2)*w/4

Also note that ANY input image that is to wrap over half the cylinder, its width will compress by 2/pi or the width will shrink by 0.6366 regardless of its input size.

Anthony wrote:That is the vertical displacement should actually follow the curve sqrt(1-x^2)
where X goes from -1 to +1 over the width of the cylinder.
Or for a normalized range of 0 to 1 across the cylinder sqrt(1-4*(x-.5)^2)

This may seem right and produce something that appears reasonable, but I would have to test and compare. I used something similar as one option in my bump script, but it did not work terribly well. And I still need to add the proper arcsin option to that script.

Your approach may be equivalent to wrapping the image about the cylinder. My approach was to orthographically project the image onto the cylinder. A comparison and possible second option in my script would be interesting. I will look into this over the weekend.

This is probably analogous to the various ways to represent or project an image on a spherical surface. See http://en.wikipedia.org/wiki/Fisheye_lens. You can orthographically project it, or wrap it around or use other approaches.

The orthographic projection of an image onto a cylinder follows from the forward projection. Consider the origin at the axis and zero angle of measurement being the center of the cylinder/image. Then the x coordinate of the orthographic projection of the (vertically oriented) cylinder surface onto a planar (surface) image obeys x-xc=R*sin(angle). Thus the inverse transformation follows the inverse of this equation which is the arcsin function and not sqrt(1-x^2), which is just a (semi-)circle.

I can certainly make another version that uses sqrt(1-x^2) for comparison.

Anthony wrote:That is if the image only contains the cylindical view over its width.
y_displacement = sqrt(1-4*(i/w-.5)^2)*w/4

At this point, I don't follow this equation. Why is the y_displacement a function of i and w and not j and h? Do you mean x_displacement?

All I did was linearly scaled the length of the cylinder using a scaled ramp (gradient) function for the y_displacement. It seemed to work fine.

fmw42 wrote:This may seem right and produce something that appears reasonable, but I would have to test and compare. I used something similar as one option in my bump script, but it did not work terribly well. And I still need to add the proper arcsin option to that script.

Your approach may be equivalent to wrapping the image about the cylinder. My approach was to orthographically project the image onto the cylinder. A comparison and possible second option in my script would be interesting. I will look into this over the weekend.

That is the correct formula for the Y displacement. producing an eliptical (squashed circle) curve. It was the X displacement with compression that needed the arcsin or arccos to work correctly. A Y displacement would only need arcsin/cos if you were doing a reverse mapped spherical distortion.

PS: from the conversation in IM users mail list, a user is using depolar to extract an image from a spherical fish eye image. However a depolar of a spherical image would produce a cylindrical distortion (of a 1/4 cylinder, not the half we are doing here). It may be time I also looked as adding a (de)spherical distortion methods, as well as (de)cylindrical distortion methods to IM.

PS; angle from-to parameters in depolar currently do not match polar, except for the defaults

fmw42 wrote:
Anthony wrote:That is the vertical displacement should actually follow the curve sqrt(1-x^2)
where X goes from -1 to +1 over the width of the cylinder.
Or for a normalized range of 0 to 1 across the cylinder sqrt(1-4*(x-.5)^2)
Consider the origin at the axis and zero angle of measurement being the center of the cylinder/image. Then the x coordinate of the orthographic projection of the (vertically oriented) cylinder surface onto a planar (surface) image obeys x-xc=R*sin(angle). Thus the inverse transformation follows the inverse of this equation which is the arcsin function and not sqrt(1-x^2), which is just a (semi-)circle.

I was looking at Y displacements (based on X position) not the cylindrical distion (image compression) aspect!

anthony wrote:
fmw42 wrote:
Anthony wrote:That is the vertical displacement should actually follow the curve sqrt(1-x^2)
where X goes from -1 to +1 over the width of the cylinder.
Or for a normalized range of 0 to 1 across the cylinder sqrt(1-4*(x-.5)^2)
Consider the origin at the axis and zero angle of measurement being the center of the cylinder/image. Then the x coordinate of the orthographic projection of the (vertically oriented) cylinder surface onto a planar (surface) image obeys x-xc=R*sin(angle). Thus the inverse transformation follows the inverse of this equation which is the arcsin function and not sqrt(1-x^2), which is just a (semi-)circle.
I was looking at Y displacements (based on X position) not the cylindrical distion (image compression) aspect!

Why would you want a non-linear y (length) compression that depends upon x^2 for a vertical cylinder? What effect are you trying to achieve by that?

as y is only dependant on x, all pixels of constant x will have the the same value. thus no compression only displacement!!! It is like -wave just displacing to a circlar curve, rather than to a sine curve!

Legacy ImageMagick Discussions Archive

Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images

Re: Help with composite images