Hey, Tom, great to hear from you again!
Yes, I have played a lot with the JAI and the ImageIO libraries. In
fact, the "Image Gallery" I did was JAI based. However, the quality is
not what I want it to be. What I like is that it's rather easy to use
and quite fast. For most Web graphics that is fine, but as soon as you
start moving into quality I am more than uncomfortable. If you e.g.
have a 300kb JPG image with bigger layers (e.g. a blue sky), then you
really feel the quality loss. The crazy thing is that even if the JPG
compression rate is set to 100% and I do NO processing (just buffer
the image and write it out) the result is somewhere around 230kb and
the big layers are spotted. When scaling with different algorithms the
result is similar.
But keep in mind that I am not a "Graphic Expert". All I know is that
there are different processes required to maintain quality when
scaling an image. It seems to be a matter of algorithms rather than
Java API. I can buffer the image in a way that the BufferedImage
contains the exact same amount of bytes, but when outputting the image
that's when I seem to loose the quality.
A lot of course has to do with the quality of the original image, but
it seems just "parsing" an image (create a BufferedImage and the write
it out) is enough to loose quality, on any given JPG image. I worked
my self through a lot of examples found during research, but none did
the job.
But for 90% or more of image processing JAI is fine, the quality loss
is hardly recognized. Perhaps I am just too picky :-)
If there is an interest out there, I gladly will manage a work group
separate from the list and once we have a cool imaging tool we will
come back and provide it to the community.
Thanks!
Giancarlo
gberner at xumak dot com
On Dec 3, 2008, at 12:13 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]
> wrote:
Giancarlo have you ever used the Java Advanced Imaging (JAI) library
for the scaling process? It is a fast library for working with
images and it runs on Windows, OS X and Linux (it has native
libraries, but has failover to java code if native libs aren't
found). I considered it against ImageMagick and found that I could
get better quality images and in the same amount of time or faster.
It is definitely much faster than the JRE Java2D implementation,
even the failover java code I found to be noticeably faster than
Java2D. I've used it successfully in a couple of apps, both of them
use it for scaling, rotation and cropping of images. JAI supports a
fairly wide range of image formats (definitely the common ones:
jpeg, gif, tiff, png) and converting between them (my understanding
is it uses the ImageIO lib that is in the JRE for the reading/saving
part, which in turn uses NIO for fast performance).
As far as the best scaling algorithm that I could find, the best one
was to scale an image down by no more than half of its image size at
a time with a final scaling that would put it in the correct
resolution (that was the method that came up most consistently on
the JAI list when I was reading it). In pseudo-code the basic idea
would be:
Calculate imageScale from current size to final size
While (imageScale < 50%) {
scale image down by 50%
recalculate imageScale from current size to final size
}
Scale image by imageScale
I remember the first time I came across the method I ignored it
because I thought it would take so long to do scaling in multiple
steps, but it is fast. The interpolation method I used when scaling
was bilinear. I found that small details remained intact very well
without odd pixelations. One of the apps I did had professional
photographers projecting the scaled images onto large screens and
looking at them with their clients. If there were issues with the
scaling method I used I think they would have told me.
Another method I read about had to do with blurring the image before
scaling it down once, but blurring was always much slower unless the
image were so small that it was going to be fast even if you did it
using the Java2D lib.
Tom
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On Behalf Of Giancarlo F. Berner
Sent: Tuesday, December 02, 2008 4:01 PM
To: Magnolia Dev-List
Subject: Re: [magnolia-dev] Image (asset/document) management
with Magnolia
Hi Tom
Thanks a lot! Yeah, one approach is to upload images and use
the ImageMagick batch process.
I have spent quite some time on an algorithm for scaling
images in Java. There are many interesting approaches, but none is
complete. The problem is that you need several different "filters"
to complete the scaling and my imaging knowledge is rather limited.
However, I did a lot of experimental work and have a working
solution, but the quality could be better. My "vision" is to have a
class which instantiates the image data and does different
renderings (e.g. rotation, scaling, etc.).
So if there is anyone out there who is wasting brain juice on
the same topic, maybe we could scratch our heads and come up with a
neat Java API.
Thanks for your hint, Tom!
Giancarlo
On Dec 2, 2008, at 2:47 PM, Thomas Duffey wrote:
On Dec 2, 2008, at 4:27 PM, Giancarlo F. Berner wrote:
The real challenge here is to write a image
scaling servlet which renders photoshop quality images!
My suggestion for this part of the problem is to use
ImageMagick (Or GraphicsMagick, if you like) along with
Runtime.exec(). I tried to find something as awesome as ImageMagick
but for Java and came up mostly empty handed. Yes, there is
JMagick, but there are several reasons why you might not want to use
it. Some of those reasons are described here:
http://www.darcynorman.net/2005/03/15/jai-vs-imagemagick-image-resizing/
Good luck!
Tom
On Dec 2, 2008, at 1:21 PM, David Smith wrote:
Speaking from the peanut gallery, I
would prefer the images be
pre-scaled and stored multiple ways
in the DMS myself as it speeds up
rendering to the public. Scaling on
the fly from a single copy to each
client is expensive on system
resources.
--David
Jackson Nicolas wrote:
Hi Ole,
You seem to be receiving a
lot of responses but there's one I would
hope to read but isn't here.
I was expecting that the "Magnolia-way"
would be not store multiple
instances of the same image, but instead
one instance and be able to
deliver multiple instances on request. In
this case, you would not have
to make any changes to the DMS but
instead create a simple
servlet that can deliver varying instances.
Unless you REALLY do have a
valid reason to store multiple instances
of the same image, I don't
see why you should. Since you want to do
the resize on automatically
on the upload anyway, why not do it on the
download. Magnolia is great
with caching so you will only have to
resize once just as you would
with the upload.
I hope this helps.
Best,
Jackson
On Tue, Dec 2, 2008 at 11:35
AM, Ole Christian Rynning <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I am currently in a very
early stage evaluating Magnolia.
I need to import and manage
several thousands of product images
with the WCMS/DMS.
Typically the images are large jpgs, pngs, gifs
and pdfs. When importing I
wish to automatically resize the image
into three sizes:
thumbnail, product and large (+ full).
For this I wish to to
develop a module/template that:
A) Automatically resizes
the images and stores them into the DMS
i.e. under images/products/
name-{thumb,small,large,full} upon
upload/import.
B) A template that allows
the editor to navigate the DMS by
thumbnails, and insert
images with selected size.
Can anybody give me some
general pointers for how to do this (the
magnolia-way!)?
Best regards,
Ole Christian
________________________________
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[EMAIL PROTECTED]
>
----------------------------------------------------------------
________________________________
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[EMAIL PROTECTED]
>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
----------------------------------------------------------------
