Legacy ImageMagick Discussions Archive

Hi.

There's a topic below about dropouts - it has an unhelpful title which is why this is a new topic.

While I've been generating faux lenticular vignetting using the code below; dropouts are appearing in some - not all - output images. All the dropouts seem to be identical; and all are confined to the upper half of the image.
Here are some full-size crops by way of illustration. They're crops from skies beause they're easiest to see. The dropouts all look the same anyhow.






Is this a bug?


Thanks.

Post your input image so others can test with it.

Does it consistently fail on the same image?

Have you tried putting in -write tmpX.png into your statements to capture the intermediate results to see where the problem gets inserted?

Also I am not sure +filter means anything. So perhaps try setting the filter back to something else or its normal default value.

I tried your command on about 8 images in IM 6.7.2.1 Q16 Mac OSX Tiger and it never failed with your dropouts.

The only other thing I can think of is that it might be your libjpeg. Try changing either or both the input and output images to PNG or TIFF or BMP and see if you get the same dropouts. If you don't then perhaps it is an old version of libjpeg and you need to update that.

You also never say exactly what version of IM you are using other than current. What do you get from

convert -version

Version: ImageMagick-6.7.2-1-Q16-windows-dll

Hi, fmw42. Thanks for the response.

First, any jpeg will do for testing.

No, it doesn't fail consistently - sometimes the lines are there, sometimes not. But the lines are consistent - always about that length, and always in the top half. (As far as I can see.)

I'll try the writedown debugging strategies.

I see what you mean about the (non-existent) +filter switch; I'll try your suggestion.

I'll get back to you.



Thanks.

The drop-outs could be related to a bug in OpenMP. To test, set the MAGICK_THREAD_LIMIT environment variable to 1 so only one thread at a time runs.

Hi, again.

I've checked the libjpeg version: it's 8, which is up-to-date I think.

Translating JPG > PNG still gives dropouts

Translating PNG > PNG doesn't appear to generate dropouts but since the dropouts don't show every time it's difficult to know whether that's any kind of fix or clue to the problem - if there is one - or is just chance.

Setting MAGICK_THREAD_LIMIT=1 does also seem to work; but with the same caveat as PNG > PNG, obviously.


Thanks.

What version of IM? We're using ImageMagick 6.7.2-1 and your command failed with

• convert: invalid argument for option `sparse-color': Invalid number of Arguments @ error/mogrify.c/SparseColorOption/481.

We then used the example from http://www.imagemagick.org/Usage/canvas/#sparse-color: 30,10 red 10,80 blue 90,90 lime, and got proper results. It looks like -sparse-color needs 3 arguments and you only have 2.

Hi.

I gave my IM version - in red - above: ImageMagick-6.7.2-1-Q16-windows-dll

-sparse-color Barycentric only requires two parameters to generate the third automatically. To quote your docs:

Two Point Gradients
If only two color points are given, IM will generate the third point for you, so that the angle is perpendicular between the two original points. The result is a simple linear gradient over which you have a lot of control.

D.

Magick,

This should work with two points. See http://www.imagemagick.org/Usage/canvas ... _gradients.

On my Mac, it works fine. I have PMed Anthony on this.

My release of ImageMagick returns an exception with 2 points. We'll wait for Anthony to comment.

The sparse color operator should allows you to specify ANY number of arguments. From one thru to as many as you like. That is especially the case with a freeform method such as 'Shepard's Method'.

However, some methods work BEST with a specific number of points.

Barycentric works best with 3 points. If more than three points are given then it should generate a best fit average that many nor match any of the given points but be as close as possible to all the points given.

But with 2 points it does some calculations to generate a third point perpendicular to the other two and the same color as one of them so as to generate a perfect gradient between the two given points. A very important special case.

a single point is also a special case, but it is a common special case for ALL methods. Just make the whole image that color.

That is what should happen!

IM v6.6.8-5 is the last MAJOR change to the operator, and that was to preserve the colors in the original image when a limited set of channels is selected.

NOTE that the operators core API input is a complex array of floating point data that depends very heavilly on the current channel setting. There is a function in the CLI interface that parses the users input string (coordinates and color) into that array. This was original meant to be used by other API's such as Perl and Ruby, but it seems those API's do not make use of that function


The most common reason for a error about number of arguments for just the CLI interface is likely a mismatch between the librarys core (the operator function) and the wand (CLI interface). That is the only reason I can see for it.

This thread seems to be wandering off topic. What does the number of parameters passed to -sparse-color have to do with the possible dropout bug? The -sparse-color command works correctly according to the documentation. Even if it didn't I doubt any inconsistencies in the drawing of the gradient would survive -distort Polar -1 and stil appear as linear dropouts.


D.

It may not have anything to do with -distort, but with OpenMP multiprocessing, especially if it is not consistent. If you are on a multiprocessor system, try disabling OpenMP (recompile IM that way). That has been know to cause problems on some Unix systems.

I know it has nothing to do with -distort Polar -1. I know that because the dropouts are linear - doh! I was pointing out that the tosh about -sparse-color was irrelevant since -distort Polar -1 came after it. The gen on OpenMP was at least germane. I'll bear it in mind.


D.

I should apologise for the above remarks; they sound more than a little snotty. I'm aware that the developers don't want a buggy piece of software any more than I do - so sorry, and thanks for the help.


D.