Google summer of code and imageio

[Simone.Giannecchini]

Hi lists,
sorry for crossposting but this might be of interest for both lists.

Me and other few guys are working on the imageio-ext project
(https://imageio-ext.dev.java.net/) in order to increase the offer of
plugins for imageio.

This year as part of the Google SoC program we are applying through
geotools in order to fund some development in the raster plugin area (
see http://docs.codehaus.org/display/GEOTOOLS/Summer+of+Code+2008).

Between the various ideas that we have been elaborating there would be
some work directed towards the integration of jmagick plugins under
imageio-ext as ImageIO readers. Note that some experimental work has
been already done in this direction for a simple jpeg reader and the
performances where very good.

Summarising, it would be great if you could circulate this information
to people who might be interested in doing this work under google
funding.


Regards,
Simone.



--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: [phone]
fax: [phone]
mob: [phone]


http://www.geo-solutions.it

-------------------------------------------------------
_______________________________________________
JMagick mailing list
JMagick@...
http://www.yeo.id.au/mailman/listinfo/jmagick
Please ensure that JMagick@... is a recipient when replying.

[Jacob Nordfalk]

Hi,

As the former maintainer of JMagick have resigned I have volunteered
to coordinate the continuation of the JMagick project.

Please note that the newest source code is available at:
 https://sourceforge.net/projects/jmagick/


I think it would be just brilliant if JMagick (JM) could be integrated
into an existing imaging framework, such as the imageio-ext project!

I have several reasons for this:

Remember: JMagick is a 'thin' layer into the core ImageMagick (IM) API.

1) As the IM API is regarded as "somewhat internal" to IM it have
changed over the years. IM claims backwards compatibility but there
have been some incompatibilities anyway and these have been causing
troubles and instabilites for JM users.

2) The IM API is not very intuitive in several ways. Therefore JM is
also a bit hard to get started with and understand.

3) JM MagickImage images are incompatible with standard Java
BufferedImage class.

Therefore it would be fine if a more 'user friendly' way of accessing
JM could be made.

I must confess I dont know very much about the imageio-ext project but
it seems only to promise an intuitive way of reading and writing
images to disk.

Thus, all the other features of IM/JM will not be available by this, I suppose?

Jacob


2008/3/12, Simone Giannecchini <simboss1@...>:

> Hi lists,
>  sorry for crossposting but this might be of interest for both lists.
>
>  Me and other few guys are working on the imageio-ext project
>  (https://imageio-ext.dev.java.net/) in order to increase the offer of
>  plugins for imageio.
>
>  This year as part of the Google SoC program we are applying through
>  geotools in order to fund some development in the raster plugin area (
>  see http://docs.codehaus.org/display/GEOTOOLS/Summer+of+Code+2008).
>
>  Between the various ideas that we have been elaborating there would be
>  some work directed towards the integration of jmagick plugins under
>  imageio-ext as ImageIO readers. Note that some experimental work has
>  been already done in this direction for a simple jpeg reader and the
>  performances where very good.
>
>  Summarising, it would be great if you could circulate this information
>  to people who might be interested in doing this work under google
>  funding.

--
Jacob Nordfalk
http://javabog.dk
Skype: jacobnordfalk
_______________________________________________
JMagick mailing list
JMagick@...
http://www.yeo.id.au/mailman/listinfo/jmagick
Please ensure that JMagick@... is a recipient when replying.

[Bob Friesenhahn]

On Wed, 12 Mar 2008, Jacob Nordfalk wrote:
>
> 2) The IM API is not very intuitive in several ways. Therefore JM is
> also a bit hard to get started with and understand.

The C++ API to ImageMagick and GraphicsMagick is considerably more
intuitive.  It seems reasonable to layer a similar user-friendly
object-oriented interface on top of existing JMagick.  JMagick itself
is not very object-oriented since it seems to be primarily a way to
access the C APIs from Java.

Bob
======================================
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

_______________________________________________
JMagick mailing list
JMagick@...
http://www.yeo.id.au/mailman/listinfo/jmagick
Please ensure that JMagick@... is a recipient when replying.

[Simone.Giannecchini]

Ciao Jacob,
please, read below...

On Wed, Mar 12, 2008 at 7:10 AM, Jacob Nordfalk
<jacob.nordfalk@...> wrote:
> Hi,
>
> As the former maintainer of JMagick have resigned I have volunteered
> to coordinate the continuation of the JMagick project.
>
> Please note that the newest source code is available at:
>  https://sourceforge.net/projects/jmagick/

I have been following the evolution of JMagickm thx :-).
>
>
> I think it would be just brilliant if JMagick (JM) could be integrated
> into an existing imaging framework, such as the imageio-ext project!
>

I have done some quick experiments in order to stick JMagick behind
ImageIO for reading JPEG files.
If you check out the source code for imageio-ext youì'll find a sample
plugin which is pretty basic, but which also shows a lot of potential.
JMagick is able to handle big aerial photography (10 mb) in jpeg quite
smooothly while the SUN plugins chocke right away.
My goal here is to evaluate the status of JMagick (and try to guess
its future :-)) but also, I admit that my hidden desire is to trying
to join a litlle bit the JMagick effort in order to bring it more into
the standard java world which should be imageio-based. Me and Daniele
would be glad to provide some help in order to achieve this but I
think that some of this effort should be provided by the JMagick
community itself. In the end with a little cooperative effort we could
both gain a lot.



> I have several reasons for this:
>
> Remember: JMagick is a 'thin' layer into the core ImageMagick (IM) API.
>
> 1) As the IM API is regarded as "somewhat internal" to IM it have
> changed over the years. IM claims backwards compatibility but there
> have been some incompatibilities anyway and these have been causing
> troubles and instabilites for JM users.
>

I cannot comment on this, I am not much of a JMagic user yet :-).

> 2) The IM API is not very intuitive in several ways. Therefore JM is
> also a bit hard to get started with and understand.
>

Every library has its learning curve.



> 3) JM MagickImage images are incompatible with standard Java
> BufferedImage class.
>
> Therefore it would be fine if a more 'user friendly' way of accessing
> JM could be made.

You can check this class here to have an idea about what we did to try
and convert from JMagick images to imageio.


https://imageio-ext.dev.java.net/source/browse/imageio-ext/trunk/plugin/jmagickjpeg/src/main/java/it/geosolutions/imageio/plugins/jpeg/JpegJMagickImageReader.java?rev=178&view=markup

>
> I must confess I dont know very much about the imageio-ext project but
> it seems only to promise an intuitive way of reading and writing
> images to disk.

imageio-ext aims to extend the sun ImageIO capabilities for image I/O,
hence it is correct  to state that it does only concern with reading
and writing images. Of course JMagick does more, infact I have been
thinking about trying to stick some of the JMagick operations behind
JAI operations; more R&d for the future :-).
For the moment the focus is on having more r&w capabilities especially
where the SUN standard capabilities show some problems (jpeg and png
on big datasets).



>
> Thus, all the other features of IM/JM will not be available by this, I suppose?


See above, JAI si the way to go for this. It is considered good
practice to separate I/O from processing itself hence I am trying to
face one problem at a time. I/O first :-).



I hope to have sparkled some nice discussion here.
Simone.

>
> Jacob
>
>
> 2008/3/12, Simone Giannecchini <simboss1@...>:
>
> > Hi lists,
> >  sorry for crossposting but this might be of interest for both lists.
> >
> >  Me and other few guys are working on the imageio-ext project
> >  (https://imageio-ext.dev.java.net/) in order to increase the offer of
> >  plugins for imageio.
> >
> >  This year as part of the Google SoC program we are applying through
> >  geotools in order to fund some development in the raster plugin area (
> >  see http://docs.codehaus.org/display/GEOTOOLS/Summer+of+Code+2008).
> >
> >  Between the various ideas that we have been elaborating there would be
> >  some work directed towards the integration of jmagick plugins under
> >  imageio-ext as ImageIO readers. Note that some experimental work has
> >  been already done in this direction for a simple jpeg reader and the
> >  performances where very good.
> >
> >  Summarising, it would be great if you could circulate this information
> >  to people who might be interested in doing this work under google
> >  funding.
>
>
> --
> Jacob Nordfalk
> http://javabog.dk
> Skype: jacobnordfalk
>

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: [phone]
fax: [phone]
mob: [phone]


http://www.geo-solutions.it

-------------------------------------------------------

_______________________________________________
JMagick mailing list
JMagick@...
http://www.yeo.id.au/mailman/listinfo/jmagick
Please ensure that JMagick@... is a recipient when replying.

[Simone.Giannecchini]

Ciao Bob,
I must confess that I am not familiar with graphicsmagick.

I quickly scanned the home page for the project and it seems there is
not java wraopper at the moment.
Can you confirm?


Simone.

On Wed, Mar 12, 2008 at 4:40 PM, Bob Friesenhahn
<bfriesen@...> wrote:

> On Wed, 12 Mar 2008, Jacob Nordfalk wrote:
> >
> > 2) The IM API is not very intuitive in several ways. Therefore JM is
> > also a bit hard to get started with and understand.
>
> The C++ API to ImageMagick and GraphicsMagick is considerably more
> intuitive.  It seems reasonable to layer a similar user-friendly
> object-oriented interface on top of existing JMagick.  JMagick itself
> is not very object-oriented since it seems to be primarily a way to
> access the C APIs from Java.
>
> Bob
> ======================================
> Bob Friesenhahn
> bfriesen@..., http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>
>

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: [phone]
fax: [phone]
mob: [phone]


http://www.geo-solutions.it

-------------------------------------------------------
_______________________________________________
JMagick mailing list
JMagick@...
http://www.yeo.id.au/mailman/listinfo/jmagick
Please ensure that JMagick@... is a recipient when replying.

[Bob Friesenhahn]

On Wed, 12 Mar 2008, Simone Giannecchini wrote:
>
> See above, JAI si the way to go for this. It is considered good
> practice to separate I/O from processing itself hence I am trying to
> face one problem at a time. I/O first :-).

It seems that I/O and processing go hand in hand.  Without peaceful
harmony between I/O and processing, the code will "choke" on large
images just like Java's implementation does.

By doing I/O into a "native" Java representation, the image is
duplicated in memory unless ImageMagick is modified to not maintain
its own copy.  If ImageMagick is modified to use the Java
representation, then Java code must act as a "pixel server" to
ImageMagick in case ImageMagick's image processing is desired, and so
that ImageMagick can save the image.

Bob
======================================
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

_______________________________________________
JMagick mailing list
JMagick@...
http://www.yeo.id.au/mailman/listinfo/jmagick
Please ensure that JMagick@... is a recipient when replying.

[Bob Friesenhahn]

On Wed, 12 Mar 2008, Simone Giannecchini wrote:

> Ciao Bob,
> I must confess that I am not familiar with graphicsmagick.

GraphicsMagick is originally derived from ImageMagick.  There was a
time when JMagick could use GraphicsMagick with just a trivial
configure-script change.

> I quickly scanned the home page for the project and it seems there is
> not java wraopper at the moment.
> Can you confirm?

There is not currently a Java wrapper.  I have been hoping for many
years that JMagick will "see the light" and decide to support it.

Bob
======================================
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

_______________________________________________
JMagick mailing list
JMagick@...
http://www.yeo.id.au/mailman/listinfo/jmagick
Please ensure that JMagick@... is a recipient when replying.