Re: compression parameters on re-save jpeg
When I load a jpeg image (e.g. to turn it 90drg) which compression parameters got it saved with using save (Ctrl-S). I assume the original once are not recorded in the image, so how could I be shure that the quality is perserved. The quality can not be preserved since JPEG is a lossy format and will always degenerate the image on each subsequent save. If I remember correctly, GIMP does indeed store the compression parameters with your image. If you use the "Save As" function you have the possibility to check and change the parameters. Salut, Sven
Re: The undo stack does not record some changes in layer attributes
Greetings! On Wed, 07 Jun 2000, Sven Neumann [EMAIL PROTECTED] wrote: [quoting Austin Donnelly [EMAIL PROTECTED]] I would be very unhappy if changing the layer opacity from 100% to 50% would eat up a dozen or more undo-steps since each value_changed signal from the slider triggers an undo which causes another undo-step fall off the end of the undo queue. Oh, sure - that's clearly a bad idea. I was thinking of only pushing the undo when you release the slider. That doesn't help those using the keyboard to nudge the slider though. [...] I just had an idea re: the undo stack. It shouldn't matter whether changes are done via keyboard or via mouse. Not pushing an undo on to the stack until the mouse release would help (ie. when adjusting sliders or spin buttons) but only affects mouse operations. The more generic solution is to check the last entry of the undo stack before pushing something on to the undo stack. If someone is nudging a given slider, a check would show that the last operation on the undo stack is a change to that same slider. You would then throw out that stack entry and push the latest change to the stack. This assumes that the operation being done a bit at a time does not affect an image being worked on. If the user nudges different sliders each time, then you would save each nudge of a slider (for example). The tricky part might be to determine whether the last item on the undo stack caused a change to an image. Changes to image previews should probably be ignored. I'm not suggesting this be done for 1.2 as I suspect its too likely to wind up adding bugs to the GIMP. It would help to maximize the use of the undo stack, however.
Re: Gimp and Perl 5.6
On Fri, Jun 09, 2000 at 02:01:49AM -0400, "Marc D. Spencer" [EMAIL PROTECTED] wrote: Has anyone successfully run non Perl::Fu command-line scripts under Perl 5.6? Yes, me ;) Gimp $img = gimp_image_new(100,100,RGB) Segmentation fault (core dumped) gdb reveals that it's seemingly a perl problem, but my experiance is Which version of gimp-perl (or gimp) did you use, and how did you compile it (and on what architecture)? Although I don't remember any perl5.6-specific problems it might be caused by some old version. Also, perl5.6 is not production-ready, if you want bleeding edge perl (highly recommended, it's got new cool features ;) better get it from the repository. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Gimp and Perl 5.6
At 4:27 PM +0200 6/9/00, Marc Lehmann wrote: On Fri, Jun 09, 2000 at 02:01:49AM -0400, "Marc D. Spencer" [EMAIL PROTECTED] wrote: Has anyone successfully run non Perl::Fu command-line scripts under Perl 5.6? Yes, me ;) Gimp $img = gimp_image_new(100,100,RGB) Segmentation fault (core dumped) gdb reveals that it's seemingly a perl problem, but my experiance is Which version of gimp-perl (or gimp) did you use, and how did you compile it (and on what architecture)? Although I don't remember any perl5.6-specific problems it might be caused by some old version. Also, perl5.6 is not production-ready, if you want bleeding edge perl (highly recommended, it's got new cool features ;) better get it from the repository. Perl 5.6 is listed at the Perl site as 'Stable'. I know it's still early to use in a production environment, but I want to begin to get up the curve. I love Perl5.6's new 'our', and Unicode will become more a requirement than a nicety soon. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | Versions...sorry - guess I wasn't thinking as well at 2:00 as I thought. Gimp 1.1.23 Gimp-Perl 1.2 Perl 5.6 [ Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.12-20, archname=i586-linux uname='linux tigger 2.2.12-20 #1 mon sep 27 10:25:54 edt 1999 i586 unknown ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef Compiler: cc='gcc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-fno-strict-aliasing -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=/lib/libc-2.1.2.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' ] Redhat Linux 6.1 on Intel I can poke further into the core, or I can send it to you or put it somewhere you can get it. Let me know.
Re: compression parameters on re-save jpeg
On Fri, Jun 09, 2000 at 12:24:35PM +0200, Andreas Haack [EMAIL PROTECTED] wrote: it saved with using save (Ctrl-S). I assume the original once are not recorded in the image, so how could I be shure that the quality is perserved. Just do not use JPEG ;) In general it is impossible to do what you want, especially if some other program wrote the JPEG. In practise you should save the JPEG in a quality very near the original quality. It is also possible to guess the quality (my "judge" program does something similar to this, for example), but it is very difficult. (Also, one might not want to "judge" the quality of the image, but the quality of the quantization factor instead). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Gimp and Perl 5.6
On Fri, Jun 09, 2000 at 11:09:59AM -0400, "Marc D. Spencer" [EMAIL PROTECTED] wrote: (highly recommended, it's got new cool features ;) better get it from the repository. Perl 5.6 is listed at the Perl site as 'Stable'. Ask p5p on how "stable" that is. GSAR (the current pumpkin) didn't intent to make have listed as stable. I know it's still early to use in a production environment, but I want to begin to get up the curve. well, it should work (and does work) here, even with 5.6 (I do not test it with older versions anymore). Gimp 1.1.23 Gimp-Perl 1.2 Perl 5.6 Hmm looks very fine. useperlio=undef d_sfio=undef uselargefiles=define use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef cc='gcc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux Looks quite fine (well, that compiler is very old and a lot of bugs have been found in it). cppflags='-fno-strict-aliasing -I/usr/local/include' But they took care of the biggest problem with that compiler. (actually a perl problem). This is almost exactly my configuration, except that I using a evry experimental compiler :* So, in short, I have not the slightest idea what's going wrong. Some bugs in 5.6, however, are known to corrupt memory, so I'd say try with 5.005 and later with 5.6.1. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
