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?".

Hello,
I'd like to place a watermark over a number of images. Since the dimensions of these images vary, but the watermark should always have the maximal possible size at constant proportions, I have to calculate the perfect angle for the resizing. (It should look like that. Not like that.)

The code does not rotate the image. I think that's because "-rotate" does not accept "%[fx:]" arguments? Unfortunately, I have not been able to find clear information about this so far ...
In addition, the variables "w" and "h" seem to have the value "0" ... which I also do not understand.

Unfortunately, this is my own thread. Although I am very grateful for the answers there, my current question was not answered.

To briefly explain why I opened a new thread for this topic:

In the first thread I searched for an algorithm with which I can calculate the desired angle. So it was the approach I was looking for.

In this thread I ask if it is possible to perform a computation at runtime that accesses the dimensions of the currently processed images. In addition, I would like to know if I can use the result e.g. to rotate an image. The answer from the first thread serves as a case study.

To refer to this case example: At the moment, I have to execute four commands to get a watermarked image:

Get the dimensions of the watermark.

Get the dimensions of the underlying image (at 300 dpi).

Calculate the necessary angle.

Composing the picture (with the actual rotating and resizing).

The user GeeMac has shown that it is possible to integrate the step for "getting the dimensions" in the last step. Therefore, I ask if it is possible to integrate the calculation also into it.

AVoeee wrote:That makes perfect sense. But if I put the underlying image in the parentheses, it does also rotate.

Yes, so delete it.

If you use u.w and v.w, there must be two images in the current list to get the numbers from. If there aren't two images, it won't work. So do the rotation, which will rotate both images in the list, and then "-delete" whichever one you don't want.

(An alternative is to use "-distort SRT" and a more complex expression that will only rotate one image, which saves time. GeeMack often shows how to do this. But this still needs both images in the list, and still needs one to be deleted.)

When an "fx:" expression uses dimensions of images, those images must be in the current list.

Your "-rotate" includes the fx expression. An alternative is to put the fx expression in an earlier "-set option:DEGS %[fx:..blah..]", so that is when the dimensions of the two images are required. Then, you would have "-rotate %[DEGS]" when you need it.

Then it reads in the watermark image, so now there are two image in the stack.

The next line uses the formula you've written to rotate just the watermark image. That happens because I multiplied your formula by "t", which is the position of the image in the stack. The main input image is number "0", so it rotates zero degrees. The watermark is image "1" in the stack, so it rotates "1" times the formula.

Next is the resize. By using "u.w" and "u.h" it will resize both images to the dimensions of the main input image, which is already that size so it remains unchanged.

Then the "-compose over -gravity center -composite" places the rotated sized watermark over the input image.

The next line uses the formula you've written to rotate just the watermark image. That happens because I multiplied your formula by "t", which is the position of the image in the stack. The main input image is number "0", so it rotates zero degrees. The watermark is image "1" in the stack, so it rotates "1" times the formula.

Hello,
I have an additional question and I'm unsure if I should open a new thread.

When I convert images which have a transparent background to jpgs, the background turns black. (As can be seen here).
That seems to be a very common problem and I have also found some approaches and explanations in the forum.

But all the approaches I have found so far do suggest that transparency should be replaced by a color (on all layers of the image). But it is precisely this transparency that I need so I can place the rotated watermark on the underlying image ...

These approaches lead to something like this. So the transparency of the watermark turns also white and covers the whole picture.

Is there a way that all layers are taken into account and thus only the pixels that remained transparent at the end are replaced with a given color?
I've read that there are several options for "-compose" and "-composite" that will cause the image to merge instead of placing individual layers over each other. Could that be a possible solution?

The test image is available here.
The test "watermark" is available there.

Please kindly note that I am aware that png supports transparency. Nevertheless, I am interested in whether there is a way to achieve this with jpg.

JPG does not support transparency. So if you are making a JPG output, then you must flatten your processing over some background color or image, otherwise the JPG will replace any transparency with black (or the color or texture in the intermediate image under the transparent area). Perhaps you understand this already.

But to understand what you are trying to do, it would be helpful to see your command line that produced the resulting image you showed and explain where the problem is in the resulting image. It is not clear to me what you want.

So if you are making a JPG output, then you must flatten your processing over some background color or image, otherwise the JPG will replace any transparency with black (or the color or texture in the intermediate image under the transparent area).

You don't need to create an initial canvas as we did above, you can instead let "-flatten" create one for you. The canvas color will be the current "-background" color, while its size is defined by the first images Virtual Canvas size.

So I wrote the following bash code, which apparently fixes the problem: