Do you plan to support loading of TIFF images (additionally to GIF & JPEG)?

======================================================================

======================================================================

An Image I/O framework extension will be developed which will allow
Sun or 3rd parties to add codecs for any typical sampled image format.

It is not at all certain that we would directly integrate a codec for TIFF as
a part of core, but the extension will allow runtime pluggability for such
a codec.

Are there any other 3rd party tools that perform
this functionality today?

This request has been "in progress" for 3/4 of a
year now. In that amount of time, how much
progress has been made?
Will this be in JDK 1.2?

How about .PNG support as well? the PNG format has been promulgated as an image
standard by the W3C.

I also would prefer .PNG support over .TIFF as it is the proclaimed standard
image format by the W3C and the most flexible and powerful image format I have
seen. I really don't understand why   
Java shouldn't support this format as Java should be network- and
internet-centric!?

How about PNG format??

I wrote a library for TIFF images this past spring.  
It handles raw, packbits, G3, G4 and JPEG compression.  
I will make it available under GNU licencing this
week.  It will be available on 
www.lizardworks.com\java.html by October 31.  I 
would welcome any comments and would be happy to 
make any improvements.  There will are two versions 
(1.02 & 1.1), since I had to write my own 
sun.awt.image.ByteArrayImageSource.class for TIFF JPEG
support.

Since the TIFF file format is the most widely used (and memory-efficient)
image format for scanned documents, it would be a great advancement
for Java in the enterprise.

If Java is going to target the "Enterprise",
remember that the Enterprise has quite a few
more TIFF files than JPEGS.  Almost all document
imaging systems use TIFF.  Native TIFF support
will unlock a vast amount of data for Java apps.

There should be support for more formats, not only
for tiff but also BMP, PNG etc.

We are basing a product on Java with hopes that tif images will be supported; 
current tif packages are to slow.

ALL fax machines use TIF (G4) compression. A global standard
like this should definitely be part of the Java language.

At present, TIFF G4 is the most economic representation of 2 level bit images.
Future versions of TIFF will also include more powerful 2 level image
compression schemes (JBIG).

Both PNG and TIFF support is essential.

Come on people... TIFF files are 
OUTRAGEOUSLY HUGE!  I'd hate to see how much more
the JDK is going to grow just to support these
archaic dinosaurs.

No they're not huge. In fact I found they were the most
efficient format to store large black & white scans.

TIFF/CLASS F is the most efficient way
to store fax images. When is this going
to be part of the core product?
Support for PDF would also be nice.

My take on image support:
PNG - Da
TIFF - Da
PDF - Nyet

I work in a large document imaging shop and
we desperately need to display TIFF images in
our applets.

Coming from the (small) NeXT world I have been
looking for a TIFF package for ages.

Maybe Java 2D pr AWT can have image-conversion plug-in
support ... you can't support every file format
in the JDK.

Handling tiff files will be very usefull
to integrate fax and web services in intranets

I wrote a .BMP and .ICO class.

.PNG support also, please.

It should be added.  This would be a nice feature.  How about support for BMP
and PCX also?

TIFF (in particular G4) support is very important
to our products (for document viewing).  Also,
efficient bitmap and greyscale support in the 
window system and rescale-bitmap-to-greyscale
(of course, JDK 1.2 has some APIs for that:
a good step forward).

A more general workaround would be the ability (or at least better
documentation on) to write your own decoders that are used whenever ImageLoader
comes across an unusual file. That way you can have support for .TIFF, .PNG,
.BMP, .ICO etc

PNG and TIFF

PNG Support Please!!!!

Make Image I/O support modular by defining
ImageLoader and ImageSaver interfaces, and
implement it with GIF,JPEG,TIFF and many more
formats. Add also image inspection features
such as finding the file format of an image
or its color format without fully loading it.

As well as loading the TIFF image, we need to
read values out of the tags.  In particular,
we are working with the GeoTIFF superset of
TIFF tags.  How about support for accessing
image metadata?

not only read, but also write images to graphic
files in different formats. i know of a freeware
gif writer, anything else out there?
official supported in 1.2?

When you finally add TIFF like I requested 
last March, could you also add a binary Image class?
G4 images are binary and usually page size, which
has a tendency to blow memory when feeding java.awt.Image.

The JDK needs to be able to evolve as the industry switches between image
types.  Today's standards are gif, jpeg, and tiff.  Who knows what tomorrow
will bring.  In order to avoid rewriting the Image class everytime a new
standard is released, why not have the ImageProducer look for a data file (a
pluggin) everytime it enctonters a non-standard image?

We've had to write a TIFF->raster decoder in 100% pure java, and the beast
is *extremely* slow due to the way that the ImageProducer scans a line at a
time, and also the inneficiencies of using a 32-bit int in a lot of places to
code for a b/w pixel which could be represented in 1 bit.  Native support in a
reliable way, à la JPEG/GIF support is the only good way to work with the
financial-industry imaging standard/fax format of TIFF.

Happy birthday bug #4029964
Come on guys, it's been a year and not one single little comment from Javasoft.
That's true, it's only the number 2 in the top 25.

I would be happy with a class (an applet) 
that supported
compressed tiff CCITT G4 (T6) full page 
(2592*3508 (A4) and 2320*3408(US))

I work in the document imaging industry.  Most document
imaging vendors store their images as tiff.  This would
be a great advantage if tiff were a supported format.

P.N.G. PORTABLE NETWORK Graphics
Doesn't that sound like Java?
Come on Sun, forget TIFF give us PNG!!

No! No! Not a jumbled, incompatible, hard-to-support mess like TIFF.  That one
function would double the size of the JDK.
PNG is definitely the way to go. Yes, I'm a
little biased, being one of PNG's creators,
but we debated for a long time on whether
to create PNG in the first place when there
were lots of others like TIFF around, and we
came to conclusion that TIFF just wasn't
acceptable for net use.  PNG is better
compressed, more compatible, an official web standard, just as capable, and
would
only add a minuscule amount of code to the JDK (which already has java.util.zip,
 the same compression algorithm as PNG).

I see a trend here... Some people want TIFF support,
others want PNG support, others want BMP support...
and if they all go into the JDK, it'll bloat.  How
about adding a facility for registering readers
for different formats with the system?  Kinda like
how the JDBC drivers are registered.  When an image
is requested, the first 1K or so the the image can
be given to each registered reader and they can examie
it for it's magic number and respond about whether
ot not the module can read the image.  If it can,
it is then asked to do so.  This way, it'll be
easy to add support for RGB files, PIX, etc... and
if you don't care about most of them (many people
don't) you don't pay the price for having support.

For those who want PNG, submit a separate request
for enhancement, then vote for it. Your commentary
here against TIFF is much less useful than your
votes elsewhere for a PNG. You are just creating
noise otherwise.

There are HUGE repositories in the business world of TIFF G3 and G4
compressed images. I worked for eight years in the document
imaging world, and there are sites with 100,000,000+
images (many with > 10 million). Without TIFF viewing capabilities
(either by server rendering to GIF on the fly - yuch - or
a TIFF capable viewer), browser technology will not be used.
Also, G3 and G4 are very efficient compression
methods that would make image viewing of b&W very
snappy, even on slow links.
these businesses will

How about PNG support as well?

I have worked in the image industry for 4 years
supporting a product which displays TIFF images.
I would not recommend the base Java language support
TIFF as it does GIF and JPEG.  Unfortunately, every
image vendor seems to have their own interpretation of
the TIFF and compression standard and it really is a support
nightmare.  This includes fax machines, fax cards,
scanners, and display cards as well as software programs.
I am very concerned especially when a see comments
from folks in the industry who say they have a large number of
TIFF images in an 5-year or longer database.  You don't want
to support these.  The best approach (as mentioned by others)
is to have a way to plug-in a vendor-specific
implementation to display TIFF or any other image
format.  In summary, the one who should display TIFF
images should only be the one who created it.

I would prefer PNG. (4101708)

I'd prefer to see .PNG before .TIFF, too.
Wonder if Kodak can toss in some libraries for this? >:)

I would also prefer PNG. 

An intro to the 2D API says that Java can now be
used for CAD/CAM programs.  Well, Java is still a 
toy if it can not read and WRITE a lossless format
image file (PNG or Gif).  Reading and writing TIFF
would be really nice too, as most images in the 
working world are TIFF.

Reading and writing JPEG, GIF, PNG, TIFF, 
PICT, BMP, and other image files should 
be a standard part of Java.
From what I understand, a company 
called Activated Intelligence 
(http://www.activated.com) (with 
which I have no affiliation) has 
created a product called JIMI (the 
Java Image Management Interface) 
which does this.  They have offered 
to license part of JIMI (write JPEG,
write GIF, read PNG, and write PNG)
for free to Sun. Sun almost licensed
it, but hasn't yet.  Instead, they 
may include just a JPEG writer from
Kodak instead.  
I want Java to read and write 
additional file formats.  If you do,
too, please:
1) Read Sun's comments about the 
JPEG encoder at 
http://java.sun.com/products/java-media/2D/.
2) Email Sun (java2d-comments@sun.com)
to encourage them to add read/write 
capabilities for JPEG, GIF, PNG, 
TIFF, PICT, BMP, and other image 
files.  These are the people who
will make the decision.  And ask 
them to once again consider licensing 
JIMI from Activated Intelligence.  
3) Also vote for bugs 4101708 (for PNG support), 
and 4055931 (writing images to various 
file types).
4) Join the Sun's "java2d-interest" 
mailing list immediately and make 
your wishes known.  Important 
decisions about what to support in 
the JDK1.2 release of Java2D are 
being actively discussed right now. 
Instructions for joining the list 
are at:
http://java.sun.com/products/java-media/
2D/forDevelopers/interest_group.html
5) Email Activated at 
"support@activated.com" to express
your support for their efforts.

Please build image encoding/decoding into the VM
where it, hopefully, it can be in assembly or at
least optimized 'C'. Image encoding performs 
poorly when interpreted, to say the least.  I have
used a couple of the third party Gif encoders and
I thought my computer crashed when I ran them 
because everything 'stopped' for so long. 

I think java needs a extensible framework that
enables developers to write their own 
de-/encoders for other fileformats (ofcourse it
should include the most important format (TIFF,
JPEG, GIF, PNG) in the jdk).
Just like JIMI, I don't understand why javasoft
used kodaks jpeg codec instead of JIMI (as far 
as I know it was offered to them).

As our (omtool Ltd.) corporate fax software sales 
generated more than $20M avenue 1997 ($8M 1st Q 
1998), I don't see any reason a standard TIFF
viewer not be supported by java. btw, the viewer
can be very small and fast.

 

Why ? What do you guys need TIFF support for ?
Having GIF and JPEG support, why don't you just
convert your images to those formats, which are
anyway the best ? I do not see a REAL need for
TIFF, I mean, yeah it would be *nice* but it is
not critical AT ALL. There are many other more
important bugs and features that java needs, so
please don't waste your votes on this one.

As balcells wrote: Just use JPG or GIF!

Why not use JPEG or GIF?  Because either format is
particularly good for high resolution binary
images (e.g., scanned text).  In addition, GIF
is plagued by patent problems and should really
not be used anymore at all.  TIFF with Group4
compression is still the best choice for binary
images (at least until JBIG comes along).

In the biological scientific world (both academic and industrial) TIFF images
are widely used.
Adding TIFF support to JAVA would help the writing of new JAVA tools for
scientists.

In my opinion, TIFF would be a poor addition to Java.
First of all, it is a "container" format like AVI
or MOV which results in countless different internal
formats, confusing users and making support an endless
nightmare. Secondly, there are potential problems
with patents that come into play when working with
such formats. Aren't there one or two TIFF compression
algorithms which are protected by patents? Finally,
with formats like PNG around, TIFF is mostly unnecessary.
If Java supports TIFF it will just increase the use
of an outdated format and bloat the already large
JDK/JRE. The same goes for BMP, PCX, WMF, and PICT.
The latter two also bring up a new problem: supporting
vector graphics and metadata.

TIFF is a dreadful file format. However, TIFF CCITT 42D compression is the most
efficient way of storing black and white images produced by fax or document
scanning.
Our company produces document management software, most of our customers images
are around 40-60k. Using GIF or JPG we get images from 200-400k. These formats
are completely unusable for these kinds of images.
You also need special rendering software. You can't just take a B&W image
3000x4500 pixels and display it in a window 600 pixels wide. You need to
antialias the output, and you need to do this very quickly.
I do wish the PNG crowd would take their problems elsewhere as they are not
related to this problem.

I ran a test using painshop Pro v5 with a 2 color image with text on it and a
resolution of 3000 by 4500. The tiff file was saved using FAX CCITT 3.
faxtest.tiff = 132842 bytes
faxtest.png  =  76739 bytes
Funny, seems to me like PNG licked TIFF on 2-color FAX compression :-)

I Think The TIFF format is Better quality than GIF or JEPG
but it takes too much space

TIFF format is the only required format for our application.
Lack of tiff support is a show stopper for us, so 
please implement it.

There are various requests for new formats,
such as TIFF and PNG as well as lesser known
and proprietary ones.
Why not incorporate into the JDK a mechanism 
so that new formats can easily be added by 
organisations concerned by each one.
(i.e. Adobe could provide a Photoshop PSD
plugin, etc...) I they feel so inclined,
the source code could be provided to an
open source system and, if desirable, integrated
into the next JDK

Having support for a file format that natively
includes an alpha channel (TIFF) would be a great
feature.

I work for an imaging and scanning company and we can't use Java because all of
our images are in the TIFF format.  PLEASE give us TIFF.

Would be great. Think of large TIFF-files (DIN A0, for CAD-systems)

Just to make sure it is understood that CCITT G4 
is a better compression for B/W facsimile (fax)
I took a 300dpi scanned A4 page of 32206 bytes, read it into 
PSP 5 and saved it as png not interlaced.
resulting size: 67002 bytes.
Any JAVA support for TIFF (G4) must also be 
able to print at full dpi...
Is 300+ votes not enough for someone to take notice?

.TIFF is an obsolete complex format.. 
we don't need it. 

I was wastly dissapointed to see that the Java Advanced Imagering
addon included native code instead of being 100% Java 
(so much for the buzzwords).  I cannot use it.

I have a set of libraries that work as standard content
handlers at http://www.vlc.com.au/~justin/java/imageloader/
These handle JPEG, BMP, TIFF, TGA, PNG (1.0) and a number
of other formats. If you forego using Toolkit.createImage()
and use just a standard URL class, this works perfectly.
Note that the classes use native code. There is a simple
reason for this: speed. The JPEG pure java loader takes about
ten times longer to load and uses probably double the memory
of native code. The native code compiles for both NT and various
unixen (we've tried Solaris 2.x and HP-UX).
The current version is 0.9 but expect to have 0.95 ready by 2 August 1999.
There are a number of fixes - in particular cleaning up of crap from end of
image streams when doing a lot of high speed image loading. I also expect to
have some image encoders available too.
Unofficial testing suggests that image loading is twice the speed of
the standard Sun capabilities for JPEG (we don't do GIF due to silly
LZW patents) and use a quarter of the memory. 

In photography world the tiff is THE standard. Jpegs are only for low quality
www-stuff. Does Java plan to be just for nice animation applets on the web or
maybe something usefull. 3rd parties is never good in such an important thing.

Just go to www.snowbnd.com
They have a great java toolkit for handling images. We use it particulalrly for
tiffs, it is very fast and can print at 300 dpi.
They aren't too expensive either.
I don't work for them.