[Gimp-developer] The Frosty Logo Script and the Sparkle Plug-in are Back in Action
This bug: http://bugzilla.gnome.org/show_bug.cgi?id=132145 Was present in the Bugzilla for a long time now. It was reported because the Frosty Logo script did not render correctly. Kevin Cozens discovered it was due to the Sparkle Plug-in. Eventually, I decided to resolve it. I did that by comparing the code (portion by portion and line by line) to the code in GIMP 1.2. As a result of this process, I found four regression bugs[1] that were fixed in this patch: http://bugzilla.gnome.org/attachment.cgi?id=35345&action=view However, there were still problems apparent. I temporarily hacked the code to settle both plug-ins on the same identical pseudo-random number generator, with the same seed, and compared the results. They were very different. So I decided to add traces in the code to see where they were different. As I went to add some traces, I discovered another regression bug, very similar to another one I discovered previously, which I fixed. This seems to have corrected the problem altogether, but the results were still not identical. I added more traces, enough to cause both dumps to become a 1.5 GB (no typo here) file, and then I discovered that a parameter passed to a function was different in the plug-ins. I found out that it was a bug, because the 4th byte (possibly alpha) of a color was not initialized. This bug was still present in gimp 1.2.x. I fixed this bug too, and afterwards the results were identical. The patch with both of the newer fixes is this: http://bugzilla.gnome.org/attachment.cgi?id=35501&action=view In any case, I still noticed a problem. In the upper part of the image, the shadows had completely horizontal edges. I noticed that this problem still existed in GIMP 1.0.x (!), but it was still disturbing. After a lot of investigation, and trying to reduce the script to a minimum that still exhibits this problem, I found out the problem was because: <<< I discovered that the problem with the shadow was due to the fact that the shadow was generated within the image boundaries and then the shadow layer was moved (= translated) by an offset which caused it to have horizontal edges at the top of the resultant image. >>> I prepared a patch to fix it. Sven told me to commit it to the CVS, which I did. I forgot to commit it to the GIMP 2.2 branch, which Sven was gracious enough to do late last night. So now the sparkle plug-in is hopefully fully bug-free, and the Frosty logo is back in action. Happy sparkling! Regards, Shlomi Fish [1] - Well, one of them was just a swapped order for fetching two consecutive random numbers from the random number generator, but that was revised too. - Shlomi Fish [EMAIL PROTECTED] Homepage:http://www.shlomifish.org/ Knuth is not God! It took him two days to build the Roman Empire. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > I thought it was amusing that someone said to Bill that storing > metadata in lots of little parasites is not the right thing - 2 > years ago, people told me exactly the opposite. Which is why it should be brought up here instead of sneaked into CVS w/o any previous discussion. Actually, no code should be committed to CVS at the moment until we have made up a roadmap that outlines what we want to achieve with GIMP 2.4. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Renaming the Xtns menu
Hi everyone! Due to a suggestion on the portuguese-br translation I had set up, I renamed, in GIMP 2.2 already, the "Xtns" menu option to "Extras". "Extras" is written and means the same in PT and EN, just as Xtns was being used as abreviation of "extensÃes". I am writting this because I liked the way it feels, with a whole word in there, instead of some pr3-h4x0r dialect, and am suggesting that it gets renamed in this development cycle. On other news, I was going to update my build today, as I've returned from holydays, and anoncvs seens to be down. :-( So I am with a pre-2.2.1 build right now. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Sven Neumann writes: > Assuming your camera adds EXIF info, are you seriously telling me that > you do not run 'exiftran -a -i' on each and every image you ever shoot > and instead use GIMP to rotate them? Add another voice to all the others saying "No, I leave my originals untouched, and only edit copies". In fact, I don't think I'd ever met anyone who regularly ran exiftran on every archived original, until this discussion. Exiftran isn't even installed by default on any linux distro I've used. Is it commonly found on mac and windows machines? (in another message) Sven Neumann writes: > If the spec says it's ASCII, then we have no choice but keeping it > ASCII. That of course means that there isn't much point in allowing > anyone to edit this field since conversion to ASCII will fail for > almost all strings that a user may enter. It appears that the best we It's a bummer that it's not something like UTF-8 (and quite odd, if the spec came from Japan), but editing ASCII is still useful for quite a large number of people. What do modern cameras sold in Japan save in the EXIF fields? ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
]It's a bummer that it's not something like UTF-8 (and quite odd, ]if the spec came from Japan), but editing ASCII is still useful ]for quite a large number of people. ] ]What do modern cameras sold in Japan save in the EXIF fields? Japan has a romanized alphabet that's corresponds to their characters. Other languages like Chinese have a more difficult problem because some dialects have no standard romanized phonetic system. I wouldn't go to any extra effort to keep multibyte systems from working with data that's supposed to be ASCII, nor would I add any special functionality to support multibyte characters. Basically, do the straightforward implementation of the spec, with one exception: I would, as a user, expect my programs to be able to handle any filename, and blame any failure to do so on the image editing tool rather than the spec. At the same time, any default filename generated should be within the 8.3 standard. _-T ___ Speed up your surfing with Juno SpeedBand. Now includes pop-up blocker! Only $14.95/month -visit http://www.juno.com/surf to sign up today! ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Date: Sat, 8 Jan 2005 11:24:49 -0800 From: Akkana Peck <[EMAIL PROTECTED]> Sven Neumann writes: > Assuming your camera adds EXIF info, are you seriously telling me > that you do not run 'exiftran -a -i' on each and every image you > ever shoot and instead use GIMP to rotate them? Add another voice to all the others saying "No, I leave my originals untouched, and only edit copies". Unfortunately, thus far you and I are the only ones taking this position. I can't speak for every single photographer in the world, but as a matter of general principle, you don't mess with your negatives. The one thing I do to them is chmod 400 so I don't accidentally write over them. However, I use kimdaba (which is EXIF-aware) to index them. If I want to edit a particular image, I'll read it into the GIMP (which I can do from right-click in kimdaba), save it elsewhere (that's why the chmod 400), and then start editing it. If a particular application isn't EXIF-aware, tough on it. The ones I care about are kimdaba, the GIMP, and Photoprint, when it's ready (which one of the Gimp-Print developers is working on). Having to dismiss a completely irrelevant warning every time I want to edit a digital photograph is simply annoying. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Hi, Akkana Peck <[EMAIL PROTECTED]> writes: > It's a bummer that it's not something like UTF-8 (and quite odd, > if the spec came from Japan), but editing ASCII is still useful > for quite a large number of people. It would require unreasonable effort to create an entry that restricts editing to ASCII and for almost all languages it would be rather useless also. We should restrict ourselves to only displaying these fields. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
On Saturday 08 January 2005 13:40, Robert L Krawitz wrote: >Date: Sat, 8 Jan 2005 11:24:49 -0800 >From: Akkana Peck <[EMAIL PROTECTED]> > >Sven Neumann writes: >> Assuming your camera adds EXIF info, are you seriously telling me >> that you do not run 'exiftran -a -i' on each and every image you >> ever shoot and instead use GIMP to rotate them? > >Add another voice to all the others saying "No, I leave my >originals untouched, and only edit copies". > > Unfortunately, thus far you and I are the only ones taking this > position. You can add me to the list. I also leave my originals alone. As you say this is just good photographic practice. I have negatives that are almost 70 years old that are in nearly new condition that I got from my fathers photo collection before he died and I have my own collection of negatives and slides that goes back about 45 years. All have been carefully stored and are only touched to make "copies" (digital now days). My brother is a professional photographer and he also leaves his digital originals alone and only edits copies. I am sure that there are others on this list that also agree but have not said so on the list. In any case I don't see any reason to not do the same with digital originals. > > I can't speak for every single photographer in the world, but as a > matter of general principle, you don't mess with your negatives. The > one thing I do to them is chmod 400 so I don't accidentally write over > them. However, I use kimdaba (which is EXIF-aware) to index them. If > I want to edit a particular image, I'll read it into the GIMP (which I > can do from right-click in kimdaba), save it elsewhere (that's why the > chmod 400), and then start editing it. > > If a particular application isn't EXIF-aware, tough on it. The ones I > care about are kimdaba, the GIMP, and Photoprint, when it's ready > (which one of the Gimp-Print developers is working on). > > Having to dismiss a completely irrelevant warning every time I want to > edit a digital photograph is simply annoying. > > -- > Robert Krawitz <[EMAIL PROTECTED]> > > Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 > Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] > Project lead for Gimp Print --http://gimp-print.sourceforge.net > > "Linux doesn't dictate how I work, I dictate how Linux works." > --Eric Crampton > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer > -- Hal V. Engel pgpG26jiDBqoc.pgp Description: PGP signature
Re: [Gimp-developer] jpeg-exif development summary
From: "Hal V. Engel" <[EMAIL PROTECTED]> Date: Sat, 8 Jan 2005 14:09:29 -0800 You can add me to the list. I also leave my originals alone. As you=20 say this is just good photographic practice. I have negatives that=20 are almost 70 years old that are in nearly new condition that I got=20 from my fathers photo collection before he died and I have my own=20 collection of negatives and slides that goes back about 45 years. All=20 have been carefully stored and are only touched to make=20 "copies" (digital now days). My brother is a professional=20 photographer and he also leaves his digital originals alone and only=20 edits copies. I am sure that there are others on this list that also=20 agree but have not said so on the list. In any case I don't see any=20 reason to not do the same with digital originals.=20 It occurred to me that there's another reason not to change so much as a single bit of images: the ability to verify that an original is indeed an original. Some cameras, such as the Canon EOS 1D Mark II, are capable of signing the image, so that it can be verified that the image is unmodified. See http://consumer.usa.canon.com/ir/controller?act=ModelFeaturesAct&fcategoryid=139&modelid=9808#f3. Changing the image in the slightest -- including a lossless rotation -- would destroy this signature. Someone with this camera who needs to be able to verify photographs (perhaps because they're being used as evidence in court) could not use exiftran. Someone may want to preserve that signature, while still editing the photograph and saving it under a different name. The basic point here is that changes to the original digital file are *irreversible*, no matter how minor one thinks they may be. Photographers don't like making even the smallest irreversible changes to their master images, for good reason. I've given a specific reason, in addition to the general reason. Please don't do anything that makes life difficult for photographers who wish to perfectly preserve their originals! -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
