Re: [Gimp-developer] Could you please tell me the implementation of gimp_image_get_colormap function?
Am Freitag, 26. August 2011 schrub Zhenxing Zhou: Hi All, Hi. I read the code of GIMP v2.6.11 and I want to find the code of *gimp_image_get_colormap *declared in* *libgimp\gimpimage.h. gimp_image_get_colormap calls _gimp_image_get_colormap in libgimp\gimpimage_pdb.c _gimp_image_get_colormap calls gimp_run_procedure (gimp-image-get-colormap... in libgimp\gimp.c gimp_run_procedure calls gimp_run_procedure2 in libgimp\gimp.c gimp_run_procedure2 calls gp_proc_run_write in libgimpbase\gimpprotocol.c gimp_wire_write_msg calls (* handler-write_func) (channel, msg, user_data) in libgimpbase\gimpwire.c Then I lost the track of gimp_image_get_colormap. Could you please tell me which code in which file real implement the * gimp_image_get_colormap* function? It's the first function in src/libgimp/gimpimage.c. I'm a beginner in C language. Thank you very much. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Modify alpha transparency of selected pixels?
Am Samstag, 25. Juni 2011 schrub Jeremy Morton: [...] you can use masks on selected pixels I don't see how that lets you actually set the pixel's alpha value, though. You have to mess around with the mask getting its pixels just the right value to make the pixel's alpha value right, which is probably harder than using the cut/paste/merge method I mentioned previously. What I really want to be able to do is enter a number and set the selected pixels' alpha transparency to that number. You can enter that number in the colour dialog and fill the mask with the resulting colour. Since you already selected the pixels the mask will only be changed for those. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dropping Scheme with gimp 2.8?
Am Freitag, 17. Dezember 2010 schrub Andreas_P: houz (don't know real name for now) That would be me. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
Am Sonntag, 12. September 2010 schrub Mirza Husadzic: [...] The algorithm: As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is constructed and pushed into hash table. If key is uniuqe then line in stroke is valid. If key is duplicated, then line is rejected and current stroke ends (begin of a new stroke). That's it. This method can be applied even if paths are merged from GUI. I will further test this approach with other shapes from SVG (cubic bezier, ellipse etc). If they are flattened on lines, at this stage, maybe this may work with them too. But, I'm not sure about this. I didn't tested it. I would like to hear you opinions. I haven't looked into your patch nor do I know how GIMP actually draws the paths. So if I'm writing nonsense – just ignore me. ;-) As I understand the previous mails the problem is that each path is painted using XOR so an even number of paths over a single pixel will be invisible. What about not drawing on the canvas using XOR but maintaining an extra 1-bit- buffer on which the paths are painted and which in the end is XORed to the image? I don't know if that's too much overhead or if it doesn't make any sense at all. It just came to my mind … Cheers, Mirza. Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Zooming in Single Window Mode
Am Mittwoch, 18. August 2010 schrub Liam R E Quin: On Wed, 2010-08-18 at 08:33 +0200, Mathias Lindner wrote: Hi, I run the current development version of GIMP (2.7.2). In single window mode I experience a very annoying issue. One example to reproduce this: choose the brush tool, create a new layer and change it's opacity with the slider. And now it comes: I want to zoom into the image with the + and - keys on my keyboard. Or I want to move the displayed detail using the space bar - before I start painting... Yes, this is a detail that needs more work. Inkscape has a similar problem Which uses ESC to defocus the widgets. Still annoying but better than nothing. [...] Liam Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another set of feature-wishes regarding Guides
Am Samstag, 7. August 2010 schrub oli...@first.in-berlin.de: Hello, 1) it is possible to make guides invisible/visible and to make them magnetic/nonmagnetic. Both features are independent, which is good for some situations. To make them invisible as well as non-magnetic at the same time, two check boxes must be enabled/disabled. The possibility to make both with one click would be fine: visible magnetic / invisible non-magnetic. I don't have an installed GIMP around so I cannot test it: are invisible guides magnetic? If not then your request is void as making them invisible will also make them non-magnetic. If yes then that sounds (at least to me) like a bug/design flaw. Also it would be fine to have keyboard-shortcuts for all those check-boxes. It should be possible to assign them youself. [...] Ciao, Oliver Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Am Sonntag, 1. August 2010 schrub Christopher Curtis: [...] but HTML is a decent way to store stylized text. HTML may be suitable to store basic things like size, font face, color and so on, but it's far from typographic needs like manual kerning, … HTML isn't meant to describe the form of data but the content. In an ideal world all form would be defined with CSS. So better stop dreaming of HTML in GIMP. The best I can think of is an plugin which takes the text layers, throws away all the information it doesn't understand and output the rest as HTML. Chris Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Am Samstag, 31. Juli 2010 schrub bob: Hi guys. Hey. Smashing magazine linked to an interesting blog entry, where John Nack discusses the possibility of HTML layers in photoshop. If I understand the gist of his proposition/fantasy, the idea is the ultimately his image editor would have a feature that can import, present and edit html elements as components of a layer. I don't see any use cases where that would help. It won't help to get images fit better to an existing page as every HTML renderer has slightly different output. And importing a HTML page to generate the whole output reminds me of old pr0n pages where everything was an image – don't do that, it's usability nightmare. Besides I strongly believe in the unix philosophy of one task, one tool: GIMP for the images, vim for the HTML. [...] Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] html layers
Am Samstag, 31. Juli 2010 schrub Alexandre Prokoudine: On 7/31/10, Tobias Ellinghaus wrote: Smashing magazine linked to an interesting blog entry, where John Nack discusses the possibility of HTML layers in photoshop. I don't see any use cases where that would help. Then you might want to read up on recent trends in web programming. You see, these days CSS can do a lot of stuff that used to be done with layer effects and whatnot in Photoshop before: gradient overlays, rounded rectangles, inset text and so on. And CSS is a standard. Exactly my point: We already have CSS, so why should GIMP be used for that? Alexandre Prokoudine Tobias [...] signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Please fix Color and/or Value transfer mode
Am Donnerstag, 29. Juli 2010 schrub Charlie De: Just in case, not everyone in this list is a GIMP developer. There are ways and ways to be involved in the project, so there's not much point counting opinions just because they were expressed. We all have our own ideas how GIMP could evolve, what bugs should be fixed first and so on, but as long as we do not write code, priorities are set by people who do. I beg to differ. Priorities must ultimately be set by end users. Wrong. This is open source. That implies that whoever writes the code decides. If you don't agree in their decision you are free to grab your favorite text editor and do the changes yourself. Or find someone whom you can pay to do it for you. IMO it's extremely rude to tell anyone what to do when all they do is done for free for your pleasure. So fix it or STFU. And I would repeat that the majority of end users would favour timely fixes of essential functionality over concerns how those fixes will render existing files. My only point in all this is one of priorities. By all means do whatever can be done to reduce any inconvenience of the new rendering, but don't use the compatibility issue as a block to essential fixes. Not for 4 years! I don't think any serious user would be willing to throw away his work of the last years just because GIMP breaks backwards compatibility. If that's ok for you it tells quite a lot about the quality of your work. [...] Charlie Tobias, who tries to calm down again. It's just that this kind of attitude pisses me off. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Could new version of gimp building swf?
Am Dienstag, 1. Juni 2010 schrub Hades: Could new version of gimp building swf? In linux env,is there any good swf builder project ? There is a plug-in which might help: http://my.opera.com/area42/blog/flash-swf-export-for-gimp Thanks. 祝 万事如意 Hades 2010-06-01 signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Still GIMP @ LGM 2010
Am Donnerstag, 13. Mai 2010 schrub Michael Schumacher: On 13.05.2010 14:46, Joao S. O. Bueno wrote: So, When I emailed about this subject last week, I've been told everyone was already booked up and talks registered: it looks like teh talk registration is not quite complete, and we have to fill in the details for the LGM programme. No idea what the Saturday 100:00 talk is supposed to be, but for... Who is intending to talk? Peter? GSoC mentors? (including myself)? We shouldprovide then some details ASAP. ... there are two talk proposals in their wiki: http://create.freedesktop.org/wiki/A_first_outline_for_a_UI_for_a_fully_GEG Led_GIMP http://create.freedesktop.org/wiki/Writing_GIMP_scripts_and_plug-ins According to [0] those two are scheduled for thursday, yet there is still a half hour slot on saturday which just reads GIMP. HTH, Michael Tobias [0] http://ospublish.constantvzw.org/documents/LGM2010/LGM_programme_070510.pdf ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Testing on NULL an unitialized values
Am Freitag, 23. April 2010 schrub Oliver Bandel: Zitat von Tor Lillqvist t...@iki.fi: You are right, that in some seldom situations it might make sense to initialize values to other start values. But they should always be predictable. You didn't get the reasoning about letting the compiler, or valgrind, catch use of uninitialized variables, did you? I got it. But the compiler throws a warning and not an error on it. So, it's possible to get running code. So what? If the programmer decides to ignore warnings it's his deliberate choice. At least others have the chance to see those warnings and fix them/slap the one who caused them. Tobias ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Am Mittwoch, 8. Juli 2009 schrub yahvuu: [...] The user sends a JPEG to a colleague for review -- takes 2 hours to render. The image is OK, the user creates a TIFF for the print shop -- takes 2 hours again. I think in this case, the user would be better off if he had some control about when the rendering happens. What about caching the rendered image? As long as nothing is changed it can be reused. And when anything is altered in the image it has to be rerendered anyway. At least if it's not possible to cache intermediate results of the rendering or just rerender the changed parts. [...] Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Am Mittwoch, 8. Juli 2009 schrub Danko Dolch: [...] I've a screenshot for you - showing a layer tree and a node based view side by side. The node view is more pleasing to read if you try to understand whats going on. http://www.dolchonline.net/prj/gimp/combustion_scr01.jpg I personally love the node editor of blender and would like to see something like that in GIMP. The only problem with these node setups (like the one in your screen shot) is that they are only graphs but no trees. And AFAIK GEGL uses trees of nodes. Thus the cool things like several sources or forward edges (think of a bumpmap on a layer which uses the same layer as source) are not possible. [...] Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Export spec should be augmented to handle an important usecase
Am Mittwoch, 8. Juli 2009 schrub Omari Stephens: [...] Thus, it seems like both ways of handling this default ([1, 2, 3] priority as well as [3, 1, 2] priority) are viable and useful. This is why I suggest having a setting to switch between the behaviors. What about providing some kind of pre-populated drop down box in the export dialog with both alternatives, so you can quickly select one of those or just use the dialog the way it currently works. The box could be filled like this: last used directory associated directory last (say) 5 directories other than the two above If you select either one of the first two entries, that one becomes the default in subsequent exports. So if GIMP ships with last used directory and you export to associated directory, the next time you open the dialog it will default to associated directory. To make the whole thing unobtrusive it could be reduced to a little triangle next to the path at the top of the dialog which gives the list when clicked. Well, I guess that's the way drop down boxes work. :-) I hope this makes some kind of sense. Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Composition rendering time instance
Am Mittwoch, 8. Juli 2009 schrieb Martin Nordholts: On 07/08/2009 08:45 PM, Martin Nordholts wrote: On 07/08/2009 08:26 PM, Tobias Ellinghaus wrote: And AFAIK GEGL uses trees of nodes. This is wrong, GEGLs image processing structure is a directed acyclic graph, one output node can be connected to several input nodes. / Martin Make that the output pad of a node can be connected to input pads of any number of other nodes. / Martin Thank you for the clarification. I have to admit that I never programmed with GEGL and only knew what I read. Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] lgm talk, part 2...
Am Samstag, 20. Juni 2009 schrieb yahvuu: [...] Can you give an outline how the print color for that text will be specified? The RGB color isn't useful here and the text layer can't be accessed while the press projection is pulled over, IIUC. So each artwork layer will have a custom color separation setting resp. color mapping? From Peter's blog post: However there will be full flexibility to map the content of any layer directly to any plate. For instance that light blue text in our example: it can be directly mapped from its text layer to the light blue plate, bypassing the composite. I understand that you can use layers as plates. signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
