MagickExtentImage

[mkoppanen]

Code: Select all

#include <stdio.h>
#include <wand/magick-wand.h>

int main()
{
  MagickWand *magick_wand;
  PixelWand *pixel_wand;

  magick_wand = NewMagickWand();
  pixel_wand = NewPixelWand();

  PixelSetColor( pixel_wand, "red" );

  MagickNewImage( magick_wand, 400, 400, pixel_wand );

  /* After this the red area topleft corner is in coordinates x100 y100 */
  MagickExtentImage( magick_wand, 800, 800, -100, -100 );

  MagickWriteImage( magick_wand, "out.jpg" );

  return 0;
}

In the following code negative x and y paramters given to MagickExtentImage move the original area to right to. This seems a bit counter-intuitive. I would expect the positive values to move to right and down from the origo. Is this expected behavior?

[el_supremo]

Hi Mikko,
I tried that same sort of code yesterday
It appears that coordinate (0,0) is the top left of the original image so that when you place the original image in the middle of a larger canvas, the coordinate of the top left corner of the extent will be negative.

Pete

[mkoppanen]

Hi Mikko,
I tried that same sort of code yesterday
It appears that coordinate (0,0) is the top left of the original image so that when you place the original image in the middle of a larger canvas, the coordinate of the top left corner of the extent will be negative.

Pete

Hello Pete,

I really can't say I follow you there. Passing x0,y0 to MagickExtentImage places the original image into new images 0,0 (top left corner). So basically if this follows rest of the api passing 200, 0 should place the old images top left corner to x200,y0 in the new larger image.

Am I missing (again:) ) something here ?

[el_supremo]

Hi Mikko,

passing 200, 0 should place the old images top left corner to x200,y0 in the new larger image.

No, it's the other way round. The coordinate you specify to the function is the coordinate of the top left corner of the new extent relative to the *old* image whose top left corner is (0,0).

Try this code:

Code: Select all

#include <windows.h>
#include <wand/magick_wand.h>

void test_wand(void)
{
	MagickWand *m_wand = NULL;
	PixelWand *p_wand;

	MagickWandGenesis();

	m_wand = NewMagickWand();
	p_wand = NewPixelWand();

	PixelSetColor(p_wand, "blue");

	if(!MagickReadImage(m_wand,"logo:")) {
		MessageBox(NULL,"Failed to read logo:","",MB_OK);
	} else {
		MagickSetImageBackgroundColor(m_wand,p_wand);
		MagickExtentImage(m_wand,1024,768,-200,-50);
		MagickWriteImage(m_wand,"logo_extent.jpg");
	}
	/* Tidy up */
	m_wand = DestroyMagickWand(m_wand);
	p_wand = DestroyPixelWand(p_wand);
	MagickWandTerminus();
}

It produces this image to which I've added the coordinate system:


The (0,0) coordinate is at the top left of the logo: image, which is the original one, so the coordinate of the extent's top left is (-200,-50).

Hope this helps.
Pete

[mkoppanen]

Thank you for seeing all the trouble, Pete! Now I get the point in the coordinates

[anthony]

The question however is Is this a bug, or a feature?

I thought Extent was more like a normal crop without any virtual offsets, in which case the results you are seeing is incorrect.

The behavior you are seeing is more like a viewport crop that was later flattened.


What is your view. Should it be fixed, or left as is.

[mkoppanen]

The question however is Is this a bug, or a feature?

I thought Extent was more like a normal crop without any virtual offsets, in which case the results you are seeing is incorrect.

The behavior you are seeing is more like a viewport crop that was later flattened.


What is your view. Should it be fixed, or left as is.

My opinion is that it does not work how one would expect it to work. That might lead to confusion. My view is that it should be changed in the next major version (6.3.6?).

[el_supremo]

Changing the interpretation will break anything that is using it right now. Note that the documentation (http://imagemagick.org/api/magick-image ... xtentImage) does refer to (x,y) as an offset, not as a coordinate, so in that sense it is correct as it stands. The only problem is that there are two interpretations of how the offset works. Is it an offset of the extent relative to the original image, or is it the other way round?
FWIW, I think that clarifying the documentation is all that's required.

Pete

[anthony]

Do you have a suggestion or new text for the documentation?

Also what does it do at the other side? If you specify 100x100+100+100
but the image is only 150x150 then what should it do?

What about virtual offsets or canvas size of the resulting image. What if the image itself has a virtual offset. These are all matters that need to be considered when defining just what and operator should do. -crop as I outlined in IM Examples
does define what it does in all these cases, though I am not certain its manual entry is also defined properly.