convert doesn't conserve size when scaling down and up - imagemagick

In order to make applying blur faster I'm first scaling my image down and then scale it back up:
convert - -scale 10% -blur 0x2.5 -resize 1000% RGB:-
This works most of the time but sometimes the output resolution is slightly different from the original input. Is there a way to force the pipeline to be size-preserving?

You should be able to access the original geometry of the image via %G, so you can do:
convert input.jpg -scale 10% -blur 0x2.5 -resize '%G!' RGB:-
If you are using Windows, you probably want "%G!" in double rather than single quotes.
If you are using v7 ImageMagick, replace convert with magick.
I think you are getting errors because if you take 10% of 72 pixels (say), you will get a whole number of pixels, i.e. 7 pixels and then when you scale back up by a factor of 10 you'll get 70 rather than your initial 72.

If you are using Imagemagick 7, you can do the following:
magick input.jpg -set option:wd "%w" -set option:ht "%h" -scale "%[fx:wd/10]x%[fx:ht/10]" -blur 0x2.5 -resize "%[fx:wd]x%[fx:ht]\!" RGB:-
This stores the input width and height. Then uses the stored values to scale by 1/10 of those dimensions, then does the blur, then resizes exactly back to the origin input size. Note the ! that forces the resize to the exact dimensions.
or simpler without storing the input width and height:
magick lena.jpg -scale "%[fx:w/10]x%[fx:h/10]" -blur 0x2.5 -resize "%[fx:w]x%[fx:h]\!" lena_x.jpg

Related

Imagemagick: How to bulk convert images into square

I want the size of the square should be equal to the largest side of the original photo
E.g.
Original: 500 x 400 => Output:500 x 500
Original: 400 x 600 => Output: 600 x 600
You can do that as follows for any given image in Imagemagick 7. To do multiple image, you would need to write a "for" loop, whose syntax depends upon your OS.
magick image.suffix -gravity center -background black -extent "%wx%h^" result.suffix
or
magick image.suffix -gravity center -background black -extent "%[fx:max(w,h)]x%[fx:max(w,h)]" result.suffix
Here is a better way to convert all images in a folder with either Imagemagick 6 or 7. I use -distort SRT's viewport to do the padding with a no-op warping (i.e. no rotation, scale or translation) in mogrify to process all images in the folder.
First create a new folder to hold your output images, if desired and use the -path option to mogrify. Specify a background color (in this case I use red).
For Imagemagick 7:
magick mogrify -path path_to/new_folder -virtual-pixel background -background red -set option:distort:viewport "%[fx:max(w,h)]x%[fx:max(w,h)]-%[fx:0.5*(max(w,h)-w)]-%[fx:0.5*(max(w,h)-h)]" +distort srt 0 *
For Imagemagick 6, remove "magick" before mogrify.

Resize an image with 54x54 squares (540x540) to 54x54pixel lossless

I've got an 540x540 image of 54x54 color squares (same sizes).
When I resize it to 54x54px it looks horrible (blurred), shouldn't a resize like this be perfectly done with imagemagick?
is I possible to get it perfect?
I've tested convert source.png -resize destination.png and -adaptive-resize but the result is the same..
I see what your confusion is now... the problem is not that the process is lossy, rather it is because the -resize is doing more sophisticated processing than you want in order to make an attractive job that you would want for, say, photographs. You want a very simple point sampling process which will produce simple blocks of pure, uncombined colour.
I'll make a start image:
magick -size 10x10 xc:red +noise random -scale 540x540 start.png
And scale it down, by taking a point sample in each block:
magick start.png -sample 10x10 small.png
And back up:
magick result.png -scale 540x540 reincarnated.png

crop image with imagemagick offset given in percentage

imagemagick's crop command supports cropping to a percentage of an image but the offset values must be specified in pixel values, e.g.:
convert image.png -crop 50%x+10+20
I want to crop with offset values x and y given in percentage of the image width, and height respectively. The pixel values can be calculated, for instance if the image size is 100x200 an offset of 10% would result in 10 and 20 respectively. Is it possible to do this calculation as part of the call to convert? Width and height are available as %w and %h at some places, but this does not work:
convert image.png -crop 50%x+(0.1*%w)+(0.1*%h)
If you're running IM v6 you can use FX expressions with "-set" to set image attributes. By setting the page geometry you can specify the offsets to a calculated percentage and do the crop like this...
convert image.png -set page -%[fx:w*0.1]-%[fx:h*0.1] -crop 50%x+0+0 result.png
That reads the image, sets the geometry for the upper left corner to a location outside the original canvas, and crops to the new top left corner specified by the geometry.
Note the offsets are negative numbers.
Also, if you're doing additional processing in the same command you'll probably want to "+repage" after the crop in order to reset the page geometry to the new WxH+0+0.
Edited to add: You can even include the width and height dimensions for the crop when using "-set page". This command would crop an output of 50% the input width and height, and starting at 10% in from the left and top...
convert image.png \
-set page %[fx:w*0.5]x%[fx:h*0.5]-%[fx:w*0.1]-%[fx:h*0.1] -crop +0+0 result.png
Notice how the crop operation is simply "-crop +0+0" since the dimensions and offsets are in the page geometry.
This method lets you use more complex calculations than just using a percent or number of pixels for the cropped output dimensions.
You cannot do that in ImageMagick 6. But you can do that in ImageMagick 7.
magick image.png -crop "50%x+%[fx:0.1*w]+%[fx:0.1*h]" +repage result.png
In ImageMagick 6, you need to do the computations ahead of the command, store them in a variable and use the variable in the crop command.
However, in ImageMagick 6, you can do the equivalent using -distort with viewport processing as follows:
convert image.png -set option:distort:viewport "%[fx:0.5*w]x%[fx:0.5*h]+%[fx:0.1*w]+%[fx:0.1*h]" -filter point -distort SRT 0 result.png
With v7 ImageMagick, make start image:
magick -size 200x100 gradient: a.jpg
Now crop using lots of calculated widths, heights, offsets:
magick a.jpg -crop "%[fx:w*0.9]x%[fx:h*0.8]+%[fx:w*0.1]+%[fx:h*0.05]" b.png
Check:
identify b.png
b.png PNG 180x80 200x100+20+5 8-bit Gray 256c 408B 0.000u 0:00.000
If you only have v6, use bash and integer arithmetic:
read w h < <(identify -format "%w %h" a.jpg)
convert a.jpg -crop $((w*80/100))x$((h*90/100))+$((w*10/100))+$((h*5/100)) result.png
Check:
identify result.png
result.png PNG 160x90 200x100+20+5 8-bit Gray 256c 412B 0.000u 0:00.000

Imagemagick convert to name tiles as row/column doesn't work as expected with -extent

I have an image, 5120  ×  4352 that I crop into 2048x2048 tiles. I want to name my cropped tiles like
tile_0_0.png
tile_0_1.png
tile_0_2.png
tile_1_0.png
tile_1_1.png
tile_1_2.png
...
But this command:
convert image.png -crop 2048x2048 -gravity northwest \
-extent 2048x2048 -transparent white \
-set 'filename:tile' '%[fx:page.x/2048]_%[fx:page.y/2048]' \
+repage +adjoin 'tile_%[filename:tile].png'
Gives me this result:
tile_0_0.png
tile_0_1.png
tile_0_16.png
tile_1_0.png
tile_1_1.png
tile_1_16.png
tile_4_0.png
tile_4_1.png
tile_4_16.png
I suspect it has do with the tiles on the last row and column aren't fully 2048x2048, but the extent command makes the end result still 2048, but how can I use this with tiles and file names?
My current workaround is to first resize the original image like this, and then run the above command:
convert image.png -gravity northwest \
-extent 2048x2048 -transparent white bigger.png
But it would be nice to do it in one swoop :)
Using ImageMagick you could set a viewport that is just enough larger than the input image so it divides evenly by 2048. Then a no-op distort will enlarge the viewport to that size. That way the "-crop 2048x2048" will create pieces that are already 2048 square.
Here's a sample command I worked up in Windows, and I'm pretty sure I translated it to work correctly as a *nix command.
convert image.png \
-set option:distort:viewport '%[fx:w-(w%2048)+2048]x%[fx:h-(h%2048)+2048]' \
-virtual-pixel none -distort SRT 0 +repage -crop 2048x2048 \
-set 'filename:tile' '%[fx:page.x/2048]_%[fx:page.y/2048]' \
+repage +adjoin 'tile_%[filename:tile].png'
The "-distort SRT" operation does nothing except expand the viewport to dimensions that divide evenly by 2048, with a result just like doing an "-extent" before the crop. And "-virtual-pixel none" will leave a transparent background in the overflow areas.
Edited to add: The formula for extending the viewport in the above command will incorrectly add another 2048 pixels even if the dimension is already divisible by 2048. It also gives an incorrect result if the dimension is less than 2048. Consider using a formula like this for setting the viewport to handle those conditions...
'%[fx:w+(w%2048?2048-w%2048:0)]x%[fx:h+(h%2048?2048-h%2048:0)]'

Changing exposure of jpeg

Given a jpeg, what is the formula to change the exposure of that jpeg by +/-1 stop or as known as 1 EV? I want to simulate this exposure change. Is there a formula/ method to do so?
I can demonstrate that using ImageMagick, which is included in most Linux distros and available for OSX and Windows from here.
First, at the Terminal command line create an image:
convert -size 512x512 gradient:black-yellow gradient.png
Now, the way to effect +1 stop exposure increase is to composite the image with itself using the Screen blending mode - it is available in Photoshop and ImageMagick and is described here.
So, the formula to composite image A with image B is:
1-stop brighter image = 1-(1-A)(1-B)
but as we are compositing the image with itself, A and B are the same, so we effectively have
1-(1-A)(1-A)
ImageMagick refers to the pixels of an image using p rather than A, so we can do a 1-stop increase like this:
convert gradient.png -colorspace RGB -fx "(1-(1-p)(1-p))" result.png
Note that the Wikipedia article, and ImageMagick's -fx both assume your pixel intensities vary between 0 and 1.0. If you are using 8-bit images, you should calculate with 255 in place of 1, namely
+1 stop brighter image = 255-(255-A)(255-A)
or if using 16-bit values
+1 stop brighter image = 65535-(65535-A)(65535-A)
The above fx-based method is however, very slow because the -fx is interpreted rather than compiled, so a faster way to do it is:
convert gradient.png gradient.png -colorspace RGB -compose screen -composite screen.png
Just for fun, another way of looking at that is that we take the inverse of A, that is 1-A, and square it, and then take the inverse, so it can be done like this:
convert gradient.png -colorspace RGB -negate -evaluate pow 2 -negate result.png
The equivalent of -1 stop exposure decrease is to composite the image with itself using the Multiply blend mode, the formula being
1-stop darker image = A x B
which you would do faster with
convert gradient.png gradient.png -colorspace RGB -compose multiply -composite result.png
or even faster, by using memory-to-memory cloning rather than reading from disk twice, with
convert gradient.png -colorspace RGB +clone -compose multiply -composite result.png
but could do equally with
convert gradient.png -colorspace RGB -evaluate pow 2 result.png

Resources