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.

[Simone.Giannecchini]

Ciao Harald,
we would definitely be interested in taking a look at your work. We
might actually try to integrate it into imageio-ext and se where to go
from there.

How would you like to proceed?

Regards,
Simone.


On Mon, Mar 24, 2008 at 6:54 PM, Harald Kuhr <harald.kuhr@...> wrote:

> Hi Simone,
>
> On 12. mar. 2008, at 09.15, Simone Giannecchini wrote:
>
> > 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.
>
> I actually took the time to implement an ImageIO wrapper for JMagick
> for use in an internal project some time ago. Unfortunately I have
> never had time to release it, and also have no time to maintain it at
> the moment.
>
> But if you are interested, I'd be happy to submit my sources.
>
> I've implemented wrappers for the following formats:
>
> BMP r/w
> GIF r/w
> ICO r/w
> JPEG2000 r/w
> JPEG r/w
> PCD r
> PCX r/w
> PNG r/w
> PNM r
> PSD r
> SWF r
> Targa r/w
> WBMP r/w
> WMF r
> XBM r/w
> XPM r/w
>
> My main focus was to allow reading a lot of formats, so performance
> may be less than ideal, but it's quite ok I think.
> Also, the focus was pure reading/writing of pixel data, so some
> ImageIO features are not implemented, like meta data, tiled reading
> etc., some only partial, like progress.
>
> Let me know if you are interested!
>
>
> Regards,
>
> --
> Harald K
>

--
-------------------------------------------------------
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]

Sounds great if we could get this working.

Wouldn't it be best if the jmagick-imageio-ext code was bundled with
JMagick and you
had write access to the JM CVS repository?

It would be heavily dependent of JM anyway and it doesent as far as I
understand the
imageio-ext project (is this correct?).

Jacob


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

> Ciao Harald,
>  we would definitely be interested in taking a look at your work. We
>  might actually try to integrate it into imageio-ext and se where to go
>  from there.
>
>  How would you like to proceed?
>
>  Regards,
>  Simone.
>
>
>  On Mon, Mar 24, 2008 at 6:54 PM, Harald Kuhr <harald.kuhr@...> wrote:
>  > Hi Simone,
>
> >
>  > On 12. mar. 2008, at 09.15, Simone Giannecchini wrote:
>  >
>  > > 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.
>  >
>
> > I actually took the time to implement an ImageIO wrapper for JMagick
>  > for use in an internal project some time ago. Unfortunately I have
>  > never had time to release it, and also have no time to maintain it at
>  > the moment.
>  >
>  > But if you are interested, I'd be happy to submit my sources.
>  >
>  > I've implemented wrappers for the following formats:
>  >
>  > BMP r/w
>  > GIF r/w
>  > ICO r/w
>  > JPEG2000 r/w
>  > JPEG r/w
>  > PCD r
>  > PCX r/w
>  > PNG r/w
>  > PNM r
>  > PSD r
>  > SWF r
>  > Targa r/w
>  > WBMP r/w
>  > WMF r
>  > XBM r/w
>  > XPM r/w
>  >
>  > My main focus was to allow reading a lot of formats, so performance
>  > may be less than ideal, but it's quite ok I think.
>  > Also, the focus was pure reading/writing of pixel data, so some
>  > ImageIO features are not implemented, like meta data, tiled reading
>  > etc., some only partial, like progress.
>  >
>  > Let me know if you are interested!
>  >
>  >
>  > Regards,
>  >
>  > --
>  > Harald K
>  >
>
>
>
>
>  --
>
> -------------------------------------------------------
>  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
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.

[Simone.Giannecchini]

Ciao Jacob,
basically, Imageio-ext is a java project extending Java Sun's ImageI/O
framework capabilities. It is composed of several modules adding
specific features to ImageI/O like, as an instance, supporting more
raster data access capabilities and providing multithreading imageread
operation. It is an integration framework which aims to extend the
basic imageio capabilities for java.
The main module of the project is gdalframework, a framework
leveraging on GDAL to get access to a wide range of raster data
formats, mainly used in the geospatial world.
ImageIO-ext contains an experimental Jpeg plugin leveraging on
Jmagick, which was used to demontrate that imageio-ext could help with
integrating/exposing jmaigck using standard imageio capabilities.

Conclusion is, I think it would great integrating the JMagick
capabilities into imageio-ext in order to access formats like jpeg and
png in a more performant way. I am not sure it would make sense to put
imageio-ext inside jmagick :-).

My suggestion would be creating a module specific for JMAGICK which
would handle most part of the mechanics plus some plugins for the
formats we want to support and the support for metadata we want to
implement (not much at the beginning I guess :-)).

What do you think?
Simone.

On Wed, Mar 26, 2008 at 6:03 AM, Jacob Nordfalk
<jacob.nordfalk@...> wrote:

> Sounds great if we could get this working.
>
> Wouldn't it be best if the jmagick-imageio-ext code was bundled with
> JMagick and you
> had write access to the JM CVS repository?
>
> It would be heavily dependent of JM anyway and it doesent as far as I
> understand the
> imageio-ext project (is this correct?).
>
> Jacob
>
>
> 2008/3/25, Simone Giannecchini <simboss1@...>:
>
> > Ciao Harald,
> >  we would definitely be interested in taking a look at your work. We
> >  might actually try to integrate it into imageio-ext and se where to go
> >  from there.
> >
> >  How would you like to proceed?
> >
> >  Regards,
> >  Simone.
> >
> >
> >  On Mon, Mar 24, 2008 at 6:54 PM, Harald Kuhr <harald.kuhr@...> wrote:
> >  > Hi Simone,
> >
> > >
> >  > On 12. mar. 2008, at 09.15, Simone Giannecchini wrote:
> >  >
> >  > > 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.
> >  >
> >
> > > I actually took the time to implement an ImageIO wrapper for JMagick
> >  > for use in an internal project some time ago. Unfortunately I have
> >  > never had time to release it, and also have no time to maintain it at
> >  > the moment.
> >  >
> >  > But if you are interested, I'd be happy to submit my sources.
> >  >
> >  > I've implemented wrappers for the following formats:
> >  >
> >  > BMP r/w
> >  > GIF r/w
> >  > ICO r/w
> >  > JPEG2000 r/w
> >  > JPEG r/w
> >  > PCD r
> >  > PCX r/w
> >  > PNG r/w
> >  > PNM r
> >  > PSD r
> >  > SWF r
> >  > Targa r/w
> >  > WBMP r/w
> >  > WMF r
> >  > XBM r/w
> >  > XPM r/w
> >  >
> >  > My main focus was to allow reading a lot of formats, so performance
> >  > may be less than ideal, but it's quite ok I think.
> >  > Also, the focus was pure reading/writing of pixel data, so some
> >  > ImageIO features are not implemented, like meta data, tiled reading
> >  > etc., some only partial, like progress.
> >  >
> >  > Let me know if you are interested!
> >  >
> >  >
> >  > Regards,
> >  >
> >  > --
> >  > Harald K
> >  >
> >
> >
> >
> >
> >  --
> >
> > -------------------------------------------------------
> >  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
> 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.

[Bob Friesenhahn]

On Wed, 26 Mar 2008, Simone Giannecchini wrote:
> My suggestion would be creating a module specific for JMAGICK which
> would handle most part of the mechanics plus some plugins for the
> formats we want to support and the support for metadata we want to
> implement (not much at the beginning I guess :-)).

An approach would be to re-implement ImageMagick "pixel cache" storage
in Java.  ImageMagick would then invoke a callback to "persist" any
pixels which are read in a native Java image.  When writing,
ImageMagick would invoke a callback to retrieve the pixels to write.
While processing an image, ImageMagick would use the same callbacks to
retrieve and store pixels.  Since Java would need to copy the pixels,
there would be some added overhead.

There is already a "pixel stream" interface in ImageMagick which
exposes some of this, but unfortunately, it still stores its own
pixels, which doubles memory requirements.

This approach assumes that the images are not too large for Java to be
able to allocate memory for them.

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.

[Harald Kuhr]

Hi again!

Sorry, have had limitted time/net access lately.

I've been thinking about it though, and I've come to the conclusion  
that I would like to keep the code under BSD license. Would that be  
possible for you? Maybe it would be better to start a new ImageIO sub-
project?

I also have source code available for a Jimi wrapper for ImageIO that  
could be made part of that same project. Format support is probably  
not as good as JMagick, but it has support for Photoshop format,  
which is nice. I also have a couple of other (arcane) formats  
available which might be useful for someone other than me. ;-)

What do you think would be the best approach?


Regards,


--
Harald K

On 25. mar. 2008, at 16.26, Simone Giannecchini wrote:

> Ciao Harald,
> we would definitely be interested in taking a look at your work. We
> might actually try to integrate it into imageio-ext and se where to go
> from there.
>
> How would you like to proceed?
>
> Regards,
> Simone.
>

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

[Harald Kuhr]

On 26. mar. 2008, at 17.47, Bob Friesenhahn wrote:

> An approach would be to re-implement ImageMagick "pixel cache" storage
> in Java.  ImageMagick would then invoke a callback to "persist" any
> pixels which are read in a native Java image.  When writing,
> ImageMagick would invoke a callback to retrieve the pixels to write.
> While processing an image, ImageMagick would use the same callbacks to
> retrieve and store pixels.  Since Java would need to copy the pixels,
> there would be some added overhead.
>
> There is already a "pixel stream" interface in ImageMagick which
> exposes some of this, but unfortunately, it still stores its own
> pixels, which doubles memory requirements.
>
> This approach assumes that the images are not too large for Java to be
> able to allocate memory for them.

I'm currently using the MagickImage.dispatchImage method from  
JMagick, to get the raw pixel data to Java (in a format compatible  
with the BufferedImage types). I then create a data buffer "around"  
that array, and create a BuffereImage directly from it.

This approach has a more than okay performance for my needs, but it  
does of course need memory for the pixel data in both native and Java  
sides. And it could probably be done faster, especially if it would  
be possible to hook directly into the memory of ImageMagick, or have  
ImageMagick write directly to Java memory. Don't know enough about  
the internal workings of ImageMagick to help with any ot that though...


Regards,

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