mirror of
https://gitlab.gnome.org/GNOME/gimp.git
synced 2025-10-06 01:12:40 +02:00
9ff73dc26a
This uses MozJPEG from Mozilla and is dependent on this patch to be merged: https://github.com/mozilla/mozjpeg/pull/383 This is an optional option (standard libjpeg API, e.g. with jpeg-turbo, is still used when MozJPEG is not detected at build time). When using MozJPEG, we have access to both the standard algorithm used by libjpeg-turbo, since MozJPEG is a patched version of libjpeg-turbo, and their own encoding algorithm. We can switch from one to another with a single call. Here is what the maintainer says about MozJPEG goal: > The point of MozJPEG is to improve quality/filesize ratio. It's a win-win: you > get better quality for the same file size, or better file size for the same > quality, or both. There is no downside in either quality or file size. MozJPEG > tunes for these two aspects over speed. libjpeg-turbo's maintainer values speed > over the other two variables. > > MozJPEG has a few techniques. Improved splitting of progressive scans gives > smaller file size while being 100% visually identical with libjpeg-turbo. > > But MozJPEG also has trellis quantization and tuned quantization tables that > give better visual quality, but on a microscopic scale they make different > choices than libjpeg-turbo, so some pixels differ. The differences are > relatively small and predictable, so there's no risk of unexpectedly ruining > an image (especially that on average, you get better quality). Cf. https://github.com/mozilla/mozjpeg/issues/382#issuecomment-730544796 Note that after several testing, I could indeed confirm that it seems to always produce smaller files (as far as my testing went) for similarly looking quality, but the speed cost can actually be quite important: on my computer, for some random files where encoding would take 0.7 second, it took 3.5 secs with mozjpeg; for much bigger file (~25MiB) where export with jpeg-turbo takes about 3.9 secs, it takes 30+ seconds with MozJPEG which is a huge difference and can be very frustrating. For small files only, this is less of a problem (I still timed an important difference, but from 0.05 to 0.15 secs is actually bearable). This is why this cannot be an option checked by default. About naming: I hesitated to call it "Export for Web" because it's clearly one of the big use cases (optimizing file size for images on websites), but I just decided to go with a much more explicit name (even though it may resonate less that the basic "Export for Web" which everyone asks for).
------------------------------
GNU Image Manipulation Program
2.99 Development Branch
------------------------------
This is an unstable development release, an intermediate state on the
way to the next stable release: GIMP 3.0. GIMP 2.99 may or may not do
what you expect. Save your work early and often. If you want a stable
version, please use GIMP 2.10 instead.
If you think you found a bug in this version, please make sure that it
hasn't been reported earlier and that it is not just new stuff that is
still being worked on and obviously not quite finished yet.
If you want to hack on GIMP, please read the file devel-docs/README.md.
For detailed installation instructions, see the file INSTALL.
1. Web Resources
================
GIMP's home page is at:
https://www.gimp.org/
Please be sure to visit this site for information, documentation,
tutorials, news, etc. All things GIMP-ish are available from there.
The latest version of GIMP can be found at:
https://www.gimp.org/downloads/
2. Contributing
===============
GIMP source code can be found at:
https://gitlab.gnome.org/GNOME/gimp/
Resources for contributors:
https://developer.gimp.org/
In particular, you may want to look in the "Core Development" section. Some
articles of particular interest for newcomers could be:
* Setting up your developer environment: https://developer.gimp.org/core/setup/
* GIMP Coding Style: https://developer.gimp.org/core/coding_style/
* Submit your first patch: https://developer.gimp.org/core/submit-patch/
3. Discussion Channels
======================
We have several discussion channels dedicated to GIMP user and
development discussion. There is more info at:
https://www.gimp.org/discuss.html
Links to several archives of the mailing lists are included in that page.
Gimp-user-list is a mailing list dedicated to user problems, hints and
tips, discussion of cool effects, etc. Gimp-developer-list is oriented
to GIMP core and plug-in developers. Gimp-gui-list is for discussing
about GIMP interface to improve user experience. Most people will only
want to be subscribed to gimp-user-list. If you want to help develop
GIMP, the gimp-developer mailing list is a good starting point; if you
want to help with GUI design, the gimp-gui list is where you want to
subscribe.
Other discussion channels can be listed on this page when they are
moderated by a team member, such as forums.
Finally, for the real junkies, there are IRC channels devoted to GIMP.
On GIMPNet (a private free software oriented network) there is #gimp.
Many of the developers hang out there. Some of the GIMPNet servers are:
irc.gimp.org:6667
irc.us.gimp.org:6667
irc.eu.gimp.org:6667
4. Customizing
==============
The look of GIMP's interface can be customized like any other GTK+ app
by editing files in `${XDG_CONFIG_HOME}/gtk-3.0/` (settings.ini and
gtk.css in particular) or by using "themes" (ready-made customizations).
Additionally, GIMP reads `${XDG_CONFIG_HOME}/GIMP/2.99/gimp.css` so you
can have settings that only apply to GIMP.
You can also manually change the keybindings to any of your choice by
editing: `${XDG_CONFIG_HOME}/GIMP/2.99/shortcutsrc`.
Have fun,
Spencer Kimball
Peter Mattis
Federico Mena
Manish Singh
Sven Neumann
Michael Natterer
Dave Neary
Martin Nordholts
Jehan