Improved Export behaviour for non-alpha backgrounds
I'd like to propose a change to Export behaviour, or possibly to the Merge Visible Layers feature, depending on what other developers think about the following: 1. Create new image with pink background 2. Add layer, draw picture of bird 3. Save as PNG => Result is an RGBA PNG, 121Kb 4. Flatten, Save again => Result is RGB PNG, 105Kb The trouble is that "Merge Visible Layers", which is currently recommended for any multi-layer image saved to a transparency capable image file format, adds an alpha layer to resulting layer, even if the lowest visible layer was a non-transparent background. I don't think altering Merge Visible Layers is the right thing to do, there would doubtless be a number of surprises waiting if I did it. Instead, I propose to change Export to recommend "Flatten" when it notices that the bottom layer has no alpha channel AND is visible, when it would current recommend "Merge Visible". This will improve compression ratios for PNG, TGA etc., as well as increasing available colors for GIF and colormapped PNG. Comments? Objections? Nick.
Re: JPEG correction (was Re: Gimp Wishes)
If I start with an image out of my digicam and it is already in JPEG format I'll save it as an .xcf or .xcf.gz. When I'm finished makin changes then it gets prepped for the web. (crop, scale, and jpeg compression) The only manipulation I can think of that would benefit from "lossless" jpeg would be rotating the image. (if I were shooting low-rez) I remember seeing some tools at the JPEG F.A.Q. site that would rotate a JPEG without damage. http://www.faqs.org/faqs/jpeg-faq/ Tom Lane! Are you still subscribed? :-) -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Re: 1.1.19-installation fails
On Thu, Apr 06, 2000 at 11:05:10AM -0400, "William L. Sebok" <[EMAIL PROTECTED]> wrote: > Marc Lehmann <[EMAIL PROTECTED]> says: > > The problem is that gettext itself does the detection (and so the only > > solutioon would be to rpelace the gettext.m4 macros by our own versions). > > I only get the results. > > You mean the gnu version of gettext itself does the detection of msgmerge. The > problem is that the gnu version of gettext (and msgfmt) is not the only such > version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. I know (that's why I also do not understand why the .mo files, which are os/architecture dependent, should be distributed with the gimp). The problem is: gimp uses gnu gettext for detection of msgfmt/msgmerge etc.. (regardless of which version is installed on the target system). It is difficult to change this except by re-writing that part, and it does not try to detect availability of a compatible msgmerge. Obviously, I am not keen on re-implementing the whole gettext package just for perl (I had to re-implement most of it already, since it cannot be extended to other languages). :( So I am for a working-but-maybe-not-compliant-to-the-undocumented-gettext solution, but it is difficult to achieve that :( The current (soon-to-be-checked-in) solution to this problem will be to disable any automatic po updates (which requires msgmerge). If translators want an updated pot or po file, they have to "make -C po update-po" themselves (or run po/update.sh) manually. (Which was how it was done a long time ago) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: JPEG correction (was Re: Gimp Wishes)
On Thu, Apr 06, 2000 at 07:37:14PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote: > On Thu, Apr 06, 2000 at 01:20:50AM +0200, Marc Lehmann wrote: > > As such, why save an image if you didn't change it? > > There is no good reason why a PROFESSIONAL graphic designer should be > doing it, but lots of us are mere amateurs :) gimp makes it very difficult to save an image you haven't changed. > JPEG works one tile at a time. The same behaviour I observe in one image > will be true on average for individual tiles, so if I alter only one > half of an image (or only touch up one word) and save with the same > quality as the original, the untouched tiles will be mostly unharmed. Most people use things like the Curves tool, the Levels tool, the Crop tool etc.. to retouch images. Not popping up a save dialog will hurt the amateur users that you care for most, since it creates a totally wrong sense of safety. > By fiddling carefully with JPEG settings we can get the "right" setting Something that will work "by chance" (without an easy way to undo the action, since the user will not notice the problem early enough) mustn't go into the gimp. I mean, quality detection is a good thing, but it must NEVER be automatic, second guessing the user on something that will go wrong in a vast number of common situations is "unfriendly". > I don't want that, people shouldn't be using JPEG for works in progress > or as a common format moving between packages or ANYTHING like that, and > I agree that we don't want to give them false expectations. > > I think Marc and I agree on the realities of this situation, I just > wanted to make clear that "lossy" re-saving doesn't necessarily cause > any damage to the image. But that's NO REASON to be doing it, and > no reason for Gimp to encourage it either. 100% correct ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Color Quantization
The aim of GIMP is not only to be as good as Photoshop but become better than this program. So it would be fine to implement features that even commercial programs don't have. The common color quantization algorithms have many disadvantages, but there is a very new called Spatial Color Quantization (http://www-dbv.informatik.uni-bonn.de/quant/) that is better than all other methods. Is there anyone who has enough time to implement this very good algorithm. Martin
Re: JPEG correction (was Re: Gimp Wishes)
On Thu, Apr 06, 2000 at 01:20:50AM +0200, Marc Lehmann wrote: > As such, why save an image if you didn't change it? There is no good reason why a PROFESSIONAL graphic designer should be doing it, but lots of us are mere amateurs :) JPEG works one tile at a time. The same behaviour I observe in one image will be true on average for individual tiles, so if I alter only one half of an image (or only touch up one word) and save with the same quality as the original, the untouched tiles will be mostly unharmed. A classic example (which I won't distribute because it's obviously illegal) is a re-touched Matrix JPEG from the movie site, altered to replace Keanu with Windy Miller from the old UK television shows. By fiddling carefully with JPEG settings we can get the "right" setting to make the hacked version look like the original, without additional artifacts in the unaltered portions of the image. Looks great! > Given that the problem is unsolvable in theory and almost impossible even > to approximate in practise, I believt hat such a automatic detection > scheme will fool people into thinking that saving at the same quality > wouldn't destroy their image. I don't want that, people shouldn't be using JPEG for works in progress or as a common format moving between packages or ANYTHING like that, and I agree that we don't want to give them false expectations. > The problem here is that different encoders have different notions of > "quality settings", and in most cases you can only approximate the > quality setting of another encoder (quality settings are just a quick > way to describe a 8x8 matrix, and setting up that matrix is very much > decoder-dependent) I think Marc and I agree on the realities of this situation, I just wanted to make clear that "lossy" re-saving doesn't necessarily cause any damage to the image. But that's NO REASON to be doing it, and no reason for Gimp to encourage it either. That was a public service announcement from the lossy compression posse Nick.
Re: 1.1.19-installation fails
On Thu, 6 Apr 2000, "William L. Sebok" <[EMAIL PROTECTED]> wrote: > Marc Lehmann <[EMAIL PROTECTED]> says: > > The problem is that gettext itself does the detection (and so the only > > solutioon would be to rpelace the gettext.m4 macros by our own versions). > > I only get the results. > > You mean the gnu version of gettext itself does the detection of > msgmerge. The problem is that the gnu version of gettext (and > msgfmt) is not the only such version. In particular, there is a > Solaris gettext and msgfmt but no msgmerge. Hmmm... What he meant is slightly different, but close... When running the "configure" script, it runs some tests to detect what is on your system. Some of these tests are derived from the contents of the file aclocal.m4 that you can find in the top-level directory of the Gimp sources. The file aclocal.m4 is assembled (when the package is rebuilt) from a collection of *.m4 files provided by various packages. One of them is gettext.m4, which contains the tests for checking if gettext is present on your system. The problem is that the tests are verifying if your system has a working version of "msgfmt", "xgettext" and some other tools, but it does not check for the presence of "msgmerge". So it is wrong to assume that "msgmerge" is present if the tests for gettext are successful. Some Linux distributions as well as all versions of Solaris come with "msgfmt" but not with "msgmerge". I think that the only solution is to add a new test with AC_PATH_PROG or something similar in configure.in. -Raphael
Re: 1.1.19-installation fails
Marc Lehmann <[EMAIL PROTECTED]> says: > The problem is that gettext itself does the detection (and so the only > solutioon would be to rpelace the gettext.m4 macros by our own versions). > I only get the results. You mean the gnu version of gettext itself does the detection of msgmerge. The problem is that the gnu version of gettext (and msgfmt) is not the only such version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy Internet: [EMAIL PROTECTED] URL: http://www.astro.umd.edu/~wls/
