Re: [Gimp-developer] GAP
Hi, On Sat, 2007-08-04 at 03:44 -0400, I did notice that the file 'gap/sel-to-anim-img.scm' does not run under the TinyScheme-based Script-fu Did you also check the other Script-Fu script in the gap subdirectory? Yes. It appears to be fine. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
Hi, On Sat, 2007-08-04 at 01:58 -0300, Joao S. O. Bueno Calligaris wrote: I am getting an error linking gimp-gap svn in a 64bit enviromment, in both trunk and gap-2-2 branch: That's a problem with the copy of libavcodec that is included with GAP. You better disable support for libavcodec when configuring gap. For GAP 2.4 we should include a recent version of libavcodec. Sven To expand on Sven's answer a little, the FFMPEG project does not provide a stable API; therefore the GAP includes the source for a specific snapshot of the code and staticly links to it. The snapshot in the GAP's tree is from 2005 ; it needs to be updated and the GAP code modified to employ the new FFMPEG API (also for 64-bit support and GCC4 compatibility as well). Wolgang Hofer, the main developer of the GAP, is working on that update but he does not have direct access to the Internet right now. It may be a few months before updated FFMPEG support is available but it is being worked on. In the interim, I would suggest disabling libavcodec support and using an external utility to convert your frames to video. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
On Sunday 05 August 2007 06:45, [EMAIL PROTECTED] wrote: Hi, On Sat, 2007-08-04 at 01:58 -0300, Joao S. O. Bueno Calligaris wrote: I am getting an error linking gimp-gap svn in a 64bit enviromment, in both trunk and gap-2-2 branch: That's a problem with the copy of libavcodec that is included with GAP. You better disable support for libavcodec when configuring gap. For GAP 2.4 we should include a recent version of libavcodec. Sven To expand on Sven's answer a little, the FFMPEG project does not provide a stable API; therefore the GAP includes the source for a specific snapshot of the code and staticly links to it. The snapshot in the GAP's tree is from 2005 ; it needs to be updated and the GAP code modified to employ the new FFMPEG API (also for 64-bit support and GCC4 compatibility as well). Wolgang Hofer, the main developer of the GAP, is working on that update but he does not have direct access to the Internet right now. It may be a few months before updated FFMPEG support is available but it is being worked on. In the interim, I would suggest disabling libavcodec support and using an external utility to convert your frames to video. Hehh..that is a bit too much, ain't it? It actually _did_ build when I tweaked the Makefiles in the library dirs (and only there) to include the -fPIC GCC directive. 64 bit, GCC 4.1.1 It is not like this will only work in 2010 or 2012. js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ACO and CSS palette importing (patch attached)
Hi, On Sat, 2007-08-04 at 19:45 +0100, Nicola Archibald wrote: Attached is a patch, against svn, which adds ACO importing, and CSS color extraction, for the palette system. The ACO code only reads the version 1 section at the moment, I plan on finishing the version 2 support to extract color names a little later. Color spaces supported are RGB, CMYK, HSV and greyscale, but not Lab. The CSS import extracts colors defined in a .css file. If this patch meets the standards, perhaps someone would like to incorporate it into the repository. This patch would, I believe, enable the closing of Bug #316618 Very nice, thank you. Could you please attach these patches to the bug report? That will make sure that they aren't forgotten. Perhaps I can even get to review them later tonight. But it would still be nice to have them attached to the bug report. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using Parallel Make
Hi, On Sat, 2007-08-04 at 16:46 -0700, Don Rozenberg wrote: I recently acquired a new PC with a dual core chip running Kubuntu Feisty Fawn. So when I last tried to build Gimp, version 2.3.18, I used make -j and the build terminated with an error in just a few seconds. Is there a particular reason that you are building an outdated development release? The problem that you point out has been fixed quite a while ago and 2.3.19 includes this fix. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Downscaling quality.
A couple of weeks ago somebody commented about the quality of the downscaling in Gimp. iirc there was a patch that improved the quality (that was bumped for future releases) and there was a discussion about the pertinence of the different names of the algorithms in the interface. Well, I know that this kind of requests are not welcome when a new release is so near, but I've been using Gimp a little more this days for small images (my previous works were for print or signs, so I didn't find this issue to be critic), but now I do and I'd like to share my experiences and my concerns. I'm working in a website right now, and one of the most frequent operations is to reduce images. I coudn't get a decent reduction using the different algorithms. If you have to reduce a very large image to, say 800 px, you can use oversampling and you get a decent result, but when you're working on images for the web, which are frequently smaller than 100px, the results are very bad. If you use oversampling, the result is a blurred image. If you don't you get jagged edges.This is particularly visible when you work with type, logotipes or high contrast images. If you perform the transformation just once, the imperfections are visible. But the big problem comes when you have to perform transformations a couple of times. And this operations are not rare. It's very common to scale down an image, rotate it and then tweak the size again. The last time I mentioned this, Sven replied: I might be wrong but I think the current algorithms are basically the same as the ones used in GIMP 2.2. So there's really no point in addressing this long-standing but minor issue before 2.4. I thought then that it was ok, but I've changed my mind. It's not minor at all. Since Gimp doesn't support CMYK, it is not a viable tool for image processing for print, so we have a tool mostly for screen works. One of the main professional applications for that is preparing images for the web, and this issue is critic for that kind of work. As a little example, I had to create a button for changing a website's language. I had a high resolution flag of the UK and wanted to reduce it. I coudn't get the image right, by any means. I had to re-draw it using single pixels (I know that diagonal lines are difficult to represent in small sizes, so don't start to call me stupid. I made the same work before with other software and got better results). The release of the 2.4 will be a huge event. The program went through very important changes, and it's becoming a truly professional application. If you compare 2.3.x with 2.2.x the difference is impressive. Now Gimp looks and feel professional. It would be a shame to inherit that limitation from 2.2 series and have to wait until the next version (which, considering the whole GEGL thing. won't be ready soon). Please don't take this comments as another stupid user request. This is very important and for me is the major issue that obstaculizes my migation to Gimp. I'd like to have CMYK, of course, but color management is enough for now, since CMYK is not a small change. I'm not telling that's a small change either, but I think it's critic enough to take a look before 2.4 I've discussed this with several users and they share my point of view. I'd like to know what you guys think about it, and if it's possible, revise the situation before 2.4 Thanks in advance, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Downscaling quality.
On 8/6/07, Guillermo Espertino [EMAIL PROTECTED] wrote: A couple of weeks ago somebody commented about the quality of the downscaling in Gimp. iirc there was a patch that improved the quality (that was bumped for future releases) and there was a discussion about the pertinence of the different names of the algorithms in the interface. Well, I know that this kind of requests are not welcome when a new release is so near, but I've been using Gimp a little more this days for small images (my previous works were for print or signs, so I didn't find this issue to be critic), but now I do and I'd like to share my experiences and my concerns. I'm working in a website right now, and one of the most frequent operations is to reduce images. I coudn't get a decent reduction using the different algorithms. If you have to reduce a very large image to, say 800 px, you can use oversampling and you get a decent result, but when you're working on images for the web, which are frequently smaller than 100px, the results are very bad. If you use oversampling, the result is a blurred image. If you don't you get jagged edges.This is particularly visible when you work with type, logotipes or high contrast images. You don't appear to be using oversampling, as you say: If you perform the transformation just once, the imperfections are visible. But the big problem comes when you have to perform transformations a couple of times. Oversampling cancels that out, because the increased resolution minimizes loss of meaningful data. (oversampling == editing at a increased resolution relative to intended final size.) Perhaps you mean supersampling? And this operations are not rare. It's very common to scale down an image, rotate it and then tweak the size again. For now, you should rotate before scaling down if possible. The last time I mentioned this, Sven replied: I might be wrong but I think the current algorithms are basically the same as the ones used in GIMP 2.2. So there's really no point in addressing this long-standing but minor issue before 2.4. I thought then that it was ok, but I've changed my mind. It's not minor at all. Since Gimp doesn't support CMYK, it is not a viable tool for image processing for print, so we have a tool mostly for screen works. One of the main professional applications for that is preparing images for the web, and this issue is critic for that kind of work. As a little example, I had to create a button for changing a website's language. I had a high resolution flag of the UK and wanted to reduce it. I coudn't get the image right, by any means. I had to re-draw it using single pixels (I know that diagonal lines are difficult to represent in small sizes, so don't start to call me stupid. I made the same work before with other software and got better results). This is an artefact of the way downscaling currently works: it examines 2x2 pixels for each output pixel. This means if you're downscaling to less than 50%, some source pixels are ignored. If Cubic was properly implemented for downscaling, it would examine 4x4 pixels for each output pixel, and some pixels would be ignored when scale 25%. Presently, the solution to this is to scale down incrementally (reduce scale by 50% until you approach the desired scale, and then scale down to that exact size.) Maybe GIMP could implement the above workaround before 2.4. It would be inefficient (scaling down the image N times instead of once) but it would mean that the result was correctly dependant on ALL the source pixels. Non-destructive transformation is something that would be more sensible to implement after 2.4. The release of the 2.4 will be a huge event. The program went through very important changes, and it's becoming a truly professional application. If you compare 2.3.x with 2.2.x the difference is impressive. Now Gimp looks and feel professional. It would be a shame to inherit that limitation from 2.2 series and have to wait until the next version (which, considering the whole GEGL thing. won't be ready soon). Please don't take this comments as another stupid user request. This is very important and for me is the major issue that obstaculizes my migation to Gimp. I'd like to have CMYK, of course, but color management is enough for now, since CMYK is not a small change. I'm not telling that's a small change either, but I think it's critic enough to take a look before 2.4 I've discussed this with several users and they share my point of view. I'd like to know what you guys think about it, and if it's possible, revise the situation before 2.4 Thanks in advance, Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Downscaling quality.
David Gowers wrote: Perhaps you mean supersampling? Yes, it must be. I'm using a spanish localization of Gimp and try to guess the correct translation. Is there a command line option to launch gimp in english (just once, not permanent) so I can use the correct words when I'm reporting a bug or discussing something like this? For now, you should rotate before scaling down if possible. Yes, I try to do it. But it isn't always possible. Most of the times you have to make minor adjustments, and that progressively destroys image data. The opaque copy of the original tends to make the process of tweaking longer, because you can't see the context. Making the original image semi-transparent would be a great help. Presently, the solution to this is to scale down incrementally (reduce scale by 50% until you approach the desired scale, and then scale down to that exact size.) Nice tip. I'll try it. It's not that comfortable but at least is a workaround. Maybe GIMP could implement the above workaround before 2.4. It would be inefficient (scaling down the image N times instead of once) but it would mean that the result was correctly dependant on ALL the source pixels. Yes, this sounds interesting. I'd prefer a little slower transformation if the image quality isn't so compromised. Non-destructive transformation is something that would be more sensible to implement after 2.4. Yes, sure. Non-destructive transformation with GEGL will be great. But it won't be here inmediately, and it would be great to have not-so-destructive transformations while we wait. Thanks for your reply, David. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Downscaling quality.
Guillermo Espertino ([EMAIL PROTECTED]) wrote: David Gowers wrote: Perhaps you mean supersampling? Yes, it must be. I'm using a spanish localization of Gimp and try to guess the correct translation. Is there a command line option to launch gimp in english (just once, not permanent) so I can use the correct words when I'm reporting a bug or discussing something like this? Try LANG=C gimp AFAIK this works in most unix shells, most notably in bash. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
