Imgcrop - simple image converter/cropper

[vovchik]

Dear all,

Here is a tiny command line program to crop and convert images. It uses gdk_pixbuf to do all the heavy lifting:

Code: Select all

imgcrop (simple image cropper/converter) v.0.1a by vovchik, Oct 2018
---
Input formats supported:  pnm, pbm, pgm, ppm, tga, xpm, tiff, pcx, gif,
                          xbm, wmf, icns, bmp, png, jpg, svg and ico.
Output formats supported: png, jpg, bmp, tiff and ico.
Input parameters:         oldname newname x_start y_start width height
---
Example:                  imgcrop test.jpg test1.png 5 5 240 240
                                           or
                          imgcrop test.png -size (shows dimensions)

The archive contains the Bacon source and a 32-bit binary (Xenial). I hope it works for you. If somebody wants to compile a 64-bit version, please use a relatively recent Bacon (the current is 3.8.1).

[BarryK]

That's real nice!

Would it be possible for it to default to the entire image, if the size parameters are left off, or all zeros? Ex:

imgcrop test.jpg test1.png 0 0 0 0

That way, wouldn't have to run the "-size" thingy first.

[vovchik]

Dear Barry,

Thanks. You are right about the 0 0 0 0 default. The very same thought occurred to me as I was on a tram about 20 minutes ago, returning from a rather painless visit to the dentist's. I also think I should perform a check on max_w and max_h and default to those in cases where the user-supplied x and y offsets, given a desired w and h, exceed the dimensions of the original image. I'll do that soon...

With kind regards,
vovchik

[BarryK]

Another thing that I would like to ask about, is a quick way of resizing an image:

Code: Select all

# imgcrop in.png out.png 0 0 48 48

Both input and output are png, and input is any size, even 48x48. Output will be 48x48.

I have a use for this in /usr/local/easy_containers/easy-container script in EasyOS. I want to create a 48x48 png, and the input can be any size, svg, xpm, jpg or png.

Currently, I am testing for the extension, then using netpbm utilities to handle each image type. Your little app will greatly simplify this!

[BarryK]

64-bit compile, using bacon 3.7.2. Input is 16x16:

Code: Select all

# ./imgcrop Animation.xpm out.png 0 0 48 48

(imgcrop:7193): GdkPixbuf-CRITICAL **: gdk_pixbuf_new_subpixbuf: assertion 'src_x >= 0 && src_x + width <= src_pixbuf->width' failed

(imgcrop:7193): GdkPixbuf-CRITICAL **: gdk_pixbuf_savev: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(imgcrop:7193): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
OOPS.. something terrible happened and out.png was not created.

Ah, does that mean we can only go down in size? Yes...

Code: Select all

# ./imgcrop Animation.xpm out.png 0 0 12 12
Original image: Animation.xpm (w x h): 16 x 15
Arguments:      x=0 y=0 w=12 h=12
New file:       out.png (w x h): 12 x 12

Would it too difficult to scale up as well?

[vovchik]

Dear Barry,

You are right about it only being able to scale down at the moment. However, my old picscale did the scaling just fine, and I can relatively easily incorporate the scaling business, I think, since I used picscale as a template for imgcrop. I will get on that soon - as soon as I figure something out about animated gifs that has been intriguing me. I am past the middle of solving that gif problem, so it won't be long. I see that the problem of catching errors related to size in imgcrop may just go away if I simply scale to accommodate the new size requested by the user. That may be a nice solution.

With kind regards,
vovchik

[BarryK]

if I simply scale to accommodate the new size requested by the user. That may be a nice solution.

Yes, that seems like an elegant solution. In my case, where I want 48x48 output, if the input image is less, then scale it up to 48x48, then do the cropping.

[BarryK]

Thinking about it some more, if I wanted to scale an image to a certain size, then 'picscale' is fine.

While thinking about these great little utilities, I was reminded of a limitation in 'pngoverlay'. The pngoverlay executable has to be in the same directory as the images it is working on.

woof-CE is no longer using pngoverlay, they now have 'pngoverlay.sh', a script that uses netpbm utilities.

Earlier pups have pngoverlay, and EasyOS still does, and I have no plan to drop it!

The source that I use is in 'pup-tools', here:

http://distro.ibiblio.org/easyos/source ... 417.tar.gz

[aaaaa]