Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34394 > unrolled thread

Bash script with Image Magick to a Java program

Back to article view | Back to comp.lang.java.programmer

Contents

  Bash script with Image Magick to a Java program Cecil Westerhof <Cecil@decebal.nl> - 2016-05-27 00:42 +0200
    Re: Bash script with Image Magick to a Java program Jerry Stuckle <jstucklex@attglobal.net> - 2016-05-26 20:45 -0400
      Re: Bash script with Image Magick to a Java program Cecil Westerhof <Cecil@decebal.nl> - 2016-05-27 11:01 +0200
    Re: Bash script with Image Magick to a Java program Arne Vajhøj <arne@vajhoej.dk> - 2016-05-26 22:06 -0400
      Re: Bash script with Image Magick to a Java program Cecil Westerhof <Cecil@decebal.nl> - 2016-05-27 11:06 +0200
        Re: Bash script with Image Magick to a Java program Martin Gregorie <martin@address-in-sig.invalid> - 2016-05-27 10:00 +0000
          Re: Bash script with Image Magick to a Java program Cecil Westerhof <Cecil@decebal.nl> - 2016-05-27 13:31 +0200
            Re: Bash script with Image Magick to a Java program Eric Douglas <e.d.programmer@gmail.com> - 2016-05-27 05:15 -0700
              Re: Bash script with Image Magick to a Java program Cecil Westerhof <Cecil@decebal.nl> - 2016-05-27 15:18 +0200
            Re: Bash script with Image Magick to a Java program Duncan Idaho <duncan@dunenoemail.com> - 2016-05-27 18:51 +0100
              Re: Bash script with Image Magick to a Java program Martin Gregorie <martin@address-in-sig.invalid> - 2016-05-27 18:02 +0000
                Re: Bash script with Image Magick to a Java program Cecil Westerhof <Cecil@decebal.nl> - 2016-05-27 23:23 +0200
              Re: Bash script with Image Magick to a Java program Cecil Westerhof <Cecil@decebal.nl> - 2016-05-27 23:18 +0200
                Re: Bash script with Image Magick to a Java program Duncan Idaho <duncan@dunenoemail.com> - 2016-05-28 08:03 +0100
        Re: Bash script with Image Magick to a Java program Arne Vajhøj <arne@vajhoej.dk> - 2016-05-27 17:59 -0400
    Re: Bash script with Image Magick to a Java program Brixomatic <brixomatic@yahoo.com> - 2016-05-29 17:28 +0200
    Re: Bash script with Image Magick to a Java program Eric Douglas <e.d.programmer@gmail.com> - 2016-06-14 10:25 -0700

#34394 — Bash script with Image Magick to a Java program

I have a Bash script that is more as a decade old which I use Image
Magick to convert Photos to various other formats. For a long time I
wanted to change this. I am thinking about porting to a Java
application. Java has two libraries for Image Magick: Jmagick and
im4java. But Java has also its own functions to process graphics.
Would it be better to use the Java functions (no dependencies) or
Image Magick. If the latter: which is the better library?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#34395

On 5/26/2016 6:42 PM, Cecil Westerhof wrote:
> I have a Bash script that is more as a decade old which I use Image
> Magick to convert Photos to various other formats. For a long time I
> wanted to change this. I am thinking about porting to a Java
> application. Java has two libraries for Image Magick: Jmagick and
> im4java. But Java has also its own functions to process graphics.
> Would it be better to use the Java functions (no dependencies) or
> Image Magick. If the latter: which is the better library?
> 

Why change something that is working?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#34398

On Friday 27 May 2016 02:45 CEST, Jerry Stuckle wrote:

> On 5/26/2016 6:42 PM, Cecil Westerhof wrote:
>> I have a Bash script that is more as a decade old which I use Image
>> Magick to convert Photos to various other formats. For a long time
>> I wanted to change this. I am thinking about porting to a Java
>> application. Java has two libraries for Image Magick: Jmagick and
>> im4java. But Java has also its own functions to process graphics.
>> Would it be better to use the Java functions (no dependencies) or
>> Image Magick. If the latter: which is the better library?
>>
>
> Why change something that is working?

Because things change. For example I take a lot more pictures today
then when I wrote the script. So decisions I made then do not make
sense anymore. Beside that it is mostly a batch program and the
possibility to have a GUI is an improvement.

Also I think that as simple it is, it could be useful to others also.
And not everyone can run Bash scripts, but most people can run Java
applications.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#34396

On 5/26/2016 6:42 PM, Cecil Westerhof wrote:
> I have a Bash script that is more as a decade old which I use Image
> Magick to convert Photos to various other formats. For a long time I
> wanted to change this. I am thinking about porting to a Java
> application. Java has two libraries for Image Magick: Jmagick and
> im4java. But Java has also its own functions to process graphics.
> Would it be better to use the Java functions (no dependencies) or
> Image Magick. If the latter: which is the better library?

If your conversion is so simple that it is easily done with standard
Java library, then I suggest you go for it.

But I suspect that it may not be sufficient. These wrappers do not
exist because it is easy to do the same in Java without them.

:-)

Regarding Jmagick vs im4java, then they do different things. Jmagick is
a JNI wrapper to ImageMagick C API. im4java is a programmer friendly
interface to run the ImageMagick program with certain arguments.

You know that functionality exposed via ImageMagick program is
sufficient because that is what you do today, so im4java must be
the obvious choice for you.

Arne

[toc] | [prev] | [next] | [standalone]

#34397

On Friday 27 May 2016 04:06 CEST, Arne Vajhøj wrote:

> On 5/26/2016 6:42 PM, Cecil Westerhof wrote:
>> I have a Bash script that is more as a decade old which I use Image
>> Magick to convert Photos to various other formats. For a long time
>> I wanted to change this. I am thinking about porting to a Java
>> application. Java has two libraries for Image Magick: Jmagick and
>> im4java. But Java has also its own functions to process graphics.
>> Would it be better to use the Java functions (no dependencies) or
>> Image Magick. If the latter: which is the better library?
>
> If your conversion is so simple that it is easily done with standard
> Java library, then I suggest you go for it.
>
> But I suspect that it may not be sufficient. These wrappers do not
> exist because it is easy to do the same in Java without them.
>
> :-)

I evaluate things. Maybe I start with the standard library and as my
program evolves I switch. At the moment I know nothing about graphical
functionality in Java.


> Regarding Jmagick vs im4java, then they do different things. Jmagick
> is a JNI wrapper to ImageMagick C API. im4java is a programmer
> friendly interface to run the ImageMagick program with certain
> arguments.
>
> You know that functionality exposed via ImageMagick program is
> sufficient because that is what you do today, so im4java must be
> the obvious choice for you.

But then people that are going to use my program need to install Image
Magick. Or is this also the case when I am using Jmagick?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#34399

On Fri, 27 May 2016 11:06:16 +0200, Cecil Westerhof wrote:

> I evaluate things. Maybe I start with the standard library and as my
> program evolves I switch. At the moment I know nothing about graphical
> functionality in Java.
>
Whether the standard image classes in java.awt.image will do the job for 
you depends on the image source. I use it to produce thumbnails of JPG 
images but find that it can't correctly handle some JPGs from some 
sources. These are always B&W images, which result in a thumbnail of the 
correct requested size but distorted by being broken into vertical 
stripes separated by white 'bars' and, typically with the right-hand 1/3 
or so of the original image not appearing in the thumbnail version. 

This seems to be a deficiency in the Java library since the GIMP image 
manipulation program doesn't show this problem. I haven't tried Image 
Magik on these images so don't know what it would do.
 
Starting with the standard class library and only moving on if you find 
things it can't do sounds like a good plot. 

My only other comment is that the documentation for the standard image 
library does rather assume that you are already up to speed on image 
manipulation and so you know what affine transforms, etc. are and why you 
should use each type of operation on an image and in what order. This 
isn't covered in the Java tutorials and there are no references to this 
sort of basic information.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#34400

On Friday 27 May 2016 12:00 CEST, Martin Gregorie wrote:

> On Fri, 27 May 2016 11:06:16 +0200, Cecil Westerhof wrote:
>
>> I evaluate things. Maybe I start with the standard library and as
>> my program evolves I switch. At the moment I know nothing about
>> graphical functionality in Java.
>>
> Whether the standard image classes in java.awt.image will do the job
> for you depends on the image source. I use it to produce thumbnails
> of JPG images but find that it can't correctly handle some JPGs from
> some sources. These are always B&W images, which result in a
> thumbnail of the correct requested size but distorted by being
> broken into vertical stripes separated by white 'bars' and,
> typically with the right-hand 1/3 or so of the original image not
> appearing in the thumbnail version.

Well, I only work with color JPG files. ;-)


> This seems to be a deficiency in the Java library since the GIMP
> image manipulation program doesn't show this problem. I haven't
> tried Image Magik on these images so don't know what it would do.
>
> Starting with the standard class library and only moving on if you
> find things it can't do sounds like a good plot.
>
> My only other comment is that the documentation for the standard
> image library does rather assume that you are already up to speed on
> image manipulation and so you know what affine transforms, etc. are
> and why you should use each type of operation on an image and in
> what order. This isn't covered in the Java tutorials and there are
> no references to this sort of basic information.

I am not knowledged in image manipulation. So that could make things
trickier.

At the moment I do two things:
   - resize to a minimum format
   - resize to a precise format

If the format is 852x316 and the input format is 4000x2664. The first
results in an image with format 852x567 and the second in an in image
with format 852x316 where the converted undisturbed image is centred
on a black background 0f 852x316. This gives horizontal or vertical
stripes.

Is this doable (without jumping through hoops)? Otherwise I probably
should go for im4java.


Would it be easy to know if Image Magick is installed? I could then
disable the advanced functions on systems that do not have Image
Magick installed.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#34402

On Friday, May 27, 2016 at 7:43:49 AM UTC-4, Cecil Westerhof wrote:
> I am not knowledged in image manipulation. So that could make things
> trickier.
> 
> At the moment I do two things:
>    - resize to a minimum format
>    - resize to a precise format
> 
> If the format is 852x316 and the input format is 4000x2664. The first
> results in an image with format 852x567 and the second in an in image
> with format 852x316 where the converted undisturbed image is centred
> on a black background 0f 852x316. This gives horizontal or vertical
> stripes.
> 
> Is this doable (without jumping through hoops)? Otherwise I probably
> should go for im4java.

How difficult image manipulation is in Java depends exactly what you want to do.  Do you want the same input and output format?  Is it just jpg?  Are you just scaling it smaller?  Piece of cake.  We could write that in 5 minutes.

[toc] | [prev] | [next] | [standalone]

#34404

On Friday 27 May 2016 14:15 CEST, Eric Douglas wrote:

> On Friday, May 27, 2016 at 7:43:49 AM UTC-4, Cecil Westerhof wrote:
>> I am not knowledged in image manipulation. So that could make
>> things trickier.
>>
>> At the moment I do two things:
>> - resize to a minimum format
>> - resize to a precise format
>>
>> If the format is 852x316 and the input format is 4000x2664. The
>> first results in an image with format 852x567 and the second in an
>> in image with format 852x316 where the converted undisturbed image
>> is centred on a black background 0f 852x316. This gives horizontal
>> or vertical stripes.
>>
>> Is this doable (without jumping through hoops)? Otherwise I
>> probably should go for im4java.
>
> How difficult image manipulation is in Java depends exactly what you
> want to do. Do you want the same input and output format? Is it just
> jpg? Are you just scaling it smaller? Piece of cake. We could write
> that in 5 minutes.

At the moment what I want is very simple: converting photo's in JPG
format to other sizes. For use on for example Facebook and as elements
in YouTube video's.

I would not be surprised if I want to do more in the future. ;-) For
example adding text, adding borders, …


I already had a few projects for this weekend, but I think I just got
another. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#34406

On 27/05/16 12:31, Cecil Westerhof wrote:
> On Friday 27 May 2016 12:00 CEST, Martin Gregorie wrote:
>
>> On Fri, 27 May 2016 11:06:16 +0200, Cecil Westerhof wrote:
>>
>>> I evaluate things. Maybe I start with the standard library and as
>>> my program evolves I switch. At the moment I know nothing about
>>> graphical functionality in Java.
>>>
>> Whether the standard image classes in java.awt.image will do the job
>> for you depends on the image source. I use it to produce thumbnails
>> of JPG images but find that it can't correctly handle some JPGs from
>> some sources. These are always B&W images, which result in a
>> thumbnail of the correct requested size but distorted by being
>> broken into vertical stripes separated by white 'bars' and,
>> typically with the right-hand 1/3 or so of the original image not
>> appearing in the thumbnail version.
>
> Well, I only work with color JPG files. ;-)
>
>
>> This seems to be a deficiency in the Java library since the GIMP
>> image manipulation program doesn't show this problem. I haven't
>> tried Image Magik on these images so don't know what it would do.
>>
>> Starting with the standard class library and only moving on if you
>> find things it can't do sounds like a good plot.
>>
>> My only other comment is that the documentation for the standard
>> image library does rather assume that you are already up to speed on
>> image manipulation and so you know what affine transforms, etc. are
>> and why you should use each type of operation on an image and in
>> what order. This isn't covered in the Java tutorials and there are
>> no references to this sort of basic information.

Just FYI

I use the following Java libraries

java.awt.Graphics;
java.awt.Image;
java.awt.image.BufferedImage;
javax.imageio.ImageIO;
javax.swing.ImageIcon;

plus some standard libraries.

along with the

org.apache.commons.fileupload

libraries

To upload, scale and generate thumbnails and large images in jpg format
for use in my home brewed Content Management System
My source images are cropped square to a random convenient size.

I have scaled tens of thousands of images and generated tens of thousands of thumbnails
over the last five or so years with not a single problem

The code hasn't been touched for many years, I can't even remember writing most of it :-)
it's used almost every day.

I'll let you have the code if you like.
It could do with refactoring I expect, like I say it hasn't been touched for years.

<snip>

Idaho

-- 
Duncan Idaho
!(ghola mentat)

[toc] | [prev] | [next] | [standalone]

#34407

On Fri, 27 May 2016 18:51:16 +0100, Duncan Idaho wrote:

> On 27/05/16 12:31, Cecil Westerhof wrote:
>> On Friday 27 May 2016 12:00 CEST, Martin Gregorie wrote:
>>
>>> On Fri, 27 May 2016 11:06:16 +0200, Cecil Westerhof wrote:
>>>
>>>> I evaluate things. Maybe I start with the standard library and as my
>>>> program evolves I switch. At the moment I know nothing about
>>>> graphical functionality in Java.
>>>>
>>> Whether the standard image classes in java.awt.image will do the job
>>> for you depends on the image source. I use it to produce thumbnails of
>>> JPG images but find that it can't correctly handle some JPGs from some
>>> sources. These are always B&W images, which result in a thumbnail of
>>> the correct requested size but distorted by being broken into vertical
>>> stripes separated by white 'bars' and, typically with the right-hand
>>> 1/3 or so of the original image not appearing in the thumbnail
>>> version.
>>
>> Well, I only work with color JPG files. ;-)
>>
>>
>>> This seems to be a deficiency in the Java library since the GIMP image
>>> manipulation program doesn't show this problem. I haven't tried Image
>>> Magik on these images so don't know what it would do.
>>>
>>> Starting with the standard class library and only moving on if you
>>> find things it can't do sounds like a good plot.
>>>
>>> My only other comment is that the documentation for the standard image
>>> library does rather assume that you are already up to speed on image
>>> manipulation and so you know what affine transforms, etc. are and why
>>> you should use each type of operation on an image and in what order.
>>> This isn't covered in the Java tutorials and there are no references
>>> to this sort of basic information.
> 
> Just FYI
> 
> I use the following Java libraries
> 
> java.awt.Graphics;
> java.awt.Image;
> java.awt.image.BufferedImage;
> javax.imageio.ImageIO;
> javax.swing.ImageIcon;
> 
> plus some standard libraries.
> 
> along with the
> 
> org.apache.commons.fileupload
> 
> libraries
> 
> To upload, scale and generate thumbnails and large images in jpg format
> for use in my home brewed Content Management System My source images are
> cropped square to a random convenient size.
> 
> I have scaled tens of thousands of images and generated tens of
> thousands of thumbnails over the last five or so years with not a single
> problem
> 
> The code hasn't been touched for many years, I can't even remember
> writing most of it :-)
> it's used almost every day.
> 
> I'll let you have the code if you like.
> It could do with refactoring I expect, like I say it hasn't been touched
> for years.
> 
> <snip>
> 
> Idaho

I'm using:
import java.awt.RenderingHints;
import java.awt.geom.AffineTransform;
import java.awt.image.AffineTransformOp;
import java.awt.image.BufferedImage;
import java.awt.image.BufferedImageFilter;
import java.awt.image.BufferedImageOp;
import java.awt.image.RescaleOp;
import java.io.File;
import java.io.IOException;
import java.util.Hashtable;
import javax.imageio.ImageIO;
import org.gregorie.environ.ReportError;

... but obviously not all of them are being used to resize an image. 
Here's the code:

   public void resizeTo(int width)
   {
      re.trace(2, "resizeTo(" + width + ") started");
      int w = im.getWidth();
      int h = im.getHeight();
      double scale = width * 1.0 / w;
      
      if (noExpand && scale >= 1.0)
      {
         wouldExpand = true;
         re.trace(2, "Image is smaller than " + width +
                     " wide: original size will be output");
      }
      else
      {
         wouldExpand = false;
         AffineTransform at = new AffineTransform();
         at.scale(scale, scale);
         AffineTransformOp op = new AffineTransformOp(at,
                                         AffineTransformOp.TYPE_BICUBIC);
         Double nw = new Double(w * scale);
         Double nh = new Double(h * scale);
         re.trace(2, "scale=" + scale +
                     " new size w=" + nw.intValue() +
                     " h=" + nh.intValue());
         re.trace(3, "Source buffer details: " + im);
         om = new BufferedImage(nw.intValue(),
                                nh.intValue(),
                                BufferedImage.TYPE_3BYTE_BGR);
         op.filter(im, om);
      }

      re.trace(1, "resizeTo(" + width + ") done");
   }

The re.trace() calls are to my private traceing/debugging class


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#34408

On Friday 27 May 2016 20:02 CEST, Martin Gregorie wrote:

> I'm using:
> import java.awt.RenderingHints;
> import java.awt.geom.AffineTransform;
> import java.awt.image.AffineTransformOp;
> import java.awt.image.BufferedImage;
> import java.awt.image.BufferedImageFilter;
> import java.awt.image.BufferedImageOp;
> import java.awt.image.RescaleOp;
> import java.io.File;
> import java.io.IOException;
> import java.util.Hashtable;
> import javax.imageio.ImageIO;
> import org.gregorie.environ.ReportError;
>
> ... but obviously not all of them are being used to resize an image.
> Here's the code:
>
> public void resizeTo(int width)
> {
> re.trace(2, "resizeTo(" + width + ") started");
> int w = im.getWidth();
> int h = im.getHeight();
> double scale = width * 1.0 / w;
>
> if (noExpand && scale >= 1.0)
> {
> wouldExpand = true;
> re.trace(2, "Image is smaller than " + width +
> " wide: original size will be output");
> }
> else
> {
> wouldExpand = false;
> AffineTransform at = new AffineTransform();
> at.scale(scale, scale);
> AffineTransformOp op = new AffineTransformOp(at,
> AffineTransformOp.TYPE_BICUBIC);
> Double nw = new Double(w * scale);
> Double nh = new Double(h * scale);
> re.trace(2, "scale=" + scale +
> " new size w=" + nw.intValue() +
> " h=" + nh.intValue());
> re.trace(3, "Source buffer details: " + im);
> om = new BufferedImage(nw.intValue(),
> nh.intValue(),
> BufferedImage.TYPE_3BYTE_BGR);
> op.filter(im, om);
> }
>
> re.trace(1, "resizeTo(" + width + ") done");
> }
>
> The re.trace() calls are to my private traceing/debugging class

I will look into it. Thanks.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#34409

On Friday 27 May 2016 19:51 CEST, Duncan Idaho wrote:

> On 27/05/16 12:31, Cecil Westerhof wrote:
>> On Friday 27 May 2016 12:00 CEST, Martin Gregorie wrote:
>>
>>> On Fri, 27 May 2016 11:06:16 +0200, Cecil Westerhof wrote:
>>>
>>>> I evaluate things. Maybe I start with the standard library and as
>>>> my program evolves I switch. At the moment I know nothing about
>>>> graphical functionality in Java.
>>>>
>>> Whether the standard image classes in java.awt.image will do the
>>> job for you depends on the image source. I use it to produce
>>> thumbnails of JPG images but find that it can't correctly handle
>>> some JPGs from some sources. These are always B&W images, which
>>> result in a thumbnail of the correct requested size but distorted
>>> by being broken into vertical stripes separated by white 'bars'
>>> and, typically with the right-hand 1/3 or so of the original image
>>> not appearing in the thumbnail version.
>>
>> Well, I only work with color JPG files. ;-)
>>
>>
>>> This seems to be a deficiency in the Java library since the GIMP
>>> image manipulation program doesn't show this problem. I haven't
>>> tried Image Magik on these images so don't know what it would do.
>>>
>>> Starting with the standard class library and only moving on if you
>>> find things it can't do sounds like a good plot.
>>>
>>> My only other comment is that the documentation for the standard
>>> image library does rather assume that you are already up to speed
>>> on image manipulation and so you know what affine transforms, etc.
>>> are and why you should use each type of operation on an image and
>>> in what order. This isn't covered in the Java tutorials and there
>>> are no references to this sort of basic information.
>
> Just FYI
>
> I use the following Java libraries
>
> java.awt.Graphics;
> java.awt.Image;
> java.awt.image.BufferedImage;
> javax.imageio.ImageIO;
> javax.swing.ImageIcon;
>
> plus some standard libraries.
>
> along with the
>
> org.apache.commons.fileupload
>
> libraries
>
> To upload, scale and generate thumbnails and large images in jpg
> format for use in my home brewed Content Management System My source
> images are cropped square to a random convenient size.
>
> I have scaled tens of thousands of images and generated tens of
> thousands of thumbnails over the last five or so years with not a
> single problem
>
> The code hasn't been touched for many years, I can't even remember
> writing most of it :-) it's used almost every day.
>
> I'll let you have the code if you like. It could do with refactoring
> I expect, like I say it hasn't been touched for years.

That would be nice. If you like I will refactor it and send it back.
And if you like something implemented …

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#34412

On 27/05/16 22:18, Cecil Westerhof wrote:
> On Friday 27 May 2016 19:51 CEST, Duncan Idaho wrote:
>
>> On 27/05/16 12:31, Cecil Westerhof wrote:
>>> On Friday 27 May 2016 12:00 CEST, Martin Gregorie wrote:
>>>
>>>> On Fri, 27 May 2016 11:06:16 +0200, Cecil Westerhof wrote:
>>>>

where do you want it sent.

> That would be nice. If you like I will refactor it and send it back.
> And if you like something implemented …

Well you will need to do something as the single class method takes an instance of
org.apache.commons.fileupload.FileItem; as argument, FileItem exposes a couple of methods to return it's
contents as byte[] or an InputStream which is what the code uses. It's a trivial change though.


-- 
Duncan Idaho
!(ghola mentat)

[toc] | [prev] | [next] | [standalone]

#34410

On 5/27/2016 5:06 AM, Cecil Westerhof wrote:
> On Friday 27 May 2016 04:06 CEST, Arne Vajhøj wrote:
>> On 5/26/2016 6:42 PM, Cecil Westerhof wrote:

>>> I wanted to change this. I am thinking about porting to a Java
>>> application. Java has two libraries for Image Magick: Jmagick and
>>> im4java. But Java has also its own functions to process graphics.
>>> Would it be better to use the Java functions (no dependencies) or
>>> Image Magick. If the latter: which is the better library?

>> Regarding Jmagick vs im4java, then they do different things. Jmagick
>> is a JNI wrapper to ImageMagick C API. im4java is a programmer
>> friendly interface to run the ImageMagick program with certain
>> arguments.
>>
>> You know that functionality exposed via ImageMagick program is
>> sufficient because that is what you do today, so im4java must be
>> the obvious choice for you.
>
> But then people that are going to use my program need to install Image
> Magick. Or is this also the case when I am using Jmagick?

That would apply to both of them. They would need a shared library and
executable respectively.

If you don't want that, then you will need to go pure Java.

Arne

[toc] | [prev] | [next] | [standalone]

#34414

In article <87oa7s4f1u.fsf@Equus.decebal.nl>, Cecil Westerhof 
(Cecil@decebal.nl) says...
> 
> I have a Bash script that is more as a decade old which I use Image
> Magick to convert Photos to various other formats. For a long time I
> wanted to change this. I am thinking about porting to a Java
> application. Java has two libraries for Image Magick: Jmagick and
> im4java. But Java has also its own functions to process graphics.
> Would it be better to use the Java functions (no dependencies) or
> Image Magick. If the latter: which is the better library?

Since the old solution still works, I'd go all-in for Java, just for the 
fun of it and learning a thing or two. 

Kind regards,
Wanja


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

[toc] | [prev] | [next] | [standalone]

#34635

On Thursday, May 26, 2016 at 6:43:50 PM UTC-4, Cecil Westerhof wrote:
> I have a Bash script that is more as a decade old which I use Image
> Magick to convert Photos to various other formats. For a long time I

http://www.lylab.net/2016/05/image-uploader-security-flaw-discovered/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web