GNOME Bugzilla – Bug 111409
JPEG2000 image format support
Last modified: 2010-10-01 08:21:23 UTC
It would be nice to have a plugin for JPEG2000 image import and export. JPEG2000 is wavelet based image compression format rendering smaller image sizes and better image quality comparing to standard JPEG one.
AFAIK, there are legal issues with this file format. Again, the plug-in should be provided by third-party authors.
The core system of JPEG2000 (which is about all that is required to implement the save/load functionality) is licensed for free (it isn't patent free). http://www.jpeg.org/JPEG2000.html Raph Levien doesn't have much to say for this file format (a very old document -- things may have improved now): http://www.levien.com/gimp/jpeg2000/comparison.html DPReview: http://www.dpreview.com/news/0108/01080401lurajpeg2000.asp Jasper is a free library which can be used: http://www.ece.uvic.ca/~mdadams/jasper/ Might be worth investigating. Adobe has recently introduced a JPEG2000 plug-in for Photoshop. http://www.dpreview.com/news/0302/03021904adoberawplugin.asp
Because of licensing problems due to the patents on the JPEG2000 format, we will probably not be able to distribute this plug-in as part of the standard GIMP distribution, which should only contain GPL or GPL-compatible code (see also bug #83362). It should not be a problem for a third-party author to distribute a JPEG2000 plug-in as a separate package because the GIMP was designed to allow for plug-ins with different licenses, including binary-only plug-ins or plug-ins that are "free" but not "Free" (which would probably be the case for the JPEG2000 plug-in). It is unlikely that any GIMP developer could work on a JPEG2000 plug-in, but we can keep this bug report open until you find someone who writes it.
Huh? Did you read the linked page? The patents associated with the JPEG2000 standard are licensed royalty free for implementations and their use. Perhaps we should remove dockable dialogs, any form of layer compositing, JPEG support (the Forgent patent on run length coding). The JPEG2000 standard is a better standard than the JPEG standard as far as patents go, because while there are parts of the original JPEG standard which cannot be used royalty-free (IBM and Mitsubishi's patents on arithmetic coding comes to mind immediately) known patents on the core part of JPEG2000 have actually been made available for royalty-free use. We have a difference of opinion as before, and you are welcome to your opinion. I am not going to opine anymore.
Hmmm.. Sorry, I was wrong for the JPEG2000 patent stuff. I should get more sleep. The core of JPEG2000 is licensed royalty-free for everybody and this is compatible with the GPL. So a GPL-compatible plug-in for JPEG2000 could be part of the GIMP if someone writes it. Thanks for correcting me. As for the JPEG part, the Forgent issue is indeed a problem. But as far as I know, the other parts of the JPEG standard that were known to be patented (used for example to achieve a better compression of black and white images) are not supported by libjpeg and therefore not supported by the GIMP and many other programs.
Even if the JPEG2000 standard can be implemented in a royalty-free way, it does not mean that it is GPL compatible. This is the reason why the FSF is still pushing for the W3C to reconsider their royalty-free stance. This is because the patents associated with the standards are licensed in a royalty-free way only for implementations of the standard, whereas GPL'd source code can be used for any purpose.
Personally I feel patents should be taken with a grain of salt. Being too conscious stalls development. Intellectual properly is an important area and it should be kept in mind, but we do not have to concern ourselves of the consequences of the use of patents outside the scope of the GIMP project.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
I just found this: http://www.ece.uvic.ca/~mdadams/jasper/ The JasPer Project is an open-source initiative to provide a free software-based reference implementation of the codec specified in the JPEG-2000 Part-1 standard (i.e., ISO/IEC 15444-1). This project was started as a collaborative effort between Image Power, Inc. and the University of British Columbia. Presently, the ongoing maintenance and development of the JasPer software is being coordinated by its principal author, Michael Adams, who is affiliated with the Digital Signal Processing Group (DSPG) and Department of Electrical and Computer Engineering at the University of Victoria.
A BSD licensed Jpeg 2000 encoder/decoder seems to be available at : http://www.tele.ucl.ac.be/PROJECTS/OPENJPEG/download.html
This probleme will be solved soon... I've opened my first JPG2000 (jp2) image 1 minute ago :o) My plug-in, based on the jasper library, need some improvement(progress bar, etc), the save/export abilitie, and a big clean up(it's almost just gimp-plugin-template with no change but main.c for the moment), but it works fine (it's just a little bit slow with big images, but I hope it depends on jasper compilation flags): the test with GRAY & RGB images is ok, need testing with graya/rgba but it shouldn't matter. The first beta version should be released soon :I hope in the current week, but if not, it won't be released before 3 weeks because I will be in hollidays next week.
As Joao S. O. Bueno asked me to attach my unfinished "draft" here, I've enhanced it a little bit to be compilable with gimp 2.0.x. It takes about 1min20 to open a 1024x768 rgb image with jasper 1.70.5, and about 40s for the same image with jasper 1.71 ... It seems that the low performances doesn't come from jasper but from the API I use to fill image with data... Any help would be nice.
Created attachment 30387 [details] gimp plugin jpeg2000 0.1.1 My first make dist of my first C plugin of gimp, now working with 2.0.x, opening jpeg2000 images. needs jasper to compile and work.
Your problems are here (in run): gimp_pixel_rgn_init(®ion,drawable,0,0,width,height,1,0); guchar* buffer=malloc(jas_image_rawsize(jp_image)); import_jpeg2000(jp_image,buffer,width,height); gimp_pixel_rgn_set_rect(®ion,buffer,0,0,width,height); You read the entire image into a buffer, and then set the entire buffer for the image. The GIMP uses a tile-based structure internally, and usually JPEG type images are capable of exploiting that somewhat by reading 8x8 blocks at a time, and setting them. In import_jpeg2000 you read the image row by row, and then perform a pixel by pixel operation to assign data. It would be interesting to see timing info for the 2 calls, import_jpeg2000 and gimp_pixel_rgn_set_rect. Now that I think about it, I suppose that gimp_pixel_rgn_set_rect takes care of tile information itself, so that will probably be pretty quick. To time this stuff, add the following: time_t before, after; /* After pixel_rgn_init */ before = time(NULL); /* call import_jpeg2000 */ after = time(NULL); fprintf(stderr, "Time for jpeg2000 load: %d seconds\n", after - before); before = after; /* call set_rect */ after = time(NULL); fprintf(stderr, "Time for jpeg2000 load: %d seconds\n", after - before); I'd wager that of your 70 seconds, a good 65 are spent in import_jpeg2000. You could also compile your plug-in with -pg and do a profiling run on it.
Bugzilla is really not the right place for such attachments. Please upload your plug-in to the plug-in registry at http://registry.gimp.org/ In order to improve performance, you should make sure that your plug-in sets the tile cache to a reasonable size. It is also desirable to work on tiles, not on rows or individual pixels. I see that your plug-in loads the full drawable into memory before it passes it as a rectangle to gimp. This is a waste of memory and can lead to problems with very large files. Dave: If you want to get profiling data, time() is a bad choice because it gives you a resolution of seconds only. You should be using GTimer (http://developer.gnome.org/doc/API/2.0/glib/glib-Timers.html) instead.
Since this could be considered a work in progress, I don't mind if this conversation stays in bugzilla. The only other place I can think of that would be more appropriate is the devel list. Florian: You might consider consolidating the plug-in into one file (following the model of plug-ins in plug-ins/common in the main source tree) to facilitate reading inline, rather than having to download, untar and so on. This would have the additional benefit of allowing people to install your plug-in easily with gimptool. Sven: Thanks for the tip. I wasn't aware of timing stuff in glib. Since Florian was talking about 70 seconds for a plug-in run, time would probably be fine enough to prove the point. If there's a portable alternative that does milliseconds, all the better.
Well, I'd like not see any patent encumbered code in our bugzilla so please refrain from further attachments. I don't mind discussung the code here or on gimp-developer though. Doing two function calls from the inner loop which is iterated over each component of each pixel is definitely not making the code any faster. If the jasper library doesn't provide a better way of accessing the image data, it would be a very inefficient library then.
The code included here is calling a patent encumbered library, there's no patent encumbered source in there... and I thought that the patent issue was more or less addressed - jpeg2000 patents are licenced royalty free, and if that ever changes, the plug-in can die.
Using the directory structure and build system inspired by gimp-plugin-template is a very good idea and I see no reason why Florian should change that. It makes for a perfect package to distribute and at some point it will need translations and help files also. So why should he use gimptool and a single C file?
I agree with sven: gimp-plugin-template is for me the best way to do, at least for my first one, a C plugin (I've done some python-fu but that's all): a common structure is much more readable, useful, and simpler to use for a beginer like me ;) Without gimp-plugin-template I wouldn't have made this plugin! And I know what I must do just by looking at the files I haven't edited (a kind of todo list). And use is very simple! tar xzf xxx; cd xxx; ./autogen.sh ; make all install A lot of my code is adapted from ImageMagick sources, and also the load system: when I've coded this, I was aware it wasn't the best solution, but as I'm not a gimp guru at the moment, not jasper guru, I've simply done what I've understood from both other gimp plugins sources and ImageMagick jasper interface. I even don't know how to modify configure.in (and well, I only suppose that I must change this file, I'm not sure!) to check for jasper when making configure, neither have I an idea about how to using gettext for traductions... I'm only an average programmer, very interested in Gimp :), and your help is very apprecied ;) Sven: can I attach patches or my main.c file next times on this bugzilla ? It's in too early stage to be on gimp plugin registry...
News from "Jasper FAQ: Legal Issues * Is the JasPer software open source? Yes, the current JasPer license is an open source license and is based on the MIT license." Quote from JPEG Committee: "JPEG 2000 was developed with the intention that Part 1 could be implemented without the payment of licence fees or royalties, and a number of patent holders have waived their rights toward this end." The JPEG-2000 Part-1 standard is known as ISO/IEC 15444-1
If nobody else (Florian?) is doing anything with this, I might have a go in the next few days (ready for a pillow right now). I've had a look at the RawPhoto plugin to see how it deals with tiles. It seems to be doing a row-wise load as well, but it is at least tile-aware. Are there other plugin examples kicking around which (suitably stripped) would make a better example/framework for reconciling Jasper and GIMP?
Ping? Still hoping for a constructive reply to this: "Are there other plugin examples kicking around which (suitably stripped) would make a better example/framework for reconciling Jasper and GIMP?"
Well, the JPEG plug-in comes to mind - unless JPEG and JPEG2000 don't have anything in common.
Leon, did you make any progress yet?
Leon?
*** Bug 554028 has been marked as a duplicate of this bug. ***
It seems as though the project of developing a JPEG2000 plugin for GIMP died without ever producing a working plugin. This is unfortunate. JPEG2000 is significantly more space-efficient than ordinary JPEG for low-loss compression. Microsoft hasn't been interested in supporting the JPEG2000 standard, but Adobe, Corel, and others are supporting it. Part of my interest in this issue stems from the desire to migrate from Corel Photo Album to GIMP, but can't do this until there is some mechanism for reading this format in GIMP.
As long as there is no one who does work on this, JPEG2000 support will never happen. How about giving it a try yourself?
Most of my experience as a programmer is with numerical/statistical codes (linear systems, least squares, optimization, numerical integration, logistic regression, clustering analysis, etc.) I can assist anyone who needs help in those areas, but I've never written a plugin, and have no experience with graphics programming except for a small amount of work with Matlab.
I download the guide to writing GIMP plugins (plug-in.pdf from http://gimp-plug-ins.sourceforge.net/doc/Writing/) and scanned through it. Here are two specific things that I don't understand: 1. Let's suppose that I write a JPEG2000 plug-in for GIMP and that I tell GIMP to load the file "xyz.jp2". How does GIMP know that it is supposed to use my plugin? It seems as though there must be some table that gives the mapping between file extensions and plugins, but nothing like this is mentioned in the document that I read. 2. How does the interface between GIMP and my plugin code work? Is my plugin compiled and linked into a DLL?
Hi Phillip! It's great that you seems interested in developing a JPEG2000 loader for GIMP, but please ask these questions on the gimp-developer mailing list or in the IRC channel #gimp @ irc.gnome.org. Bug reports become so bloated otherwise. I am going to answer your questions now, but please continue this discussion where more appropriate. 1. GIMP queries plug-ins at startup and it is in this stage the plug-ins says "Hi, I can load and save .bmps" or "Hi, I am a filter, put me here in <Image>/Image/Arrange". You can see how a typical file plug-in registers itself by looking at the query() routine for for example BMP: http://svn.gnome.org/viewvc/gimp/trunk/plug-ins/file-bmp/bmp.c?view=markup 2. Plug-ins are separate executables, not dll's. The communication between the GIMP process and the plug-in process happens through IO-pipes and shared memory if the host OS supports shared memory. I will be glad to answer further questions, but again, please continue this discussion on the gimp-developer mailing list or on the IRC channel, whichever you prefer. Best regards, Martin
And please use http://developer.gimp.org/ instead of that hopelessly outdated site on sourceforge.
The plug-in that has been created during Summer of Code 2006 is available at http://registry.gimp.org/node/9899. It's not know if it does work currently, but it might be a base for future work.
gtk-pixbuf has had JPEG 2000 read support via JasPer since 2.14.1. Shouldn't it be trivial to add support to the GIMP? Write support would certainly be great, but read support would be better than nothing... (I don't know C, or I'd offer to do it myself.)
I would like to migrate from Corel to GIMP, but can't do this until GIMP offers at least read support for JPEG2000 images.
Maybe you want to check if the plug-in mentioned in comment #34 does still work, and maybe you can maintain it so that it could be added to GIMP (it would be nice to have some figures on general JPEG2000 usage to support the cause then, though). You can ask for advice on the gimp-developer mailing list is you run into problems.
Created attachment 135681 [details] [review] Load JPEG 2000
Cool, looks like 2.8 material.
Indeed, also almost perfect coding-style wise.
Committed with some minor changes to master.
*** Bug 631043 has been marked as a duplicate of this bug. ***