21445 - RFE: JIF support

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, enhancement, P3)

Description

[tupper]

I'm writing to request support for JIF be added to mozilla.

Information on JIF is at:

     http://jeff.cafe.net/jif

JIF is a format designed to be a complete replacement for GIF (animated and
still) that is very easy to add to an application that supports GIF and PNG.
JIF simply replaces the LZW compressed raster data in GIF with zlib
compressed data (which is what PNG uses). Applications supporting JIF should
be arriving fairly soon (the next release of the popular GraphicConverter on
the Mac should support JIF - several developers are working on adding JIF
support to their apps currently).

I can provide some help for this, but I would like to know if the mozilla
developers are receptive to this. For example, I could patch libgif to
support JIF fairly easily, but I would like to know if such patches would be
taken in by the mozilla developers. The amount of work to bring JIF support
up to the level of GIF support should be fairly minimal since JIF has the
exact same set of features as GIF and is parsed the same way, with the
exception of compressed raster data.

Jeff Tupper
[e-mail]

Comment 1

[pnunn]

Jeff:

The image is now componentized and you could write
your own jif decoder component. This would be much
cleaner than modifying the current gif decoder module.

-pn

Comment 2

[tupper]

Writing a separate decoder is possible, but perhaps I wasn't clear before
(http://jeff.cafe.net/jif has more details) - JIF is parsed *the same way* as
GIF. There are two differences: "JIF99a" is the signature (instead of "GIF87a"
or "GIF89a") and zlib is used in place of LZW. The rest of the format is the
exact same (logical screens, extension blocks, graphic control extensions, image
descriptors, ... all the exact same to minimize the amount of changes needed to
add JIF support to a GIF supporting application). Would writing a separate JIF
decoder allow animations and looping? Is there concerns about code bloat? The
image parsing code is the same for both formats - just raster decoding

Comment 3

[pnunn]

All pnunn bugs reassigned to Pav, who is taking over
the imglib.

Comment 4

[Terri Preston]

As this bug is so old and no new activity, I'm going to resolve as won't fix, 
reporter please reopen if you believe this is still an issue

Comment 5

[Matthew Tuck [:CodeMachine]]

Umm, [e-mail], the JIF format still exists and isn't in the code
base.  I can't see any reason why you should close RFEs that have seen no
activity.

Comment 6

[Blake Ross]

Reopening in light of that.  and pav can always use more bugs.

Comment 7

[Hixie (not reading bugmail)]

One reason to WONTFIX this is that PNGs are the way forward, but since we now have
PPM support (ish) that really isn't a good reason...

Tupper: Are you still interested in working on this?

Comment 8

[tupper]

What a flurry of activity. JIF is still moving along; a handful of applications 
support it now. It isn't an epic quest or anything - I have more than enough 
to do! It is just the simplest way away from GIF, as stated on the JIF page. 
PNG doesn't include all of the features of GIF yet also includes new 
features (which means that software has to be reworked to use PNG 
properly). I don't have anything against PNG, but it is useful to have a 
simple alternative to GIF. All that should require changing is to allow JIFs 
wherever GIFs are allowed and to check the header for "JIF99a" and then 
invoke zlib instead of your LZW code where appropriate. (See the JIF page 
for more details and some sample code.)

Comment 9

[Hixie (not reading bugmail)]

tor: could you help?

Comment 10

[tor]

Personally I don't see much point to JIF and don't see it catching on.
However if someone is interested in adding support, it wouldn't be that
hard to make the GIF decoder also listen for x-jif mimetype, record which
type of file it's decoding, and call the appropriate decompression routine
(do_lzw() in the current code).  "case gif_lzw_start" in gif_write() might
also need modification.

This should stay as enhancement/future.  Reassigning to [e-mail]
would probably be appropriate, as I doubt pavlov is interested in doing this
work.

Comment 11

[tupper]

JIF is a pretty trivial format: the main point is that those who want to do 
GIF-like things and avoid LZW licensing can do so. The number of man-
hours we've spent discussing this is probably comparable to the number 
of man-hours it would take to implement it for someone familiar with the 
source. I'm pretty sure the cost / benefit ratio is pretty good, given the low 
cost of implementation. I get semi-regular email from people asking how 
to use JIF; I'd gladly point them towards a compliant browser. I might be 
able to do the modifications in the future, but I'm a full-time computer 
graphics Ph.D. student that is behind in his studies... If someone is 
interested in doing this, I could provide licenses to any of my software 
(http://www.peda.com/) [GrafEq, Tess, and Poly betas do] that produce 
JIFs.

Comment 12

[rbs]

tupper, I can understand your frustration trying to convince other Mozilla
contributors for months about the value of your idea. This is a well-know stigma
that inventors face. For an independent observer, the real issue so far appears
to be that adding JIF is going to be more beneficial to JIF than Mozilla. Once
it get to this stage, only a patch can make a significant difference. Following
what tor said earlier, here is a link to get started. It will point to the exact
spots where to start investigating:

http://lxr.mozilla.org/seamonkey/ident?i=do_lzw

Since the footprint of a variant 'do_zlib' is likely to be minuscule if the
existing png version can be re-used, a patch may stand a chance to be 
accepted -- thereby bringing your JIF to the masses. This a constructive way
forward that I can suggest.

Comment 13

[Eli Friedman]

The chance of this getting added at this point is zero, especially considering that the format seems to be completely dead.