Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
On 2/6/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Mon, 2007-02-05 at 22:38 +0100, Marco Ciampa wrote: I just noted this strange behaviour: when I see the the Image menu-View-Display filters-Color Deficient Vision options (Protanopia, Deuteranopia, Tritanopia) with the Italian locale, _all_ but these three options are translated. Is it my svn copy fault or does it have this behaviour in other languages too? Sorry, but I don't understand your question. What's translated and what's not? And did you already check in the it.po files that the strings have been translated at all? As of current po-libgimp/it.po #: ../modules/cdisplay_colorblind.c:67 msgid Protanopia (insensitivity to red) msgstr Protanopia (insensibilità al rosso) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Hi, On 2/6/07, Sven Neumann [EMAIL PROTECTED] wrote: BTW, does this plug-in use GimpPreview widgets? I would like to get some feedback on features and API of GimpPreview and its derivatives. It actually uses GtkDrawingArea. This is related to zoom cropping functionality. If we dropped cropping, one of Gimp widgets could be used. Is there any widget which supports - zoom in out - GIMP quick navigation widget in the corner of the scroll bars - access to cursor coordinates to give extra control with mouse? Thanks ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
Hi, On 2/7/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tuesday, February 6, 2007, 20:03:59, peter sikking wrote: - that in-dialog cropping looks like a very uncomfortable way to do that to me; - simply display the Size in the fields that are now called Resize now without the open/close triangle, and remove the other size display; I actually find resize/crop controls redundant in the Save for Web dialog - I usually prepare the image beforehand while keeping it in a native (lossless) format, then just expect to use Save for Web to export the image for upload to a website without touching the original. The idea is based one of bug list's enhancment request which asks to save image for Internet, ie user wants image to be as small as possible (for example to send with mail or put to forum) and some parts could be cropped and picture could be resized until wanted file size is reached. It was then decided that this functionality should be put in save for web plug-in. (see http://bugzilla.gnome.org/show_bug.cgi?id=317100 ) Maybe we should discuss again if this functionality is needed and if so, is it convenient to integrate it into save for web plug-in. Thanks. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
On Wed, Feb 07, 2007 at 09:29:57AM +0100, Sven Neumann wrote: On Wed, 2007-02-07 at 09:12 +0100, Marco Ciampa wrote: [...] Resolving this error I get another error: Making all in po-libgimp make[2]: Entering directory `/home/marco/svn-gnome/gimp/trunk/po-libgimp' Makefile:159: *** target pattern contains no `%'. Stop. make[2]: Leaving directory `/home/marco/svn-gnome/gimp/trunk/po-libgimp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/marco/svn-gnome/gimp/trunk' make: *** [all] Error 2 Exaclty on the po files where I see the problem, perhaps resolving this fixes it all... Yes, that might very well fix the problem for you. I remember that I used to have this issue with the po-libgimp Makefiles myself. Now if only I could remember how I fixed it... Perhaps may help if I post the source lines of the Makefile that trigger the error: [...] all: all-yes all-yes: $(CATALOGS) all-no: #here is the problem! $(GETTEXT_PACKAGE).pot: $(POTFILES) $(GENPOT) [...] TIA -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On Wed, Feb 07, 2007 at 01:58:21PM +0100, [EMAIL PROTECTED] wrote: Despite the idiot-user title of this feature (copied for PS it seems) ... If the user is so lame that they are going to click on a feature called save for the web If a user wants to save images for use on the web, save_for_the_web is high level thinking and not lame or idiotic. The choice of format is secondary. 1. save for web 2. use most appropiate format Someone choosing save for the web needs help, let's provide some rather than maintaining them in thier ignoracen and providing enevitably compromised solutions. I know the characteristics of JPG, PNG, GIF. I can usually tell what will work best. There are border cases, though. Then I have to experiment and can't formulate save_as_jpg or save_as_my_png as my initial goal at all. -- Thorsten Wilms Thorwil's Creature Illustrations: http://www.printfection.com/thorwil ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On Wed, 07 Feb 2007 14:32:04 +0100, Thorsten Wilms [EMAIL PROTECTED] wrote: On Wed, Feb 07, 2007 at 01:58:21PM +0100, [EMAIL PROTECTED] wrote: Despite the idiot-user title of this feature (copied for PS it seems) ... If the user is so lame that they are going to click on a feature called save for the web If a user wants to save images for use on the web, save_for_the_web is high level thinking and not lame or idiotic. I said idiot-user title, it is that sort of title that is treating the user as an idiot. I should probably have chosen a more precise and less emotive term than lame. In chosing save for the web the use indicates he does not know what is involved and is expecting gimp to magically do it for him, not unreasonably since the program is offering that as an option. I believe offering that option to be a mistake. It seems to be mainly motivated by Photoshop does it so we ought to as well. The choice of format is secondary. 1. save for web 2. use most appropiate format Someone choosing save for the web needs help, let's provide some rather than maintaining them in thier ignoracen and providing enevitably compromised solutions. I know the characteristics of JPG, PNG, GIF. I can usually tell what will work best. There are border cases, though. Then I have to experiment and can't formulate save_as_jpg or save_as_my_png as my initial goal at all. Well if you can tell what usually works best that probably means you'll slightly better than a save for the web feature anyway. You'll probably be able to set an appropriate jpeg compression level for your specific image based on the quality your require for your context. In other cases, where you need to experiment, you clearly indicate you know what you're doing and my comments dont apply to you. What I am suggesting is empowering users to get to that stage rather than providing mediocre results with optimisations determined without established criteria or prior knowlege of the data. We have the choice to provide a better solution than PS rather than just playing catch-up. That's what I'd like to see. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated
On 2/7/07, gg wrote: I should probably have chosen a more precise and less emotive term than lame. In chosing save for the web the use indicates he does not know what is involved and is expecting gimp to magically do it for him, not unreasonably since the program is offering that as an option. I believe offering that option to be a mistake. It seems to be mainly motivated by Photoshop does it so we ought to as well. When you save JPEGs, generally you do it either for web-gallery, or for print, or for display (to be used as wallpaper or something). Peter might correct me, but Save for Web implies doing a tradeoff between quality and file size, whereas neither print nor display destinations require that. Thus Save for Web is a plug-in that deals with a specialized usecase. That's it. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
On Wed, Feb 07, 2007 at 11:59:43AM -0200, Joao S. O. Bueno Calligaris wrote: On Wednesday 07 February 2007 07:31, Alexandre Prokoudine wrote: On 2/6/07, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Mon, 2007-02-05 at 22:38 +0100, Marco Ciampa wrote: I just noted this strange behaviour: when I see the the Image menu-View-Display filters-Color Deficient Vision options (Protanopia, Deuteranopia, Tritanopia) with the Italian locale, _all_ but these three options are translated. Is it my svn copy fault or does it have this behaviour in other languages too? Sorry, but I don't understand your question. What's translated and what's not? And did you already check in the it.po files that the strings have been translated at all? As of current po-libgimp/it.po #: ../modules/cdisplay_colorblind.c:67 msgid Protanopia (insensitivity to red) msgstr Protanopia (insensibilità al rosso) So, do you know if ther eis an Italian word for it,a nd which it is? If there are proper Italian words for that, just send then to the list and we will fix(exceptionally, the normal course would be to ask for the change in bugzilla.gimp.org) I am the trasnaltor for Brazillian portuguese, and as far as I know these exact terms can be used in my language, so they are not changed in the pt_BR translation as well. The terms are the same in italian (they actually come from Latin) so the translation is correct and complete, thanks. See the other thread, perhaps the problem is in the automake/autoconf process that creates an invalid Makefile for the po-libgimp directory. I'm sorry, I'm not an expert in automake/autoconf/make so I do not know how should look a correct Makefile to handle correctly the compilation/update of these .po files. bye -- Marco Ciampa ++ | Linux User #78271 | | FSFE fellow #364 | ++ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colorize - Lightness != luminosity?
On Wed, 2007-02-07 at 08:57 +0100, Sven Neumann wrote: As far as I understand the dialog doesn't show absolute values for Saturation and Lightness but relative ones. Perhaps the Saturation slider should also go from -100 to +100 then. Saturation appears to be absolute. Lightness is relative. See below. First of all someone should take a look at the code and find out what it really does. I very much doubt that anyone here can tell you this without looking at the code. So why don't you just have a look and tell us what you found? Okay, here's how it looked to me. I had to trace through to figure out where the meat was being cooked, so this includes my tracing (in case I missed something): Call sequence for changing the Lightness slider in the Colorize dialog: * app/tools/gimpcolorizetool.c:colorize_lightness_adj_update() colorize_lightness_adj_update() is the callback in the Colorize dialog that handles Lightness slider changes. * app/tools/gimpcolorizetool.c:colorize_lightness_adj_update() colorize_lightness_adj_update() calls colorize_update() after retrieving the L value from the dialog and saving it in a Colorize structure. The Colorize structure holds current HSL values as gdoubles and two sets of 3 256-entry tables, one set of 3 for Luminance lookups and one set of 3 for RGB lookups. Colorize is initialized (by colorize_init()) so that the Lum lookup table is non-zero. * app/tools/gimpcolorizetool.c:colorize_update() colorize_update() calls colorize_calculate() before updating dialog controls. * app/base/colorize.c:colorize_calculate() Doesn't use the L component of Colorize structure. It simply computes 256 RGB lookup values (0-255) and sets L to i/255.0 for each component, using the S and H components passed in the Colorize structure. The H and S components are used as you would expect in HSV space: the value for H is divided by 360 and the value for S is divided by 100. * app/tools/gimpimagemaptool.c:gimp_image_map_tool_preview() For the Colorize dialog, which has a preview, this function calls gimp_image_map_tool_map(). colorize_lightness_adj_update() then calls gimp_image_map_tool_preview(). * app/tools/gimpimagemaptool.c:gimp_image_map_tool_preview() This call sequence eventually calls the gimp_colorize_tool_map() function to do the preview update. * app/tools/gimpcolorizetool.c:gimp_colorize_tool_map() gimp_colorize_tool_map() calls gimp_image_map_apply(), which is passed the colorize() function and a Colorize structure, along with the a structure containing a pointer to the drawable (re: preview) to update. app/base/colorize.c:colorize() At each pixel across the width and height of the preview: Note: L = slider setting in the dialog, ie colorize-lightness lum inits to the combined luminance of the current pixel based on the luminance lookup table in the Colorize structure. If L 0, lum = (gdouble) lum * (100.0 - colorize-lightness) / 100.0; lum = += 255 - (100.0 - colorize-lightness) * 255.0 / 100.0; else if L 0 lum = (gdouble) lum * (colorize-lightness + 100.0) / 100.0; New pixel value is RGB = Colorize.RGBlookup[lum] (Alpha preserved) This means: If L = 0 then the pixel is always the luminance of the selected H/S combination. If L 0 then the pixel is the (absolute value of the lightness slider)% of the current pixels luminance for the selected H/S combination. If L 0 Add the (lightness slider)% of 0-255 to (lightness slider)% of the pixels current luminance and use that to compute the new color from the RGB table based on the H/S combination. It's unclear to me why the percent of 0-255 is added to a percent of the current luminance value instead of directly to the current luminance value though I can see why you might want to have -100 to 100 for the L slider: negative slider values reduce luminance of the current pixel while positive values increase it. You need to do this because your working relative to the current pixel and not on an absolute scale. In other words, the L slider is a percent increase or percent decrease in any given pixels luminance. Sort of. -- Michael J. HammelSenior Software Engineer [EMAIL PROTECTED] http://graphics-muse.org -- Failure is not an option. It comes bundled with your Microsoft product. -- Ferenc Mantfeld ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colorize - Lightness != luminosity?
On Wed, 2007-02-07 at 10:23 -0700, Michael J. Hammel wrote: On Wed, 2007-02-07 at 08:57 +0100, Sven Neumann wrote: As far as I understand the dialog doesn't show absolute values for Saturation and Lightness but relative ones. Perhaps the Saturation slider should also go from -100 to +100 then. Saturation appears to be absolute. Lightness is relative. See below. Exactly. I don't remember the actual math involved and didn't try to follow your elaborate code path description. When I implemented this it was pretty clear from the beginning that -100% 'L' would have to make the image all black and +100% 'L' all white, and all values in between would be linear interpolations. That's how it was implemented in the end. No voodoo involved :-) The only point potentially open for discussion would be what the proper word for 'L' is. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colorize - Lightness != luminosity?
On Wed, 2007-02-07 at 20:08 +0100, Michael Natterer wrote: I don't remember the actual math involved and didn't try to follow your elaborate code path description. When I implemented this it was pretty clear from the beginning that -100% 'L' would have to make the image all black and +100% 'L' all white, and all values in between would be linear interpolations. That's how it was implemented in the end. No voodoo involved :-) The only point potentially open for discussion would be what the proper word for 'L' is. I think Lightness is fine from an end user perspective. The docs need to be updated to reflect the real meaning behind the slider (and it's name - the docs call it Value at the moment). The reason this came up at all was that someone asked what units were associated with those sliders, which led me to ask what the real meaning was for each slider. Now I know. :-) I've got a minor patch for the english version of the online docs. I'll submit it to the gimp-docs mailing list. Thanks. -- Michael J. HammelSenior Software Engineer [EMAIL PROTECTED] http://graphics-muse.org -- His men would follow him anywhere, ... but only out of morbid curiosity. -- From a real employee performance evaluation. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
On 2/7/07, Sven Neumann wrote: Hi, On Wed, 2007-02-07 at 05:39 +0300, Alexandre Prokoudine wrote: While we are discussing it, is it possible to add a remark to the current dialog that enabling preview also calculates size of resulted file? I already heard several times from new users that GIMP doesn't calculate resulted JPEG files size at all. This is a tiny change and it I believe that it can make it's way to 2.4 There's a tooltip on the file-size label for exactly this purpose. As of 2.3.14 there is not such tooltip. DIsplay of tooltips is enabled in preferences. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Comments on code
Hello. There's some time I wanted to contribute to a free software project and now I am diving in the code of gimp. I find it quite difficult to know where to start with. One thing that surprised me is the lack of comments in the code. I am used to have at least one comment per function and one for each file explaining what goes there and what it does. I don't know if this is a question of style, but I think it would make things easier for new people aiming to help. I thought in putting comments in the code as I achieve to understanding functions and files, and submitting them as patche. I want to know if you think it is a good idea or it would be a useless task, or if there is some reason for leaving things as they are now. I also want to use this occasion to ask advice in where to start reading and taking familiarity with the gimp code. Thanks, Mu. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] strange localization behaviour (gimp-2.3-svn)
Hi Marco,
if I remember correctly this is fixed by removing the generated files
POTFILES in all po subdirectories. Try this command in the toplevel gimp
source directory:
find . -name POTFILES -exec rm {} \;
Then do a rebuild. The problem here is that the Makefile rules to
generate the files used to be broken. We fixed the Makefiles but there's
no dependency that would cause the broken files to be regenerated.
Sven
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Comments on code
Hi, On Thu, 2007-02-08 at 01:28 +0100, Mu wrote: I thought in putting comments in the code as I achieve to understanding functions and files, and submitting them as patche. I want to know if you think it is a good idea or it would be a useless task, or if there is some reason for leaving things as they are now. We would appreciate if someone commented some more of the internal functions with well-written gtk-doc style comments. That would improve the documentation of the core as seen on http://developer.gimp.org/api/2.0/app/index.html Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Hi, On Thu, 2007-02-08 at 02:36 +0300, Alexandre Prokoudine wrote: As of 2.3.14 there is not such tooltip. DIsplay of tooltips is enabled in preferences. There is. I just checked once more (and I had already checked yesterday). Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Save As JPG Integrated (mockup)
Hi, On Thu, 2007-02-08 at 10:41 +0300, Alexandre Prokoudine wrote: What I was trying to tell you is that that message exists, but doesn't show up. Which means that something is broken ;-) It does show up. So the brokeness seems to be on your setup. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
