Legacy ImageMagick Discussions Archive

IM 6.7.0.8 Q16 Mac OSX tiger

I am getting a black result for a rotation at 105 degrees. Other 15 degree increment works fine from 0 to 360.

input:


This fails:
convert port.jpg -virtual-pixel black +distort SRT 105 +repage port_rot105.jpg



This works:
convert port.jpg -virtual-pixel black +distort SRT 100 +repage port_rot100.jpg

The 105 angle works perfectly fine for me when I copied the command and image then ran it!

What does the verbose output list? This is what i get... PS: the v.page.y on the last FX line was a minor bug fix in the verbose output I made a couple of days ago, it does not effect the actual result.

convert -verbose port.jpg -virtual-pixel black +distort SRT 104 +repage port_rot105.jpg

First, your command above used 104 degrees not 105. But running it with 105, I get the following which still produces a black image.


convert -verbose port.jpg -virtual-pixel black +distort SRT 105 +repage port_rot105.jpg
port.jpg JPEG 400x250 400x250+0+0 8-bit DirectClass 11.9KB 0.010u 0:00.089
Affine Projection:
-distort AffineProjection \
'-0.258819,0.965926,-0.965926,-0.258819,372.504537,-35.832785'
Affine Distort, FX Equivelent:
-size 348x454 -page +26-102 xc: +insert \
-fx 'ii=i+page.x+0.5; jj=j+page.y+0.5;
xx=-0.258819*ii +0.965926*jj +131.023081;
yy=-0.965926*ii -0.258819*jj +350.537546;
v.p{ xx-v.page.x-.5, yy-v.page.x-.5 }' \
port.jpg=>port_rot105.jpg JPEG 400x250=>348x454 8-bit Bilevel DirectClass 0.130u 0:00.210


On the other hand, using 104 runs perfectly fine!.


convert -verbose port.jpg -virtual-pixel black +distort SRT 104 +repage port_rot104.jpg
port.jpg JPEG 400x250 400x250+0+0 8-bit DirectClass 11.9KB 0.010u 0:00.019
Affine Projection:
-distort AffineProjection \
'-0.241922,0.970296,-0.970296,-0.241922,369.671345,-38.818908'
Affine Distort, FX Equivelent:
-size 342x450 -page +29-100 xc: +insert \
-fx 'ii=i+page.x+0.5; jj=j+page.y+0.5;
xx=-0.241922*ii +0.970296*jj +127.097413;
yy=-0.970296*ii -0.241922*jj +349.299382;
v.p{ xx-v.page.x-.5, yy-v.page.x-.5 }' \
port.jpg=>port_rot104.jpg JPEG 400x250=>342x450 8-bit DirectClass 16.4KB 0.530u 0:00.699

NOTE the bilevel and DirectClass for the type in the 105 case, but only DirectClass for the 104 case!

fmw42 wrote:

convert -verbose port.jpg -virtual-pixel black +distort SRT 104 +repage port_rot105.jpg

First, your command above used 104 degrees not 105. But running it with 105, I get the following which still produces a black image.

Sorry, I did try the 105 and then decided to try a few others to look around. At no time did I get a blank image result.
I have fixed the original report, (which does work).

However it is strange that the result is black (which is the cause of the 'bilevel' image output -- that is not a problem)
You do get black for PNG images too, That will let us determine if it is a distort SRT vs a JPEG coder issue.

All the coefficients are however correct, so I have no idea why it should be different.

Try using the coefficients directly... EG:
convert port.jpg -virtual-pixel black +distort AffineProjection \
'-0.258819,0.965926,-0.965926,-0.258819,372.504537,-35.832785' text.jpg

Also try it with -distort (both SRT and AffineProjection)
also does it happen for other -virtual-pixel settings?
What if you use -filter point.

I am basically fishing to find out what component of the distortion and resampling is failing.

Also check that IM is completely up to date, and libraries match. (using ldd /usr/bin/convert )
Check date of the referenced libMagickCore file.

Note my edited comments above about type Bilevel in 105 case.

It works for 105.001 but fails for 104.999. However, It works for both 105.01 and 104.99

See my comments above about type bilevel above (though that may be a result of the black issue and not the cause).

It also fails for -distort SRT 105

it fails for 105 if saved as jpg, png or miff

Okay it is not the coder. So look at the other suggestions I made (re-read)
Remember I can't duplicate the failure.

anthony wrote:Okay it is not the coder. So look at the other suggestions I made (re-read)
Remember I can't duplicate the failure.

My system has no ldd

I get black for -virtual-pixel black, white, edge.

Using AffineProject works fine.

convert port.jpg -virtual-pixel black +distort AffineProjection \
'-0.258819,0.965926,-0.965926,-0.258819,372.504537,-35.832785' \
test1.jpg

-filter point works fine with SRT

convert -verbose port.jpg -virtual-pixel black -filter point +distort SRT 105 +repage port_rot105point.jpg

But -filter triangle and -filter lanczos give a black result for SRT. However, they work fine for AffineProjection

fmw42 wrote:My system has no ldd

Must be something to see what shared libraries the command is using.

I get black for -virtual-pixel black, white, edge.
...
But -filter triangle and -filter lanczos give a black result.

Okay the problem is not the virtual pixel, BUT as it is always black, the results of resampling is zero.

-filter point works fine with SRT

So it is the EWA resampler. that makes it much more difficult, as it is a much lower level.

Try using -filter BOX (result may not look pretty if it succeeds.
then try adding -define filter:support=1.0 then try 2.0 etc.

This this is failing then we would need to get much more serious and enable some debugging code!

The only thing I can think of is that something about your floating point processing is either failing, or hitting a very very specific combination of values that causes a problem.

To debug that I would be restricting the output to a single pixel viewport, (to limit debug case to one lookup) and then enable code to print internal values of the sampling ellipse, and the sampling of the source image that is going on. And that is going to be real painful.

You up for it?

Try using -filter BOX

-filter box fails with black image

convert -verbose port.jpg -virtual-pixel black -filter box +distort SRT 105 +repage port_rot105box.jpg

Before going further, perhaps we should have Magick try on his Mac (though his is Intel Snow Leopard and mine is PowerPC Tiger). But it won't hurt to try if he does not mind, though it likely will work for him. Do you want to ask him or should I.

The only thing I can think of is that something about your floating point processing is either failing, or hitting a very very specific combination of values that causes a problem.

Probably right.

Go for it. It is a very specific problem.

The image converts fine on our Intel Mac with the latest MacOS X release. We also tried under Windows and Fedora Linux and got expected results.

Thanks for testing. I expect this is something in my old PowerPC Mac Mini with OSX Tiger for just some funny combination of values. So no point in going any further for you or Anthony. I hope later this summer to switch to the new INTEL Mac Mini.