[Gimp-developer] Re: Your application
Please see the attached file.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: W32/Sobig virus? [adrian@gimp.org: [Gimp-developer] Re:Approved]
On Wed, 4 Jun 2003 15:29:11 -0700, A Guy Called Tyketto [EMAIL PROTECTED] wrote: It appears that someone (maybe on gimp-developer, maybe not) has been socked with the W32/Sobig virus/worm. It's similar to the KLEZ worm, but is a bit more picky. I've been getting a lot of messages like below, but since my main machine is a linux box, I'm not getting infected. Spamassassin is helping to find it, but thought everyone would want to know. From the NANOG mailing list: [...] http://vil.nai.com/vil/content/v_100343.htm (W32/[EMAIL PROTECTED]) which is klez [...] The page linked from the message that you quoted contains this note: * Note: This variant spoofs, or forges, the from address. Therefore the perceived sender is likely not a pointer to the infected user. It is also likely that the infected user is not a member of gimp-developer. As the worm scans the address books and all HTML and text files on the victim's computer, it is not hard to imagine that it could have found some GIMP-related addresses in the same file and sent a mail claiming to be from Adrian (or Adam, as in the last message) to the gimp-developer list. The victim can be any user of the Windows version of the GIMP (the worm would have found the addresses in the documentation) or any user of any version of the GIMP who was using a Windows PC for browsing some GIMP-related web pages (the worm would have found the addresses in the browser's cache). In any case, there is a rather low probability that this user is a member of this list. And by the way, there are relatively few of these worm-generated messages that made it through the gimp-developer list. I assume that most of the messages targeted at this list were bounced to our dear list maintainer. I have seen many more worms going through the address [EMAIL PROTECTED], for example (in the order of several dozens per day, although I did not count them). -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Application
Please see the attached file.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Submited (004756-3463)
Please see the attached file.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Your application
Please see the attached file.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Approved
Please see the attached file.___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
Feczak Szabolcs [EMAIL PROTECTED] writes: Changing the color balance/brightens-contrast/ color curves are significantly slower in gimp vs. photoshop on the same machine. The problem is not the processing time alone, but the preview takes the same amount of time as the final processing. I have relized, that gimp calculates all the data in preview mode as I would have pressed the ok button. Very well spotted. Other good idea came from my friend: creating a smaller image in memory, which has the resolution of the screen and calculating the preview on that image. That is obviously the approach that should be taken. AFAIK, there are no plans to do such an improvement. Considered that we still lack some funding for our developers conference this summer, perhaps we could be persuaded to give it a try. Ok, what do you need to be more persuaded ? -- _(_)_ (_. o_)F3CZ0 (_,) http://feczo.koli.kando.hu ()__ // // ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images
I was thinking abiut the subject , and came to a way of doing it - if PDB calls can be made normaly from inside these plugins - which I assume thay can, without problens. Therefore, if you will allow me, I will describe what I was thinking in gimp pseudocode. Someone more familiar to the core than I could tell me if there is a fundamentla flaw. If it allright, than I think it could be implemented in less than a couple of weeks: In summary before for performing a preview in such filters, this could be done: 1 - Test from viewing window and scale, and from memory avaliability, if it's worth to use these optimizations. 2 - Create a new image - new drawable if we are working in a single layer image, or top visible layer in normal mode. 3 - If the current selection is larger than the viewable area store it somewere, and intersect it with the viewable area 4 - if the image is zoomed out copy all visible layers to the new image created, and scale it down in linear mode, in a manner that each pixel in it is equivalent to a pixel on the screen at the subject image. 5 - perform the filter action ont he corresponding layer on the new image. 6 - copy visible the new image 7 - create a new temporary drawable on top of all visible layers on the subject image 8 - paste draft image visible contentes on new drawable, position and scale it accordingly. 9 - repeat 5,6 and 8 until the filter is commited or cancelled 10 - restore selection, delete temporary layer and temporary images 11 - commit changes. What do you think about it? Of what I've seen on the code, it seens that each such filter does it's own changes on the images. They all would have to be individually modified to use the steps above. Still doesn't seen hard: a - if filter is in preview mode, calls a procedure that makes steps 1 - 4 above, and return a new drawable. b - perform filter action on drawablem and call a procedure that will perform 5, 6,7 (once) and 8 above. c - on ok or cancel, call something to make 10, and perform 11 Feczak Szabolcs wrote: Feczak Szabolcs [EMAIL PROTECTED] writes: Changing the color balance/brightens-contrast/ color curves are significantly slower in gimp vs. photoshop on the same machine. The problem is not the processing time alone, but the preview takes the same amount of time as the final processing. I have relized, that gimp calculates all the data in preview mode as I would have pressed the ok button. Very well spotted. Other good idea came from my friend: creating a smaller image in memory, which has the resolution of the screen and calculating the preview on that image. That is obviously the approach that should be taken. AFAIK, there are no plans to do such an improvement. Considered that we still lack some funding for our developers conference this summer, perhaps we could be persuaded to give it a try. Ok, what do you need to be more persuaded ? JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images
Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: I was thinking abiut the subject , and came to a way of doing it - if PDB calls can be made normaly from inside these plugins - which I assume thay can, without problens. We are not talking about plug-ins here. Previews for plug-ins are handled by the GimpPreview widget that Ernst was working on and should find its way into CVS soon (at least I hope that it will). We are talking about tools here. The strategy how to handle this stuff is pretty obvious and resembles what you suggested. The fact is that such a change would affect a lot of core code since it should be implemented on a relatively low level. This is something we can not do at this point of the development. It should however be a design goal for the upcoming redesign of the GIMP core. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
W32/Sobig virus? [adrian@gimp.org: [Gimp-developer] Re: Approved]
It appears that someone (maybe on gimp-developer, maybe not) has been socked with the W32/Sobig virus/worm. It's similar to the KLEZ worm, but is a bit more picky. I've been getting a lot of messages like below, but since my main machine is a linux box, I'm not getting infected. Spamassassin is helping to find it, but thought everyone would want to know. From the NANOG mailing list: --snip-- On 03.06 13:44, Dominic J. Eidson wrote: I'm having a feeling that someone harvested a bunch of adresses, possibly from NANOG, and is using them as the sender address in pretend-to-be KLEZ spams.. I have received several bounces lately, several of them appearing to be KLEZ, all with me as the original sender Just to add another data point: The same thing started happening to me a few days ago. I do not know any of the recipients of the bounces but some people I *do* know advised me they are getting them. I cannot say whether this is really KLEZ or not, not enough data. http://vil.nai.com/vil/content/v_100343.htm (W32/[EMAIL PROTECTED]) which is klez like in how it picks its targets Its been on a rampage since the Friday night. --snip-- If you're on the list with your MUA being windows based, please visit the URL above, get info on the worm, and update your virus programs and mailfilters. Right now, I have virii and spam going to /dev/null, but brought this out to give everyone a heads up. BL. - Forwarded message from [EMAIL PROTECTED] - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Gimp-developer] Re: Approved Date: Wed, 4 Jun 2003 17:02:24 +0200 X-Spam-Flag: YES X-Spam-Status: Yes, hits=5.5 required=5.0 tests=FORGED_MUA_OUTLOOK,MISSING_MIMEOLE,NO_REAL_NAME, RAZOR2_CF_RANGE_91_100,RAZOR2_CHECK version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) This mail is probably spam. The original message has been attached along with this report, so you can recognize or block similar unwanted mail in future. See http://spamassassin.org/tag/ for more details. Content preview: This is a multipart message in MIME format Please see the attached file. MIME-Version: 1.0 Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer [...] Content analysis details: (5.50 points, 5 required) NO_REAL_NAME (1.1 points) From: does not include a real name RAZOR2_CF_RANGE_91_100 (1.2 points) BODY: Razor2 gives a spam confidence level between 91 and 100 [cf: 100] RAZOR2_CHECK (0.9 points) Listed in Razor2, see http://razor.sf.net/ MISSING_MIMEOLE(0.1 points) Message has X-MSMail-Priority, but no X-MimeOLE FORGED_MUA_OUTLOOK (2.2 points) Forged mail pretending to be from MS Outlook The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. Content-Description: original message before SpamAssassin Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 4 Jun 2003 17:02:24 +0200 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) Subject: [Gimp-developer] Re: Approved X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.1b4 Precedence: list List-Id: gimp-developer.lists.xcf.berkeley.edu List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer, mailto:[EMAIL PROTECTED] List-Unsubscribe: http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer, mailto:[EMAIL PROTECTED] List-Archive: /lists/gimp-developer List-Help: mailto:[EMAIL PROTECTED] Errors-To: [EMAIL PROTECTED] Please see the attached file. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer - End forwarded message - -- Brad Littlejohn | Email:[EMAIL PROTECTED] Unix Systems Administrator, | [EMAIL PROTECTED] Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF pgp0.pgp Description: PGP signature
