Skip to main content

[JAI-IMAGEIO] Mac OS X native version of JIIO

29 replies [Last post]
Anonymous

Hello there.

I would appreciate if someone at Sun could provide a rough estimate of when
a Mac OS X version of the JAI Image I/O native libraries could become
available (see Issue # 103 on the jiio-core subproject).
This information would really help in planning some developments.

Thank you in advance.

Regards,

Marco.

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Simone Giannecchini

Have you seen this?

http://kenai.com/projects/openmlib/

Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini

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

On Thu, Jun 18, 2009 at 6:06 PM, Marco Sambin -
NeoLogica wrote:
> No news, at least that I am aware of, unfortunately.
>
> As far as I know, the same (i.e., "no news") holds true for the Windows x64
> version of the native libs. I think this would be just a matter of
> recompiling the libs with the appropriate build flags and options, but it is
> A LOT of time we are wating for these builds, and I have lost my faith about
> it...
> Unfortunately, I do not know of any other Java codecs supporting lossy and
> lossless JPEGs with grayscale depths of up to 16 bits, that is what I need.
> So I am a bit at loss...
>
> Any comment on this will be appreciated.
>
> Best regards,
>
> Marco.
>
>
>> -----Original Message-----
>> From: jai-imageio@javadesktop.org
>> [mailto:jai-imageio@javadesktop.org]
>> Sent: giovedì 18 giugno 2009 17.28
>> To: interest@jai-imageio.dev.java.net
>> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>>
>> Has there been any news or related workarounds for JPEG
>> codecs in JIIO on Mac OS X? We are looking into SWT from
>> Eclipse currently as a pure Java solution. It would be nice
>> to know about all solutions though.
>>
>> Greg
>> [Message sent by forum member 'gsmethells' (gsmethells)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=351857
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail:
>> interest-help@jai-imageio.dev.java.net
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Marco Sambin - NeoLogica

Hi Simone,

thanks a lot for pointing us to the openmlib project, that I wasn't aware
of.
Nevertheless, after giving a first (fast...) look at the source directories,
it seems to me that the openmlib project does not include codecs (for
instance, JPEG codecs) right now. Can you confirm?

Thanks and regards,

Marco.

> -----Original Message-----
> From: Simone Giannecchini [mailto:simboss1@gmail.com]
> Sent: giovedì 18 giugno 2009 19.24
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>
> Have you seen this?
>
> http://kenai.com/projects/openmlib/
>
>
> Simone.
> -------------------------------------------------------
> Ing. Simone Giannecchini
> GeoSolutions S.A.S.
> Owner - Software Engineer
> Via Carignoni 51
> 55041 Camaiore (LU)
> Italy
>
> phone: +39 0584983027
> fax: +39 0584983027
> mob: +39 333 8128928
>
>
> http://www.geo-solutions.it
> http://simboss.blogspot.com/
> http://www.linkedin.com/in/simonegiannecchini
>
> -------------------------------------------------------
>
>
>
> On Thu, Jun 18, 2009 at 6:06 PM, Marco Sambin -
> NeoLogica wrote:
> > No news, at least that I am aware of, unfortunately.
> >
> > As far as I know, the same (i.e., "no news") holds true for the
> > Windows x64 version of the native libs. I think this would
> be just a
> > matter of recompiling the libs with the appropriate build flags and
> > options, but it is A LOT of time we are wating for these
> builds, and I
> > have lost my faith about it...
> > Unfortunately, I do not know of any other Java codecs
> supporting lossy
> > and lossless JPEGs with grayscale depths of up to 16 bits,
> that is what I need.
> > So I am a bit at loss...
> >
> > Any comment on this will be appreciated.
> >
> > Best regards,
> >
> > Marco.
> >
> >
> >> -----Original Message-----
> >> From: jai-imageio@javadesktop.org
> >> [mailto:jai-imageio@javadesktop.org]
> >> Sent: giovedì 18 giugno 2009 17.28
> >> To: interest@jai-imageio.dev.java.net
> >> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
> >>
> >> Has there been any news or related workarounds for JPEG codecs in
> >> JIIO on Mac OS X? We are looking into SWT from Eclipse
> currently as a
> >> pure Java solution. It would be nice to know about all solutions
> >> though.
> >>
> >> Greg
> >> [Message sent by forum member 'gsmethells' (gsmethells)]
> >>
> >> http://forums.java.net/jive/thread.jspa?messageID=351857
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> interest-unsubscribe@jai-imageio.dev.java.net
> >> For additional commands, e-mail:
> >> interest-help@jai-imageio.dev.java.net
> >>
> >>
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> interest-unsubscribe@jai-imageio.dev.java.net
> > For additional commands, e-mail:
> > interest-help@jai-imageio.dev.java.net
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

James Cheng

Hi Marco,

I can confirm that the openmlib project doesn't include a JPEG codec
although it has functions that can be used to speed up JPEG codecs.
And, it doesn't include mediaLib's Java wrapper at this moment.

I wish I could give you an update on the native support for Mac OS X,
but I can't.

Regards,
-James

On 06/19/09 01:13 AM, Marco Sambin - NeoLogica wrote:
> Hi Simone,
>
> thanks a lot for pointing us to the openmlib project, that I wasn't aware
> of.
> Nevertheless, after giving a first (fast...) look at the source directories,
> it seems to me that the openmlib project does not include codecs (for
> instance, JPEG codecs) right now. Can you confirm?
>
> Thanks and regards,
>
> Marco.
>
>
>> -----Original Message-----
>> From: Simone Giannecchini [mailto:simboss1@gmail.com]
>> Sent: giovedì 18 giugno 2009 19.24
>> To: interest@jai-imageio.dev.java.net
>> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>>
>> Have you seen this?
>>
>> http://kenai.com/projects/openmlib/
>>
>>
>> Simone.

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

gsmethells
Offline
Joined: 2009-06-18
Points: 0

Has there been any news or related workarounds for JPEG codecs in JIIO on Mac OS X? We are looking into SWT from Eclipse currently as a pure Java solution. It would be nice to know about all solutions though.

Greg

Marco Sambin - NeoLogica

No news, at least that I am aware of, unfortunately.

As far as I know, the same (i.e., "no news") holds true for the Windows x64
version of the native libs. I think this would be just a matter of
recompiling the libs with the appropriate build flags and options, but it is
A LOT of time we are wating for these builds, and I have lost my faith about
it...
Unfortunately, I do not know of any other Java codecs supporting lossy and
lossless JPEGs with grayscale depths of up to 16 bits, that is what I need.
So I am a bit at loss...

Any comment on this will be appreciated.

Best regards,

Marco.

> -----Original Message-----
> From: jai-imageio@javadesktop.org
> [mailto:jai-imageio@javadesktop.org]
> Sent: giovedì 18 giugno 2009 17.28
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>
> Has there been any news or related workarounds for JPEG
> codecs in JIIO on Mac OS X? We are looking into SWT from
> Eclipse currently as a pure Java solution. It would be nice
> to know about all solutions though.
>
> Greg
> [Message sent by forum member 'gsmethells' (gsmethells)]
>
> http://forums.java.net/jive/thread.jspa?messageID=351857
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Adam Augusta

Agreed. We've been forced to begin migrating our imaging project to
another library for these reasons.

On Thu, Jun 18, 2009 at 12:06 PM, Marco Sambin -
NeoLogica wrote:
> No news, at least that I am aware of, unfortunately.
>
> As far as I know, the same (i.e., "no news") holds true for the Windows x64
> version of the native libs. I think this would be just a matter of
> recompiling the libs with the appropriate build flags and options, but it is
> A LOT of time we are wating for these builds, and I have lost my faith about
> it...
> Unfortunately, I do not know of any other Java codecs supporting lossy and
> lossless JPEGs with grayscale depths of up to 16 bits, that is what I need.
> So I am a bit at loss...
>
> Any comment on this will be appreciated.
>
> Best regards,
>
> Marco.
>
>
>> -----Original Message-----
>> From: jai-imageio@javadesktop.org
>> [mailto:jai-imageio@javadesktop.org]
>> Sent: giovedì 18 giugno 2009 17.28
>> To: interest@jai-imageio.dev.java.net
>> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>>
>> Has there been any news or related workarounds for JPEG
>> codecs in JIIO on Mac OS X? We are looking into SWT from
>> Eclipse currently as a pure Java solution. It would be nice
>> to know about all solutions though.
>>
>> Greg
>> [Message sent by forum member 'gsmethells' (gsmethells)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=351857
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
>> For additional commands, e-mail:
>> interest-help@jai-imageio.dev.java.net
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Fabrizio Giudici

On 05/feb/08, at 09:47, Marco Sambin - NeoLogica wrote:

> Hi Joe,
>
> if I remember correctly, the last official answer about the Mac OS
> X native
> version of JIIO library was that "the development was stuck due to
> non-technical reasons".
> May we know if these "non-technical reasons" are somehow related to
> licensing issues with Apple?
>
> Regards,
>
> Marco.

In other words: forget it. It's best to lobby Sun for take care of
the porting.

--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941

[att1.html]

Marco Sambin - NeoLogica

Hi Fabrizio,

actually the explanation "the development of the Mac OS X native version of
JIIO is stuck due to non-technical reasons" came from the Sun development
team (not from Apple), so I asked if those "non-technical reasons" were due
to licensing issues towards Apple, which is blocking Sun from developing the
Mac OS X native version themselves.

Regards,

Marco.

_____

From: Fabrizio Giudici [mailto:fabrizio.giudici@tidalwave.it]
Sent: mercoledì 6 febbraio 2008 9.05
To: interest@jai-imageio.dev.java.net
Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO

On 05/feb/08, at 09:47, Marco Sambin - NeoLogica wrote:

Hi Joe,

if I remember correctly, the last official answer about the Mac OS X native
version of JIIO library was that "the development was stuck due to
non-technical reasons".
May we know if these "non-technical reasons" are somehow related to
licensing issues with Apple?

Regards,

Marco.

In other words: forget it. It's best to lobby Sun for take care of the
porting.

--

Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941

[att1.html]

joe40
Offline
Joined: 2008-02-04
Points: 0

Marco-
Did you or Fabrizio ever get any more information regarding this topic/issue?
Seems like we are still waiting....

Regards,

Joe40

Fabrizio Giudici

On Aug 6, 2008, at 21:38 , jai-imageio@javadesktop.org wrote:

> Marco-
> Did you or Fabrizio ever get any more information regarding this
> topic/issue?
> Seems like we are still waiting....

No news that I'm aware of - unfortunately :-(

--
Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Marco Sambin - NeoLogica

Unfortunately, the same holds true for me as well: no news that I am aware
of.

As I mentioned in previous posts, a full pure-Java implementation of ALL
JIIO codecs (including lossless JPEG) would be an acceptable alternative to
a Mac OS X native version of JIIO, at least for our purposes. Things may be
different for other developers, but I think "available functionality" comes
before "high performance". Of course, having the two would be optimal...

Trustfully waiting for good news...

Regards,

Marco.

> -----Original Message-----
> From: Fabrizio Giudici [mailto:fabrizio.giudici@tidalwave.it]
> Sent: mercoledì 6 agosto 2008 21.32
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>
>
> On Aug 6, 2008, at 21:38 , jai-imageio@javadesktop.org wrote:
>
> > Marco-
> > Did you or Fabrizio ever get any more information regarding this
> > topic/issue?
> > Seems like we are still waiting....
>
>
> No news that I'm aware of - unfortunately :-(
>
> --
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
> Fabrizio.Giudici@tidalwave.it - mobile: +39 348.150.6941
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

carmeyer
Offline
Joined: 2008-03-10
Points: 0

Sorry, I see that your post is quite old.

I would be very interested in getting a Java implementation of the formats you mentioned.
Is there any work going on in this direction?

Thanks,
Carsten

Marco Sambin - NeoLogica

Hi Brian,

thank you for providing some news (even though bad :-( ) on this subject.
Actually, for my individual needs, the most annoying part of JIIO on Mac is
not the lack of native acceleration, but just the lack of support for the
JPEG formats that you outlined in your message reported below (12-bit lossy
JPEG, Lossless JPEG, JPEG-LS).

As you probably know, these formats are all very popular in medical imaging,
and this makes almost impossible to deploy a medical JAI / JIIO - based
application on Mac OS X. And it is really a pity.

A possible alternative would be to provide a pure-Java implementation of
those missing image decoders... Not sure if it is a feasible way.

Marco.

> -----Original Message-----
> From: jai-imageio@javadesktop.org
> [mailto:jai-imageio@javadesktop.org]
> Sent: venerdì 2 novembre 2007 23.35
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>
> > I think we (the community) should be able to provide a "generic"
> > native library that could be compiled on any OS for many of
> the native
> > codecs.
>
> The plugin architecture permits this of course.
>
> > I am thinking the most common case, which is the TIFF bilevel
> > compressor/decompressor.
>
> I suppose that depends on the application's use cases.
>
> > I also think libjpeg would work for the jpeg stuff.
> > Not sure about
> > jpeg 2000.
>
> To reiterate, the native layer provides the following:
>
> 1. Features
>
> 12-bit lossy JPEG
> Lossless JPEG
> JPEG-LS
>
> 2. Acceleration
>
> JPEG
> JPEG2000
> PNG
> TIFF bilevel encodings
>
> > You should definitely test the speed difference though in your
> > particular case. We have found that the pure Java version is as fast
> > - IF NOT FASTER - than the native version, as it avoids the JNI
> > overhead - this is especially true when using the latest JVMs.
>
> That is absolutely correct. I would expect the discrepancy to
> increase with the size of the image or the image tiles as the
> case may be.
> [Message sent by forum member 'bpb' (bpb)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243609
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

bpb
Offline
Joined: 2004-06-23
Points: 0

We would be interested in others viewpoints on this issue. Would Java implementations of these other formats (12-bit lossy, lossless, and JPEG-LS) suffice?

Brian

> thank you for providing some news (even though bad
> :-( ) on this subject.
> Actually, for my individual needs, the most annoying
> part of JIIO on Mac is
> not the lack of native acceleration, but just the
> lack of support for the
> JPEG formats that you outlined in your message
> reported below (12-bit lossy
> JPEG, Lossless JPEG, JPEG-LS).
>
> As you probably know, these formats are all very
> popular in medical imaging,
> and this makes almost impossible to deploy a medical
> JAI / JIIO - based
> application on Mac OS X. And it is really a pity.
>
> A possible alternative would be to provide a
> pure-Java implementation of
> those missing image decoders... Not sure if it is a
> feasible way.

Bob Deen

jai-imageio@javadesktop.org wrote:
> We would be interested in others viewpoints on this issue. Would Java implementations of these other formats (12-bit lossy, lossless, and JPEG-LS) suffice?

As an alternative to nothing??! Heck yeah!

It's not all that hard to make a mac native library though, so I'd be
surprised if that approach were easier.

-Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

bpb
Offline
Joined: 2004-06-23
Points: 0

> jai-imageio@javadesktop.org wrote:
> > We would be interested in others viewpoints on this
> issue. Would Java implementations of these other
> formats (12-bit lossy, lossless, and JPEG-LS)
> suffice?
>
> As an alternative to nothing??! Heck yeah!
>
> It's not all that hard to make a mac native library
> though, so I'd be
> surprised if that approach were easier.

It would definitely be more difficult and some might say stupid.

robert engels

We can also use the "shell" java plugins for these codecs that are
already written - basically change the native calls.

Since this code has been released to the public.

Correct?

On Nov 2, 2007, at 4:34 PM, jai-imageio@javadesktop.org wrote:

>> I think we (the community) should be able to provide
>> a "generic"
>> native library that could be compiled on any OS for
>> many of the
>> native codecs.
>
> The plugin architecture permits this of course.
>
>> I am thinking the most common case, which is the TIFF
>> bilevel
>> compressor/decompressor.
>
> I suppose that depends on the application's use cases.
>
>> I also think libjpeg would work for the jpeg stuff.
>> Not sure about
>> jpeg 2000.
>
> To reiterate, the native layer provides the following:
>
> 1. Features
>
> 12-bit lossy JPEG
> Lossless JPEG
> JPEG-LS
>
> 2. Acceleration
>
> JPEG
> JPEG2000
> PNG
> TIFF bilevel encodings
>
>> You should definitely test the speed difference
>> though in your
>> particular case. We have found that the pure Java
>> version is as fast
>> - IF NOT FASTER - than the native version, as it
>> avoids the JNI
>> overhead - this is especially true when using the
>> latest JVMs.
>
> That is absolutely correct. I would expect the discrepancy to
> increase with the size of the image or the image tiles as the case
> may be.
> [Message sent by forum member 'bpb' (bpb)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243609
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Marco Sambin - NeoLogica

Hi Brian,

a question came to my mind while reviewing the issue related to providing a
Mac-native version of JAI Image I/O Tools libraries. What does the "Status:
STARTED" mean on issue # 103 of the jai-imageio-core project
(https://jai-imageio-core.dev.java.net/issues/show_bug.cgi?id=103)? In a
recent message, you told that currently there is no plan to provide a Mac OS
X build of the JIIO native libs; so, why is this issue flagged as "STARTED"?
Also, you told that this development is currently stuck due to non-technical
decision: could we (i.e., the developers / users community) do anything to
change this non-technical decision?

Mac OS X is becoming quite a popular platform for medical imaging
applications, and the lack of some important JIIO image codecs under Mac OS
X currently cuts off the Java technology from this field and environment.

Your comments would be greatly appreciated.

Best regards,

Marco.

> -----Original Message-----
> From: jai-imageio@javadesktop.org
> [mailto:jai-imageio@javadesktop.org]
> Sent: venerdì 2 novembre 2007 23.20
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>
> Marco,
>
> I apologize for the ridiculously belated response to this question.
>
> > I would appreciate if someone at Sun could provide a rough
> estimate of
> > when a Mac OS X version of the JAI Image I/O native libraries could
> > become available (see Issue # 103 on the jiio-core subproject).
>
> At this time there is no plan to provide a Mac OS X build of
> the native components of JAI Image I/O Tools. Note that this
> state of affairs is the result of a non-technical decision
> which could change at any indefinite point in the future. If
> that occurs the Image I/O community will be apprised of the
> change as soon as practicable.
>
> > This information would really help in planning some developments.
> >
> > Thank you in advance.
>
> I am sorry that I do not have more positive news to impart right now.
>
> Brian
> [Message sent by forum member 'bpb' (bpb)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243605
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

bpb
Offline
Joined: 2004-06-23
Points: 0

Hi Marco,

> a question came to my mind while reviewing the issue
> related to providing a
> Mac-native version of JAI Image I/O Tools libraries.
> What does the "Status:
> STARTED" mean on issue # 103 of the jai-imageio-core
> project
> (https://jai-imageio-core.dev.java.net/issues/show_bug
> .cgi?id=103)?

"Started" serves to indicate that the bug is accepted.

> In a
> recent message, you told that currently there is no
> plan to provide a Mac OS
> X build of the JIIO native libs; so, why is this
> issue flagged as "STARTED"?
> Also, you told that this development is currently
> stuck due to non-technical
> decision: could we (i.e., the developers / users
> community) do anything to
> change this non-technical decision?

At this point probably not.

> Mac OS X is becoming quite a popular platform for
> medical imaging
> applications, and the lack of some important JIIO
> image codecs under Mac OS
> X currently cuts off the Java technology from this
> field and environment.

We on the imaging team appreciate the situation but cannot do anything about it from a technical point of view at this time.

Regards,

Brian

> Your comments would be greatly appreciated.
>
> Best regards,
>
> Marco.
>
>
>
> > -----Original Message-----
> > From: jai-imageio@javadesktop.org
> > [mailto:jai-imageio@javadesktop.org]
> > Sent: venerdì 2 novembre 2007 23.20
> > To: interest@jai-imageio.dev.java.net
> > Subject: Re: [JAI-IMAGEIO] Mac OS X native version
> of JIIO
> >
> > Marco,
> >
> > I apologize for the ridiculously belated response
> to this question.
> >
> > > I would appreciate if someone at Sun could
> provide a rough
> > estimate of
> > > when a Mac OS X version of the JAI Image I/O
> native libraries could
> > > become available (see Issue # 103 on the
> jiio-core subproject).
> >
> > At this time there is no plan to provide a Mac OS X
> build of
> > the native components of JAI Image I/O Tools. Note
> that this
> > state of affairs is the result of a non-technical
> decision
> > which could change at any indefinite point in the
> future. If
> > that occurs the Image I/O community will be
> apprised of the
> > change as soon as practicable.
> >
> > > This information would really help in planning
> some developments.
> > >
> > > Thank you in advance.
> >
> > I am sorry that I do not have more positive news to
> impart right now.
> >
> > Brian
> > [Message sent by forum member 'bpb' (bpb)]
> >
> >
> http://forums.java.net/jive/thread.jspa?messageID=2436
> 05
> >
> >
> ------------------------------------------------------
> ---------------
> > To unsubscribe, e-mail:
> interest-unsubscribe@jai-imageio.dev.java.net
> > For additional commands, e-mail:
> > interest-help@jai-imageio.dev.java.net
> >
> >
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net

joe40
Offline
Joined: 2008-02-04
Points: 0

Marco-
Have there been any 'updates' that you are aware of with regard to this issue?
I too would like to see the native libraries made available so that compression could be enabled for Mac OS X based systems that run dcm4chee Dicom PACS.

Rgards,

Joe40

Marco Sambin - NeoLogica

Hi Joe,

if I remember correctly, the last official answer about the Mac OS X native
version of JIIO library was that "the development was stuck due to
non-technical reasons".
May we know if these "non-technical reasons" are somehow related to
licensing issues with Apple?

Regards,

Marco.

> -----Original Message-----
> From: jai-imageio@javadesktop.org
> [mailto:jai-imageio@javadesktop.org]
> Sent: martedì 5 febbraio 2008 8.48
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Mac OS X native version of JIIO
>
> Marco-
> Have there been any 'updates' that you are aware of with
> regard to this issue?
> I too would like to see the native libraries made available
> so that compression could be enabled for Mac OS X based
> systems that run dcm4chee Dicom PACS.
>
> Rgards,
>
> Joe40
> [Message sent by forum member 'joe40' (joe40)]
>
> http://forums.java.net/jive/thread.jspa?messageID=257392
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

bpb
Offline
Joined: 2004-06-23
Points: 0

Marco,

I apologize for the ridiculously belated response to this question.

> I would appreciate if someone at Sun could provide a
> rough estimate of when
> a Mac OS X version of the JAI Image I/O native
> libraries could become
> available (see Issue # 103 on the jiio-core
> subproject).

At this time there is no plan to provide a Mac OS X build of the native components of JAI Image I/O Tools. Note that this state of affairs is the result of a non-technical decision which could change at any indefinite point in the future. If that occurs the Image I/O community will be apprised of the change as soon as practicable.

> This information would really help in planning some
> developments.
>
> Thank you in advance.

I am sorry that I do not have more positive news to impart right now.

Brian

robert engels

I think we (the community) should be able to provide a "generic"
native library that could be compiled on any OS for many of the
native codecs.

I am thinking the most common case, which is the TIFF bilevel
compressor/decompressor.

I also think libjpeg would work for the jpeg stuff. Not sure about
jpeg 2000.

You should definitely test the speed difference though in your
particular case. We have found that the pure Java version is as fast
- IF NOT FASTER - than the native version, as it avoids the JNI
overhead - this is especially true when using the latest JVMs.

On Nov 2, 2007, at 4:19 PM, jai-imageio@javadesktop.org wrote:

> Marco,
>
> I apologize for the ridiculously belated response to this question.
>
>> I would appreciate if someone at Sun could provide a
>> rough estimate of when
>> a Mac OS X version of the JAI Image I/O native
>> libraries could become
>> available (see Issue # 103 on the jiio-core
>> subproject).
>
> At this time there is no plan to provide a Mac OS X build of the
> native components of JAI Image I/O Tools. Note that this state of
> affairs is the result of a non-technical decision which could
> change at any indefinite point in the future. If that occurs the
> Image I/O community will be apprised of the change as soon as
> practicable.
>
>> This information would really help in planning some
>> developments.
>>
>> Thank you in advance.
>
> I am sorry that I do not have more positive news to impart right now.
>
> Brian
> [Message sent by forum member 'bpb' (bpb)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243605
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

bpb
Offline
Joined: 2004-06-23
Points: 0

> I think we (the community) should be able to provide
> a "generic"
> native library that could be compiled on any OS for
> many of the
> native codecs.

The plugin architecture permits this of course.

> I am thinking the most common case, which is the TIFF
> bilevel
> compressor/decompressor.

I suppose that depends on the application's use cases.

> I also think libjpeg would work for the jpeg stuff.
> Not sure about
> jpeg 2000.

To reiterate, the native layer provides the following:

1. Features

12-bit lossy JPEG
Lossless JPEG
JPEG-LS

2. Acceleration

JPEG
JPEG2000
PNG
TIFF bilevel encodings

> You should definitely test the speed difference
> though in your
> particular case. We have found that the pure Java
> version is as fast
> - IF NOT FASTER - than the native version, as it
> avoids the JNI
> overhead - this is especially true when using the
> latest JVMs.

That is absolutely correct. I would expect the discrepancy to increase with the size of the image or the image tiles as the case may be.

robert engels

I also think this would be a perfect time to drop the stupid XML
based metadata with ImageIO. This is by far the hardest/time
consuming things about writing plugins.

Let's start by defining our own interface for the standard metadata
(with a default impl that can read the standard xml/metadata), and
then custom interfaces for the formats.

Like:

interface StandardMetadata {
int getWidth();
int getHeight();
int getHDPI();
int getVDPI();
...
}

On Nov 2, 2007, at 4:34 PM, jai-imageio@javadesktop.org wrote:

>> I think we (the community) should be able to provide
>> a "generic"
>> native library that could be compiled on any OS for
>> many of the
>> native codecs.
>
> The plugin architecture permits this of course.
>
>> I am thinking the most common case, which is the TIFF
>> bilevel
>> compressor/decompressor.
>
> I suppose that depends on the application's use cases.
>
>> I also think libjpeg would work for the jpeg stuff.
>> Not sure about
>> jpeg 2000.
>
> To reiterate, the native layer provides the following:
>
> 1. Features
>
> 12-bit lossy JPEG
> Lossless JPEG
> JPEG-LS
>
> 2. Acceleration
>
> JPEG
> JPEG2000
> PNG
> TIFF bilevel encodings
>
>> You should definitely test the speed difference
>> though in your
>> particular case. We have found that the pure Java
>> version is as fast
>> - IF NOT FASTER - than the native version, as it
>> avoids the JNI
>> overhead - this is especially true when using the
>> latest JVMs.
>
> That is absolutely correct. I would expect the discrepancy to
> increase with the size of the image or the image tiles as the case
> may be.
> [Message sent by forum member 'bpb' (bpb)]
>
> http://forums.java.net/jive/thread.jspa?messageID=243609
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Bob Deen

robert engels wrote:
> I also think this would be a perfect time to drop the stupid XML based
> metadata with ImageIO. This is by far the hardest/time consuming things
> about writing plugins.
>
> Let's start by defining our own interface for the standard metadata
> (with a default impl that can read the standard xml/metadata), and then
> custom interfaces for the formats.
>
> Like:
>
> interface StandardMetadata {
> int getWidth();
> int getHeight();
> int getHDPI();
> int getVDPI();
> ...
> }

The problem of course is that the plugins are written to be as format-
neutral as possible. That's why the XML-based metadata exists... it
allows one to accommodate a nearly arbitrary metadata content without
any API change. Changing that fundamental philosophy would I think
be a bad idea.

However, there is definite value in having a convenience layer... something
that takes common calls like you have in your example and translates
to/from the underlying XML. Hide all that nastiness from the casual
user, although the nastiness is still there for those who need it.

-Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

robert engels

I don't think you are correct.

Since the consumer needs to "know" what is in the proprietary
metadata in order to "use" it - other than a simple name/value
display - unless you possibly make an assumption based upon the tag
name and/or value. The proprietary format tags/values are not
standardized - just the "standard" metadata is.

I would argue that non of the plugins are format neutral - they all
only work on the specific formats they are written for. Maybe I am
ignorant here?

If the consumer needs to know the metadata anyway for it to be
useful, then the StandardMetadata suffices for the metadata, and the
consumer can just as easily use the proprietary interfaces when it
wants to use special features of a particular format (it would need
special code using XML as well).

interface ColorImageMetadata { // just an example, might be more
beneficial to have these methods in StandardMetadata
int getNumberPlanes();
int getBitsPerPixel();
.. etc..
}

interface TiffMetadata
long[] getIFD();
boolean isG3(); // simple version of
StandardMetadata.getCompressionName()
.. etc...
}

If the consumer wants to use it in a generic fashion, then it is just
as easy to use reflection to find the interfaces a metadata
implements, and then the methods and the values.

The one thing xml affords is that you can have a DTD that lists the
accepted values. This can also be handled in a generic interface by
using:

interface StandardMetadata {
String getCompression();
String[] getCompressionValues();
.. etc..
}

On Nov 2, 2007, at 6:02 PM, Bob Deen wrote:

> robert engels wrote:
>> I also think this would be a perfect time to drop the stupid XML
>> based metadata with ImageIO. This is by far the hardest/time
>> consuming things about writing plugins.
>> Let's start by defining our own interface for the standard
>> metadata (with a default impl that can read the standard xml/
>> metadata), and then custom interfaces for the formats.
>> Like:
>> interface StandardMetadata {
>> int getWidth();
>> int getHeight();
>> int getHDPI();
>> int getVDPI();
>> ...
>> }
>
> The problem of course is that the plugins are written to be as format-
> neutral as possible. That's why the XML-based metadata exists... it
> allows one to accommodate a nearly arbitrary metadata content without
> any API change. Changing that fundamental philosophy would I think
> be a bad idea.
>
> However, there is definite value in having a convenience layer...
> something
> that takes common calls like you have in your example and translates
> to/from the underlying XML. Hide all that nastiness from the casual
> user, although the nastiness is still there for those who need it.
>
> -Bob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

[att1.html]

Bob Deen

> I don't think you are correct.
>
> Since the consumer needs to "know" what is in the proprietary metadata
> in order to "use" it - other than a simple name/value display - unless
> you possibly make an assumption based upon the tag name and/or value.
> The proprietary format tags/values are not standardized - just the
> "standard" metadata is.

Not all formats support all "standard" metadata options, and not all files
contain all possible metadata. You would at least need query functions for
each item to say "is it available". Maybe even a different query
function to
ask "is this item supported by the format"... those are not necessarily the
same thing.

> I would argue that non of the plugins are format neutral - they all only
> work on the specific formats they are written for. Maybe I am ignorant here?

Sorry I meant to say the plugin *mechanism* is format neutral. Meaning it
can handle any kind of format with any arbitrary metadata. Specific plugins
are of course format-specific.

> If the consumer needs to know the metadata anyway for it to be useful,
> then the StandardMetadata suffices for the metadata, and the consumer
> can just as easily use the proprietary interfaces when it wants to use
> special features of a particular format (it would need special code
> using XML as well).

We do a fair amount of processing on the XML without specific code to
interpret the items (think XSLT here).

The bottom line is, it's a part of a standard that's embedded in the
JRE so it's unlikely to change and almost certainly will not go away
(for compatibility reasons). Which is why I suggested a wrapper
interface... make it easy to use without affecting existing API's.
Practically speaking, changing the API would mean that someone
would have to write a new interface for each existing plugin... and
that's pretty unlikely. That's why I think a wrapper (which can be
used with any plugin that supports the generic interface) is the way
to go. Maybe not the ideal design, but we don't exactly have a clean
slate here.

> *If the consumer wants to use it in a generic fashion, then it is just
> as easy to use reflection to find the interfaces a metadata implements,
> and then the methods and the values.*

Well we have a different definition of "easy". ;-) The problem with
that as a general design philosophy is that it assumes that the interface
writer is rigidly following the naming conventions... that can be a fairly
dangerous assumption.

> The one thing xml affords is that you can have a DTD that lists the
> accepted values. This can also be handled in a generic interface by using:
>
> interface StandardMetadata {
> String getCompression();
> String[] getCompressionValues();
> .. etc..
> }

Yep.

-Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

robert engels

On Nov 2, 2007, at 8:17 PM, Bob Deen wrote:

>> I don't think you are correct.
>> Since the consumer needs to "know" what is in the proprietary
>> metadata in order to "use" it - other than a simple name/value
>> display - unless you possibly make an assumption based upon the
>> tag name and/or value. The proprietary format tags/values are not
>> standardized - just the "standard" metadata is.
>
> Not all formats support all "standard" metadata options, and not
> all files
> contain all possible metadata. You would at least need query
> functions for
> each item to say "is it available". Maybe even a different query
> function to
> ask "is this item supported by the format"... those are not
> necessarily the
> same thing.
>

It would be the same, the method could throw
"UnsupportedOperationException". You need to handle that just as if
the node was not in the XML. But I would argue that with the proper
interface hierarchy, you could partition the interfaces in a
hierarchical fashion so that it would be rare for a format to need to
throw this exception.

>> I would argue that non of the plugins are format neutral - they
>> all only work on the specific formats they are written for. Maybe
>> I am ignorant here?
>
> Sorry I meant to say the plugin *mechanism* is format neutral.
> Meaning it
> can handle any kind of format with any arbitrary metadata.
> Specific plugins
> are of course format-specific.
>
>> If the consumer needs to know the metadata anyway for it to be
>> useful, then the StandardMetadata suffices for the metadata, and
>> the consumer can just as easily use the proprietary interfaces
>> when it wants to use special features of a particular format (it
>> would need special code using XML as well).
>
> We do a fair amount of processing on the XML without specific code to
> interpret the items (think XSLT here).
>

Yes, but it would appear that using XSLT (since it is a formatting
language) is doing nothing more than a "fancy" display of what I
stated - name/value pairs, possibly with some hierarchy, but the
interfaces can easily support hierarchical data as well.

Please show me an example of a real world use (acting on the metadata
- not just display/formating it ) that does not involve "knowing" the
metadata, and I will be far more inclined to accept the situation.

> The bottom line is, it's a part of a standard that's embedded in the
> JRE so it's unlikely to change and almost certainly will not go away
> (for compatibility reasons). Which is why I suggested a wrapper
> interface... make it easy to use without affecting existing API's.
> Practically speaking, changing the API would mean that someone
> would have to write a new interface for each existing plugin... and
> that's pretty unlikely. That's why I think a wrapper (which can be
> used with any plugin that supports the generic interface) is the way
> to go. Maybe not the ideal design, but we don't exactly have a clean
> slate here.

True. The people that developed this originally were obviously of
the type "XML is the coolest, greatest thing... let's use it". A
terrible design choice for Java. Look at the difference with how
metadata works with JINI services. The service returns an interface
that describes what it can do. Far easier, and more powerful. Java/
code based metadata is ALWAYS better (if working in Java). The only
possible reason to use XML is if the plugin architecture was
standardized across platforms (non Java) and then it might be
worthwhile.
>
>> *If the consumer wants to use it in a generic fashion, then it is
>> just as easy to use reflection to find the interfaces a metadata
>> implements, and then the methods and the values.*
>
> Well we have a different definition of "easy". ;-) The problem with
> that as a general design philosophy is that it assumes that the
> interface
> writer is rigidly following the naming conventions... that can be a
> fairly
> dangerous assumption.
>

All of Java is based on this (i.e. Java Beans).

>> The one thing xml affords is that you can have a DTD that lists
>> the accepted values. This can also be handled in a generic
>> interface by using:
>> interface StandardMetadata {
>> String getCompression();
>> String[] getCompressionValues();
>> .. etc..
>> }
>
> Yep.

It was a poor choice, and I bet if the designers answered honestly
they would admit it. They designed a solution for a problem that
didn't exist.

We can keep living with it, and all the problems - I wrote the PCX
plugin (a VERY simple format) - way more work than it should have
been, and it STILL doesn't do any real metadata - because it is
complete horseXXXX, or we can admit the mistake and invest the
resources to correct the problem to allow for easier development.

>
> -Bob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail: interest-help@jai-
> imageio.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net