[Gimp-developer] Re: mailing list problems (was: Re: web site move)
[EMAIL PROTECTED] (2003-10-07 at 1131.45 +0200): Raphael, how can one subscribe by mail? I'm only aware of the mailman web interface. When it works and for example for gimp-developer list just send a mail to [EMAIL PROTECTED] with subject subscribe (replace list name and domain as necessary). It comes in the headers, but I guess most mailers hide them and do not offer a way to extract the info in a useful way (if you are not faking the user agent field try pressing h). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Redo shortcut
[EMAIL PROTECTED] (2003-10-01 at 0852.29 +0200): They did not have any problem about changing button order from the most used one (important button on left side, for LTR languages) to the easier to use one (imporant on right side), OTOH, so logic behind when to change and when not is fuzzy for me. The button order is used elsewhere (Mac). It should be used in conjunction with better dialogs (action verbs such as Save, Revert, Don't save rather than Yes, No, Cancel). And the logic behind it is simply that humans using LTR languages read dialogs from the top left to the bottom right, so the default action should be on the bottom right. Fine, I know about the order and the verbs, so I can not understand why there seems to be a blind reasoning about shortcuts: not every app requires the same functions nor the same usage pattern, so settings lots of shortcuts that only seem to match text editors and browser seems unreasonable. Gimp has collisions with other keys, you just changed one, but there are more, if you want to comply, your work is half done... and I will change back in my own config to make things nice for a Gimp user instead than for a HIG writer. HIG is not set in stone, and even then, it can be wrong. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Redo shortcut
[EMAIL PROTECTED] (2003-09-26 at 1933.11 +): I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. sounds like a good option, of course, it would confuse things if a user wants to apply SH+CT+Z to some other function(not sure why they'd want to, but it's possible). Grouped undo, or call undo history, ie. Hardcoding would be more problem than harm, btw. just out of interest, what on earth made the GNOME HIG people think that SH+CT+Z was a good combo for anything? and is there a good reason (HIG rules wise) for not allowing use of CT+R? it's not like there's a refresh of reload funciton in GIMP(although it could be handy, i still wouldn't want it attached to CT+R) Probably a mix of related to undo with used in other places reasonings. If you want a real answer, ask them. They did not have any problem about changing button order from the most used one (important button on left side, for LTR languages) to the easier to use one (imporant on right side), OTOH, so logic behind when to change and when not is fuzzy for me. And they proposed shortcuts seem to be text editor / browser oriented, while other kinds of apps seems to be ignored. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Mailing list archive out of date
[EMAIL PROTECTED] (2003-09-25 at 1354.47 +0200): a) out of date (last message from July 26) See Sven's post. Until the RAM issue is solved, try: http://marc.theaimsgroup.com/ http://news.gmane.org/ http://www.mail-archive.com/ b) not searchable (ht://dig error: Unable to read configuration file) Probably related to a, meanwhile try 'site:lists.xcf.berkeley.edu gimp term1 term2 ... termN' in Google. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Redo shortcut (was: Undo shortcut)
[EMAIL PROTECTED] (2003-09-25 at 2008.02 +0200): You have a point here. I think that what was chosen was the consistency of Shift as negation. I think that's probably a goal Relation, not just plain negation. So that is why using shift for grouping would be fine. we could work towards. It certainly makes a lot of logical sense. But then, so does having + to zoom in instead of =, and look how many bug reports that's got us :) I thought the logic behind = for zoom is that it is in the same key than + (in USA kbds, at least) but people wanted to avoid using Shift. I guess people's logic includes comfort. :] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Kudos to The GIMP Developers!
[EMAIL PROTECTED] (2003-09-24 at 1132.48 +0200): I'd just like to say: Well done. I managed to create a A1 poster at 600 dpi - a whopping 1.1 Gig of picture data (about 2x14000 pixels). Was there a real difference between 600 DPI and 300 DPI? I have a mag here that is done in 300-400 DPI, with good paper... and it looks nice, and it is something you look nearer than a wall poster. BTW: Is it possible that there is a 3 Gig limit on per-process memory? The machine has 6 GB, no ulimits and I got a could not allocate x bytes message when I gave 3 Gig tile cache to GIMP (it took about 500 Meg for other stuff, so I settled with 2.5 GB tile cache and still got a 3 Gig swap file plus 3 Gig memory usage). What kind of processor and OS was used? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Edit Alpha as Mask
[EMAIL PROTECTED] (2003-09-09 at 2128.34 +0200): On a related note: In 1.3 we introduced the possibility to initialize the mask from the layers alpha channel. This is still unfinished since 1.2 has that option too. What I think was added is inverse option and selection and grayscale-copy modes. it should probably transfer the alpha channel to the mask by making the layer all opaque. The open question here is if this should be the default behaviour. It might be confusing since the other ways of initializing the layer mask don't touch the layer's alpha channel. Any opinions on this, anyone? I would add option to clean alpha channel. Probably a name like Discard alpha channel contents afterwards should be fine (except that you will still have alpha channel :-/ ). Reset alpha channel afterwards maybe? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Portable XCF
[EMAIL PROTECTED] (2003-08-15 at 1357.35 +0200): There is unfortunately one thing that most of these filesystems have in common: they are designed to store their data in a partition that has a fixed size. If you create such a filesystem in a regular file, you have to pre-allocate the space that you will need for storing your data. Or use a tool to change the size, they exist, and in some cases they allow changing while online. Examples are ext2resize and growfs. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Portable XCF
[EMAIL PROTECTED] (2003-08-15 at 1541.28 +0200): BTW: Would it be possible to get a sparse file by zeroing the unused bits? Then it would be quite space efficient (at least with some file systems). Yes, try it with dd and cp (GNU version only?): dd if=/dev/zero of=/tmp/zero-test count=1000 cp --sparse=always /tmp/zero-test /tmp/zero-sparse ls -l /tmp/zero-test /tmp/zero-sparse du -cs /tmp/zero-test /tmp/zero-sparse If you get same byte size, 512000 bytes, but different block usage, 0 vs 503 here, your fs is doing sparse files. Another test I did here with a 8258506 bytes file, composed by catting a real data file of 7745389 bytes, then 512000 zero bytes and a final 1117 byte group of random data, gives an usage of 8098 blocks for the original and 7601 for the sparse copy. What I do not know is how many fs support it, and if they can do on the fly or a forced copy is needed, or if it is a good idea from performance point of view. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700): 7 able to support many color depth and spaces PNG certainly supports 1,2,6,7,9,10, and 11. Let us examine the other IIRC (did I read the spec wrongly maybe?) the upper limit is RGBA with 16 bit per channel, no arbitrary color spaces or data formats. You would have to use gray PNGs to assemble other color spaces... and never want 32 int or floats, or use a similar trick than with colour spaces, split data. I think PNG does not fit 7 without tricks. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Implementing dynamic brush features
[EMAIL PROTECTED] (2003-08-12 at 1721.12 +0100): Right now, the only non-tablet controled dynamic brush feature is color, with the gradient brush, Direction works too. Now, as I pointed out in Bugzilla, I've since found out that Photoshop 7 has some new dynamic features (see screenshots included in Bugzilla thread), including jitter (randomness I think), etc. http://www.arraich.com/ps6_tips_7brushes1.htm gives a better view of PS7 brushes. Long time ago there were mails about this (brush architecture, natural media), search and you can get things like http://www.levien.com/gimp/wetdream.html. - layer folders, useful if you work with a lot of layers. Paths folders would also be nice. Layer groups are being considered, check past mails. Maybe if you search with that name, or layer trees or something (some people seems to dream with folders, I guess, all is a folder ;] ). - always on top option for each tool box. This way you can maximise a picture you're working on, and just have the toolbox you access frequently on top. Hehe, the never ending story of wm vs apps (for this, i prefer wm, i do not buy the story of wm having to be invisible and then change the apps, each one its own way). I would add one thing: collections. Create a dir and drop brushes inside, and you get them ordered and clearly differenced from the rest (selector, tree...), not mixed. It could be done for patterns, gradients and palettes too. This is partially done, gimp lets you define dirs at will, but just that. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-08 at 1801.54 -0700): Portable XCF would use a chunk system similar to PNG, with two major differences. First, chunk type would be a string instead of a 32-bit value. Second, chunks can contain an arbitrary number of subchunks, which of course can contain subchunks themselves. PNG 32 bit names are char... or at least all them can be read. :] And I think the purpose of this was, among other ideas: easy to parse (always four chars) and makes sense with some rules about chars (caps vs normal). Even the magic of PNG had a reasoning (part binary to avoid confusion with text and capable of detecting non 8 bit transmision or bad byte order). IOW, why not make it similar, but just bigger (four char for name space and 12 more for function)? Arbitrary size strings does not seem a good idea to me. Another thing, alignment (and thus padding), is worth the problems it could cause? If the format has to be fast, maybe this should be taken into account, and not only about small sizes in memory (ie 32 bit), but maybe disks (ie blocks) or bigger sizes in memory (ie pages) too. Would the format be used just as storage, or would it be used as source / destination when memory is scarce. Remember that some apps are capable of working in areas instead of the full image, to improve global troughput. At the end of each chunk is a checksum, as well as a close-chunk marker. The purpose of the close-chunk marker is to help recover in case of corruption; if no corruption is detected, the close-chunk marker is ignored. One of the major advantages of this hybred technique is that if an implementation does not understand or is not interested in a particular chunk, it can seek to the next chunk without having to read or parse any of the data in-between. image data chunks should use png-style adaptive predictive compression. They should also use adam-7. I would avoid compression inside the format. Files can be compressed as a whole, and IIRC Adam7 is about interlacing, not compression, dunno why an editor should do progressive load. Load smaller res in case of problem? I would try to avoid that instead of try to fix it, with proper storage and transmission. Load with proxy images? Too rough, IMO, it is not a scaled down version. PNG compression is the one provided by zlib, and I can show you cases in which other compressors have done a better job with my XCF files (anybody can try bzip2), and if computers keep evolving the same way, the extra CPU load is better than the disk or network transfer. Letting other apps do it means those apps could be general, reducing work load. Or better, custom, but once the look of the data is well known and there is plenty of test cases (like FLAC but for XCF2, compression targeted at some kind of patterns). Realize too that this links to aligment things, if you know that a layer is always somewhere and requires X MB, you can overwrite and reread without problems. An example is worth a thousand words. Here is a simple RGB image with two layers (one with a parasite) and a comment. This is just a rough sketch of what it would look like: (labels in all capitial letters are for illustrative purposes and do not take up any space in the file.) FILE HEADER: portable xcf file Note what I said about PNG file header above. version major - 1 byte version minor - 1 byte CHUNK: chunk start, optional - 2 byte bitmask with some png-like flags xcf-comment total size of chunk and subchunks - 4 bytes size of chunk - 4 bytes For all these sizes... why not 64 and be avoid future problems? If someone likes it and uses it for really big things, segmentation is a negative point. Or maybe force a small max size for each chunk (forcing segmentation) which would give more CRCs. Options, options, options... This is the comment chunk end (flags) - 2 bytes xcf-comment 1 (subchunk depth) - 1 byte crc32 - 4bytes [...] I would add unique chunk ID to each, so then can make references. So of your list of items, 1 (lossless), 2 (portable), 3 (extensible), 4 (graphs), 7 (depth and spaces), 8 (gimp states) are a must. 5 (recoverable) will be nice, a lot, but if you want it to work, it sounds like some escaping and reserved flags will be needed (like line code in transmissions). I would forget 11 (compression), and put 10 (compact) as a secondary to 9 (fast load/save) and 6 (fast access). I would add tile based as 12. To some extent, it reminds me of the Blender format (with the add on that Blender files are 64 or 32 bit, little or big endian, and all the plataforms can load them fine... Adam will love it :] ). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-14 at 1440.34 -0400): The updates were originally done as technical notes, now they are incorporated into the main TIFF v7 spec which is part of the Photoshop SDK. They seem to be very friendly and open about it: From http://partners.adobe.com/asn/photoshop/index.jsp Q: Why is Adobe changing the policy on how the Photoshop SDK is distributed? A: The Photoshop SDK contains Adobe-owned intellectual property and for that reason, Adobe needs to capture and verify contact information for every party that desires to use this developer kit for business or personal use. By bundling TIFF into it they are doing a nice service to spread the format and make everyone have compatible readers and writers. At least it seems clear, it is about lawyers not about technology. GSR PS: Sorry, I forgot, quotation from a document Copyright © 2003 Adobe Systems Incorporated. All rights reserved. Cos copyright laws still allow quotation, no? :] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GimpCon RFC: Portable XCF
[EMAIL PROTECTED] (2003-08-09 at 1830.56 -0700): Is there a good reason not to use either PSD or TIFF as the native format? The only possible argument for either is that Adobe controls them both. However, I would state that TIFF has pretty much taken on a life of its own outside Adobe (via libtiff). You are right, PSD is not an option, it would mean always behind Adobe and never able to include new things. And even less now that the specs are harder to get, and some data I doubt will be ever public (is Gimp hardlight 100% the same than Photoshop for example?). About TIFF, every now and then someone appears with an horror story about TIFF files, so while better than PSD, I dunno if enough. :/ GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Interesting trick using new modes
Hi: I have been playing with the new grain extract and merge modes, and I think I found something interesting: The idea is to start with a dirty image (dust in camera or scanner) or old subject (scratches in a car, face wrinkles) and clean it up (but no miracles). Make a selection, remembering to use feather option (5-10 is fine), over the area to clean up. Posibibly setting some help guides now is a good idea for future steps. Blur IIR the contents. The value varies with each case, sometimes 10 pix is fine, sometimes it is better 15, some others 10pix two times. Despeckle or any other smoother filter can be used too. Move the selection boundary to the place to use as source. Duplicate the original two times (you have three layers), and set the top one to grain extract. Blur IIR the contents. As in the other smoothing step, use size and do as many times as personal taste suggests. It should go from a plain gray to a bumpy area inside the selection. Instead of blur iir, other blurs can be used, or a convolution matrix (fill all with 1 and set auto on, to get a box filter). Merge down (the reason for two copies and not just one), cut and paste as new layer. You can discard the layer that is gray with a hole. Set the pasted layer to mode grain merge, and move it over the area to fix (here the guides become helpful). Now it can be left as is, or merged down, cut and pasted as new layer over an original of the image (no the blurred at all, but the one with problems), using modes like lighter only (ie to hide a dark spot). The process can also be done in a different order, first extract the grain from somewhere, then place over an area to fix, blurring the damage just before merging the new noise. This way you know what you have to blur, but maybe you have repeat the process some times cos you did not extracted enough to cover all in one pass. This other path is recommened for cases in which textures must match nearly 100% or otherwise show bad discontinuities. Anybody that have used latest versions of Photoshop will see this is similar to healing brush and patch tool, just artesanal. I can not say it is the same, cos all I have is demo images from friends, playing some minutes in a machine from a mag office and lots of tutorials I got from Inet. My trick is not perfect cos sometimes the values you choose are not enough, or too much. Having some kind of formula for them would be better. There is also the problem of fixing areas that are really damaged (a hole in a photograph), for which the only solution I have found is to airbrush manually after the blur, with colours that hide the error. If the colour does not change much, shaperburst gradient from FG to transparent is a good solution too. In few words, hide the problem without caring if it looks fuzzy, just make colours match globally. I have been thinking about selective blur, but changing the condition (blur pixels that differ more than the setting, not less, as the current filter). Or another variation in which the bigger the variation, the bigger the blur (on a side note, selective blur could be like that, to avoid a sharp cut). Other option would be an interpolator that used the pixels in the border of the selection as source to build some kind of web over the problem. Should there be some kind of itereative colour bleeding filter, it could be tried too. For those interested, the best sources I found, both as inspiration and to check what PS does: http://mmmaybe.gimp.org/tutorials/Film_Grain/ http://www.3dgate.com/techniques/2001/010625/0625hajba.html http://www.digitalretouch.org/Photoshop7.html http://www.eyesondesign.net/pshop/healing/brush.htm http://www.adobe.com/products/photoshop/movie_nf2.html http://www.arraich.com/ref/aatool_healBrush6.htm http://www.arraich.com/ref/aatool_patch6.htm Conclusion just in case anybody got lost: modify the damaged area just keeping the global look, without caring how blured it gets, then extract the detail from a nice area using grain extract and apply over the smoothed area with grain merge. Like the film grain tutorial, but for image detail. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: A fresh pair of eyes.
[EMAIL PROTECTED] (2003-07-30 at 0246.34 -0700): Leopard and Brick patterns do not properly tile. http://bugzilla.gnome.org/show_bug.cgi?id=118796 GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Custom layer mode combination
[EMAIL PROTECTED] (2003-07-26 at 0201.25 -0300): My idea is that in the end, the custom layer formulas get recorded in a gimp directory, just like brushes and patterns. So, a set ofrather itneresting formulas would be shipped with the Gimp (or with the patch). That would provide alone could provide a lot of functionality. You should check math map plugin (the more I think, the more I believe it is your formula idea), btw. And then that is where my suggestion comes into effect, it would be just a run math map case of the generic solution. I don't get exactly what is your idea. I will probably, in the end make a gimp_custom_layer_set_mode (drawable, custom_layer_formula); where custom layer formula is a string exactly like the one taht would be typed on the interface. gimp_custom_layer_set_mode (drawable, function_to_call, params_for_it). If function to call is math map, one of the params will be a formula. Difference? It can be used to call levels, or blur or whatever. Usage examples: 1 - User paints a white to black gradient, for example radial, to make a tunnel effect. - Sets mode to run command. - Command selector appears, he chooses blur. - Result he gets is blur applied as by the white and black, like a selection. If some layer below changes, blur is recalculated. He will be able to move layers, repaint them, whatever, and blur will work on that. 2 - User paints another gradient, this time linear. - Sets run command for the layer mode. - Selects levels as command. - Plays with values, and hits ok. - Levels is applied to layers below, following the white and black as selection mask. - User realizes the levels are a bit wrong, chooses settings option, changes values to something else. - User sees a tree does not require the effect at all, so he paints with black in the effect layer the area occupied by the tree. He will be able to change his decission as needed. 3 - Same init steps. - Chooses math map. - Types formula. - Formula is applied. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Custom layer mode combination
[EMAIL PROTECTED] (2003-07-26 at 0944.01 +0100): (Well, contrast enhancement would be more like a sigmoid function -- what you describe here is basically gamma adjustment for a fixed gamma value.) And the best of all, there are tools to do all this, no need of typing formulas. Formulas are fine for experimenting or really corner cases, but dunno why a simple contrast has to be done with a formula (specially if that contrast operation can be run in more optimized form). I think that what GSR is really asking for in effect layers is stuff like 'blur layers', 'pixelize layers', etc, which basically is what everyone really wants. :) These require a decorrelation between the positions of pixels of different drawables though -- I made a working prototype of this during 1.1.x and it wasn't pretty. For single pix effects it should be easier, cos it would be like what is now, just call something with result of layers below as input, and merge back using white and black of the effect layer as modulator. I ask for what you say, but depending on the kind of commands allowed, there are one or other restrictions. Of course, for effective usage, due some commands working in drawables, you would have to pass a big block of pixels anyway. It all depends in where it is plugged and what functions are allowed. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Custom layer mode combination
[EMAIL PROTECTED] (2003-07-24 at 2031.28 -0300): The basic idea is that besides the normal addition darken only layer modes, to implement a custom mode. In it, the user gets to type a c-like expression of what to do with the pixel values in each channel when combining the layer. IMO you are forgeting a kind that users will like a lot more: call other GIMP functions, specially some like levels or curves (in this case, using the layer to control strengh in a channel by channel basis, or maybe using value (V in HSV) to get a single number and work like a selection mask, you should have to checke what makes sense). I guess users will find more use to those than playing around with formulas. I used the filter that lets you do math formulas to test ideas, but dunno how many people would like to use that daily. The formulas are nice, I am not saying you should drop that, but you should find a way to cover both if you can, formula and PDB. If you are going to get dirty, make it really worth it. Maybe even you can do the PDB way only, and provide a new call that does formulas (sounds simpler to me, more generic). Hey, maybe you can fit into it effect layers. ;] Well, probably not, they are not simple operations to layers below them. Depends if you want to apply filter to the result, which is just the call idea, or to the layer data only, which is what you need for auto bevel or auto drop shadow when working with text, ie. Last case would be more like having a layer hidden as input and a visible one as output, and recalculate output one only when input changes, not every time layers below change. In any way, all are interesting ideas to explore. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: tentative GIMP 2.0 release plans
[EMAIL PROTECTED] (2003-07-23 at 1320.11 -0400):
counsel. Claiming that offering my counsel is hurting GIMP's
reputation is a hamfisted way of telling me to shut up because you
don't like my opinion. Releasing 1.4 as 2.0 will do more to hurt
what does hamfisted mean?
Using dict(1):
1 definition found
From WordNet (r) 1.7 [wn]:
ham-fisted
adj : not skillful in physical movement especially with the hands;
a bumbling mechanic; a bungling performance;
ham-handed governmental interference; could scarcely
empty a scuttle of ashes, so handless was the poor
creature- Mary H. Vorse [syn: {bumbling}, {bungling},
{butterfingered}, {ham-handed}, {handless}, {heavy-handed},
{left-handed}]
GSR
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gradient dithering
[EMAIL PROTECTED] (2003-07-18 at 1014.57 -0300): I tried to aply adptive supersampling with maximum depth, to compare the effects with the ones from the patch: I had to kill out gimp after 20 minutes of 90% CPU use and no response. To see supersampling at work, try doing a diagonal gradient moving the mouse one pixel in each axis, and using a custom gradient like the german one, with repeat mode triangle wave. Use two layers, one with supersampling and the other without, then toggle visibility. You will see how the supersampled version is a bit smoother, giving a orange brown looking wavy image, instead of sharply changing pixels, more like straight lines than a gradient. Work in zoom mode to build the gradients, then compare zoomed and non zoomed. Quick conclusion: supersampling is for people working with quickly changing gradients, while dithering is for people working with slowly changing gradients. They are different things for different problems, and using the wrong one means wasting time. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: new-xcf (was:Re: GIMP GBR format spec)
[EMAIL PROTECTED] (2003-07-17 at 0959.32 +0200): Brainstorming, a dir named .xcf2 with the proposed contents inside? :] Would probably cause problems (ie. be cumbersome) copying, moving around on the web, etc. :-) We aren't quite at reiser4 yet. :-) Well, I think people can copy dirs like they copy files (the small nitpick is shell users, and those should know how to solve it). And pack them for web too. Only problem I see is users complaining about what was a single files now being a single dir, and oh, damn, I can look inside. In the end, both are project contaniers. No need of any future FS, NeXT did it long time ago, it is more about the upper level tools than the FS. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new-xcf (was:Re: GIMP GBR format spec)
[EMAIL PROTECTED] (2003-07-16 at 2223.29 +0200): If we would design our own extremely simple wrapper format there would be no need to work with the compatibility mess existing formats are (all of them :). If we say that access by other tools than gimp is not important Brainstorming, a dir named .xcf2 with the proposed contents inside? :] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Menubar in fullscreen mode [Re: the userinstaller]
[EMAIL PROTECTED] (2003-07-16 at 2244.11 +0200): Don't! Fullscreen mode is useful for more than that. It is nice when working on a large image, or a smaller image with high magnification, to get rid of superfluous stuff like the window decoration, but in that case the user may still want to use of the stuff that would otherwise be hidden. I find this a lot more useful as well, probably because that's what the fullscreen mode was for in Photoshop. A preview is nice as well, but fullscreen editing is quite a kick-ass feature. I always wondered why then the app has to do it, instead of the wm providing a trully full screen mode (no decors). I thought special full screens where due something different, like viewing video without any widget. :-/ GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: [CinePaint-dev] GIMP GBR format spec
[EMAIL PROTECTED] (2003-07-10 at 1140.21 -0400): It is very sad to see that Sven thinks that Robin Rowe is the only person to whom his ideas should be told. Pity the rest of the GIMP developers (current and future) who might like to comment on it. Use the list archives. Search engines let you restrict to servers. And IIRC basically it was about packing XML and some common image format like PNG into a some common archive format like TAR, so while not all soft will be able to open it, at least the user will be able to dissasamble it and load things by hand. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: development questions
[EMAIL PROTECTED] (2003-06-17 at 2122.23 +0200): So all we need is an even version number... All around GIMP, most notably with its toolkit GTK+, the 2.0 era has begun. Should we really go for 1.4? I don't think so and everyone me and Mitch talked to (for example on #gimp) agreed that the changes since 1.2 warrant the jump to 2.0. So unless anyone speaks up with good reasons against calling the next release GIMP 2.0, it will probably happen so. As already have been pointed out, lot of talk has been going about 2.0 being the great change, and something else being in the middle. So IMHO going for 2.0 directly would cause a bit of confusion, so I do not see any real adventage about starting a number race. To mark it as a lot have been done and it took a lot of time, there are some other numbers from 1.3 to 2.0 that are even too (ok, only three make sense, 1.4, 1.6 and 1.8). I find easier to explain that after 1.2 the next stable is not 1.4 but 1.6 (the bridge from old to new) or 1.8 (the path to 2.0 begins) than explaining that 2.0 is not the promised 2.0. The first half-explains itself, the later looks as a good way to waste time explaining to people. Already some time have been invested in the old naming plan, and there always be docs floating around talking about the mighty 2.0. It is just about communication, PR or whatever you want to name it, so the clearer, the better. Just my opinion, 1.6 or 1.8 sounds great, and there are no old news to rewrite. GSR PS: OK, maybe some places will have to s/1.4/1.whatever/g. PS2: Name it Hobble4? j/k Bad Sun joke. Sleep time, really. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: guash questions
[EMAIL PROTECTED] (2003-04-05 at 0349.40 -0500): the plan is that only gnome users can view more than one thumbnail at a time? Try gqview. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Q] Future of Gimp
[EMAIL PROTECTED] (2003-03-28 at 2120.56 -0600): On Fri, 2003-03-28 at 19:24, Daniel Carrera wrote: The main thing is that it can step through images. When you click on a different image it doesn't open a new window with the image, rather it replaces the image in the already-open window by the one you selected. In this way, you can step through a sequence of images. Ah yes. The flipbook thing. I remember Ray Feeney asking for such a thing when I interviewed him. Is not that GAP, Gimp Animation Plugin? The 1.2 version here has a menu named Video, and has commands like the ones you talk about, including one named VCR Navigation. Dunno current status of GAP for 1.3/1.4, I just barely remember some notes in changelo about cvs reorganization. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: caching considerations in gegl
[EMAIL PROTECTED] (2003-03-21 at 0124.53 +0100): Related to this, I would love to have a function that would enable me to create a layer mask from alpha channel or apply it to the existing mask. Is not that what I did in script-fu long time ago using 1.2? The only problem I had is that script-fu was unable to add the entry to the LC menu, but otherwise, it worked fine. The reason was that somebody wanted to edit the alpha cos a game used it as extra texture channel (reflections, iirc), and the best was to move the alpha to mask, work there, and then make it alpha again when saving as PNG. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: New version of the preview requirements
[EMAIL PROTECTED] (2003-03-19 at 1838.56 +0100): NON-REQUIREMENT 2: Split preview window with before and after version of the image. Other option is toggle view, like with layers (put a buffer with the original over the preview, swap buffers which would work better with alpha...). What would be better, toggle versions or two near versions? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Some feedback on Gimp 1.3.x
[EMAIL PROTECTED] (2003-03-18 at 1624.31 +): 1. Everyone loves a good splash screen, but now Gnome has startup-notification which kinda makes them superflous. Startup notification lets you know that your applications is starting but it is not as intrusive as a splash. I have edited my Gimp Launcher to add the line 'StartupNotify=true' and to change it to run 'gimp-1.3 -s'. To me this feels much snappier than before. And eventually when nautilus has integrated support for startup notification it would make sense to do the same for the gnome mime-type. Probably could be done in the gimp.desktop and other files that apply for that cases. 3. This one I'm stealing from Alan Horkan(who i've cced). It would make much more sense to me if the Image-Transform-Rotate X Degrees items where instead labeled Fip Horizontal, Rotate Left and Rotate Right The rotates should keep the degrees, rotate 90 degrees right and rotate 90 degrees left (or CW and CCW maybe, but that is criptic that way or long if expanded to words), that way you know it is a fixed rotation, not a free rotation, it is clear about what it does. But you have to check what flip horizontal is, the proper name it should get is rotate 180 degrees, it is not a horizontal flip, but double flip... which is even more complex than rotate 180 degrees to understand. It also makes the menu items look as a group. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: caching considerations in gegl
[EMAIL PROTECTED] (2003-03-11 at 1828.24 +0100): are you saying that we'd best remove the Anti-Erase feature from the current development version because it is broken by design and only works by accident (often but not reliably)? That's how I interpret your words but I want to be sure... Would just antierase users be happy with layers masks? This feature is ignored a lot, and I think it does the same, you hide and unhide areas as you want, keeping the colour info. If yes, get rid of antierase. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: caching considerations in gegl
[EMAIL PROTECTED] (2003-03-11 at 1233.14 -0800): Would just antierase users be happy with layers masks? This feature is ignored a lot, and I think it does the same, you hide and unhide areas as you want, keeping the colour info. If yes, get rid of antierase. Or, as I suggested in an earlier email, but I don't think was stated very clearly, implement anti-erase as a layer mask (whether or not the user can actually see the extra layer). Could make sense, after all quick mask is a temp channel and fast ops from / to selection. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Re: alpha vs. transparency / translucency
[EMAIL PROTECTED] (2002-12-20 at 1246.03 +0100): I agree for CMYK, DPI as well as RGB, but I don't think that RGBA is a commonly used term and it should thus not be used in the user interface and AFAIK it isn't. You should then check GIMP's Compose operation, you can compose three images as RGB, or four as RGBA. And when you inspect a PNG you can get ones that are RGB and some others that are RGBA (file(1) reports all this correctly), no coder voodoo, but plain user interests. For me and the people I know around, RGBA is a perfectly normal term, at the same level of the others. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: alpha vs. transparency / translucency
[EMAIL PROTECTED] (2002-12-18 at 1711.13 +0100): I agree with Alan and Raphaël (see the bug report) when it comes to the What/How statement. I can see how the term alpha may be unclear to new users, but I think it would be a pity to replace it all together, as this might cause users who are accustomed with the term to be confused. Another How: My image is RGB, how do I make it RGBA? :] Side effect, will be RGBA be named RGBT everywhere (in user visible interface)? Is not a bit silly to start renaming basic concepts of a field with something else (aka causing differences with reference docs that existed long time ago)? Just wondering. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Photoshop Plugin Support
[EMAIL PROTECTED] (2002-12-12 at 1550.09 -0500): First I would like to say Im not trying to start a flamewar here... but will the win32 Gimp target ever support Photoshop plugins, Seaching in Google you can see http://www.gimp.org/ (scroll down to GIMP 1.2.3 for Windows Released) or a more precise thing like http://lists.xcf.berkeley.edu/lists/gimp-developer/2001-December/006179.html You can try places like http://registry.gimp.org/ too, and you will find that user filter make filter factory plugins-kind work too. So seems at least some kind works, dunno if the factory ones are the same than the 8bf ones, or if there a lot of other kinds, but at least one does, maybe more. and will the *nix x86 Gimp target ever support Photoshop plugins via Wine? Dunno, if anybody wants and tries, maybe. Other option is to recode them from scratch (more portable, fixable, probably without money charge, etc). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Film Gimp and GIMP
[EMAIL PROTECTED] (2002-12-08 at 1225.19 -0500): I'm sorry, I must have missed it. Was the plan to have MDI as an option, or to make everything MDI only? I hope option. BTW, anybody know how to disable the film gimp menu in each window and get back to plain old gimp window? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Film Gimp and GIMP
[EMAIL PROTECTED] (2002-12-08 at 1133.54 -0800): Hi. Pardon a silly question, but if you want plain old gimp why not use plain old GIMP? Just curious. I hope option. BTW, anybody know how to disable the film gimp menu in each window and get back to plain old gimp window? Err, not clear enough? Another try: Make Film Gimp not show the menu in the top area of every window, only make it visible via MB3 click or by being dettached (doable with GTK+1.2, but new feature, so probably a no-no) or click arrow in top left corner (new feature, so probably another no-no). I guess the reply is no too, I have not found any hint about the top menu being removable if the user does not need it. If anybody know what I did not saw in the code, and that would make the always visible menu go away cleanly (currently nuked by removing some code), please tell me. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: layer groups (was: Film Gimp and GIMP)
[EMAIL PROTECTED] (2002-11-29 at 1937.59 +0100): Yes, this is a nice idea, although this is different from the feature that we were talking about. As a matter of fact, the idea that you present here has already been discussed on this mailing list. This is similar to what is done in a program called Khoros and its interface Cantata. If you do a It is like some composition engines work, for example NothingReal's Shake (now Apple's). In the world of 3D shaders, too, like ShaderMan or Maya's system. They just have systems capable of passing streams of data thru the nodes, requiring a timeline interface, so you can see that side of the problem too, the offsets from stream to stream. But if you only allow one image per input, you can work with the tree alone. I do not see why it can not be used for layers, after all, the only limit is what kind of bricks you have avaliable (current layer stack would be a lot of blend:normal, blend:disolve... bricks). Current way: Top layer (soflight) Middle layer (burn) Bottom layer (na) [No Applicable, there is nothing below] In tree: IN:TL \ IN:MLB:Softlight - OUT \ / B:Burn / IN:BL Now lets do groups: Layer A (softlight) | Group A,B Layer B (na)| (hardlight) Layer C (burn) | Group C,D Layer D (na) | (color) Layer E (na) And the equivalent: IN:LA \ B:Softlight / \ IN:LB \ \ IN:LC B:Hardlight - OUT \/ B:Burn / / \ / IN:LDB:Color / IN:LE I can go on, with layer effects, adjustements, channel compose and decompose, plugins and so on. Probably I could do bricks for paint tools, if so inclined (paint in multiple places at the same time, undo by disabling bricks...). Making big boxes would allow clearer grouping, simplify paint ops (all strockes become one box), or reducing the undo steps. :] Exposing part or all the tree would confuse people, that is true, but could make some other things nicer. Depends in the target. So are we talking about the engine or the interface or both? And after all this rant... is anybody checking GEGL docs? It would save me doing ascii art. ;] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Film Gimp and GIMP
[EMAIL PROTECTED] (2002-11-27 at 2219.52 -0500): From what I heard, Gimp originally declined a merge with the hollywood branch, which I see as a serious mistake. Gimp isnt photoshop, and it isnt any other program that people compare it to. Gimp is more than all of them. And thanks to FG, Gimp can become much more than it is now. But I dont see this happening unless people realize having multiple (uncompatible) programs like this is extremly bad. And from what I heard, the decision was the following path: - 1.3-1.4: code clean ups and port to gtk+2, add new features that drop in without any problem. Port to other plataforms officially. Make the GUI a bit more logical, reuse keycombos, make common previews. All this should make the code suitable for the future, based in objects and so on. It should be something like all previous versions, but nicer in the surface and in the engine, but not a complete rework. - 1.x-2.0: support colour spaces and bit depths, macro recording or anything that done for 1.4 would mean a lot of job. This would use GEGL, which should be ready at that moment, or at least the core part should. Gimp would become an user of the lib, an interface, maybe a full video processor tool, based in scripting (after all, videos are ordered lists of images, and basic video processing has already been done with perl). It could be seen as a complete rework, or maybe not, I hope all the GUI can be plugged on top of the new system. The merge is 2.0, or more probably, there is no merge per se, cos future code should do it from the lower levels. Thus merging with 1.0 code that would be deprecated anyway would mean more caos than real help. As anyone can guess, working GEGL can be done now, while the main clean up is done in the 1.3. The status of Film Gimp for me was some people use it, they got something solved, and as program it is a nice experiment, next time we will do it in core, not as patch. If some other people need or what something else / more, fine, but no other of the rest have to follow. issues. And a GEGL enabled Gimp is so far off, it will be years before I see it done. As a heavy user and supporter of Gimp, I deserve the occational feature request, and my request is that higher precision rendering is added asap. And coders deserve the right to have a live, I guess. That is a natural characteristic of free time projects: they evolve as the people's mood and time allows. :] If there is market, I suppose people could start a business about coding under contract and make everything go faster or port or wathever. If there is none, there is only accepting more strong limitations and go on as they allow. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Re: regex+
[EMAIL PROTECTED] (2002-11-27 at 1026.55 -0500): even the part where the search by name button gets pushed? In the plain DB browser you can write ^plug.*blur and hit that button. Last time I checked, ^plug.*blur was a regex, that meant has plug first (nothing before it), then something, then blur. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: regex+
[EMAIL PROTECTED] (2002-11-26 at 1206.59 -0800): What I have trouble imagining is the scenario where regex search in Gimp is necessary or useful. Few users even know how to phrase a regex search. Is this just feature-itis? Do I correctly surmise that regex could be removed without being missed? It will be missed by persons that use the DB as a tool, like script or filter writers, not users. If you want to call that featuritis or not useful... GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: + restoring mouse position after use corner navigation tool
[EMAIL PROTECTED] (2002-11-25 at 0259.10 +0100): I notice that mouse navigation tool, in the lower right corner of drawing window, could be improved in usability: before drag the viewing area is better to save the mouse position, restoring it after viewable area is moved and mouse released. ... I think it's better that after the use of ccorner view drag tool, the mouse stay in the used tool, don't you think so? Let me try to understand it: +-+ - Image window | | | | | | | | | | | | | | | | |#| - Navigation system icon +-+ User clicks in # and moves pointer to * and releases there: +-+ | | | | | | | | | | | | |+---+ || [*] - Small frame showing current view area || # | - Start position, was the icon +| | | | +---+ Currently the cursor stays in *, which in the example means a bit out of the image. And what I understand is that you want it to jump back to #. If so, are you sure jumping cursors are nice? Or that people having to raise the hand and reposition the mouse is nice? A 3D app I know does it, and is a serious problem cos your mouse sooner or later ends going out of the pad, but the cursor is not near a monitor edge at all. The cursor is far or near the place the hand thinks it is, but not exactly there. If there is a thing to change, it is to let the cursor go out of the preview if the user keeps dragging, thus make screen / mouse relation more tied, not less. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Random number seeding interface
[EMAIL PROTECTED] (2002-11-21 at 1459.36 +0100): The gimp_random_seed_new() function currently creates a spinbutton for the seed, and a togglebutton for whether a Time seed should be used. With the change over to g_rand* () the default seeding (which is from /dev/urandom by default, and time if that fails) is much better, so Time os probably no longer appropriate as a label. But that's superficial. Change the label to New Random Seed or something like that. It could be: Current Seed: _78928___^v |New Random Seed| I keep the spin button so people can just use a simple approach, start with one value (via the button or manual input) and test consecutive numbers, thus allowing going back to a nicer result you got four clicks ago, for example. The real change would be to do away with the toggle, replace the toggle button with a normal button, and set a random seed in the spin-box when the button is pressed. For this, I've been using Yep, nice for experiments. The ascii art above uses plain button, not toggle, as you recommend. the global PRNG (g_random_int) rather than setting up what would be a short-lived GRand * object, but again that would be a trivial change. After that the only thing left to do is intelligent default seeding. Do we seed with 0 as the default, and use the same seed as the last time if run with last vals is used for a plug-in? Should the gimp_random_seed_new() function set a random seed when called? Or do we seed with a random number to start? Currently the setting of an initial seed is entirely the plug-ins responsibility. I propose we leave it that way. The run with last vals should use, imho, the same seed value. This can, of course, be modified from plug-in to plug-in, but I think it's a sane behaviour. Only things I see as important is being able to reproduce the same results as many times as needed, thus last vals should be a run again, no changes at all. The other thing, the value for first run or new seeds, do whatever you want, seed with a random number from a highly random source or use time, I do not think anybody will have problems with not so random things in images (anybody so weird to do crypto with gimp?). If it looks random, it should be enough. Also, once the behaviour is decided, we should use the random seed widget across more plug-ins. Several plug-ins currently do their own thing in this respect, and there's no real need for it. Yes, you will make some people happy, specially about the rerun part. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: The Occasional Bug List
[EMAIL PROTECTED] (2002-11-06 at 2355.33 +0100): In libgphoto2, someone recently implemented reading the available memory from /proc/meminfo (if available) and act according to that. The code is at And for OSes that do not have that, like FreeBSD 4.6? It does not take into account details like disk speed or shared systems either. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: The Occasional Bug List
[EMAIL PROTECTED] (2002-11-06 at 1430.05 -0800): Regardless, it should only be used to create a suggestion -- the tile cache size should still be determined by the user. Yes, cos it still does not cover shared machines, nor machines with peaks in other tasks, nor disk tweaking, nor is the current situation at startup the normal situtation. And then you get complains, again. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Dreamworks, Shrek, and the need for 16 Bit
[EMAIL PROTECTED] (2002-11-01 at 0211.09 +0100): adjustments before the data is propagated down to 8bit? I was thinking of something like the levels tool. Do you think it would be possible to perform a reasonable first color adjustment only by looking at a histogram? In that case it should relatively easy to add that It could be, yes, but I do not think a pure math way is the right way, images are more white, no, less, tweak that. functionality to some of the file plug-ins. Since this wouldn't need any support from the GIMP core (albeit perhaps some helper functions in libgimp and libgimpwidgets) this could happen for GIMP-1.4. What do you think? I think it should be visual, a window with the image in 8 bit, and controls that decide how to get that 8 bit from the original 16 or 32. Basically black white points and a curve. I say visual, cos it could mean what one does in the lab, but digital (load some copies, adjust each one at will, and mask and mix all the copies to get the final image). PNG should be included in this family too, BTW. Any other format? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Dreamworks, Shrek, and the need for 16 Bit
[EMAIL PROTECTED] (2002-11-01 at 0136.10 +0100): Just FYI (I have no specific goal with this mail ;): I met some guy from Dreamworks (Shrek) at the LWE in Frankfurt, and he told me that their whole rendering infrastructure is 8 bit, including intermediate results (so the whole of Shrek was done at 8 bits, with a later dynamic adjustment of the results into the necessary range). I guess they work with linear data all the way. Just mainly cos I have been trying some tricks with a 3D app, and they went boom until I told the app to stop using gamma. And finally he told me that the need for 16 bit and floating point is there in many but not most cases, so one _can_ get along without it, at leats for rendered scenes. But not for real and render at the same time, and not for bad tuned render either. I am reading and getting info about this, seems linear and high range is best, if not, you have to choose how do you damage, but you hardly avoid it. Cineon is 10 bit and non linear, digital photo cameras start to give RAW dumps with more than 8 bit, some places use 32 bit float already (I would have say Dreamworks would have too... or at least 16 int)... Why all this rant? The more info, the better, I am trying to write about all this, so users know what GIMP can do, and how to solve the problems (or get the less noticeable error), and coders can get info about desired usage. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Dreamworks, Shrek, and the need for 16 Bit
[EMAIL PROTECTED] (2002-11-01 at 0938.03 -0800): Would error-diffusing dithering be an option people would like? Yes. Niklas should know a lot. :] He gave me a case in which it was really bad, and no need of import, it was possible to get it with current tools (gradient and proper colours). I managed to find a way to fix it, but very poor man one (spread filter, to fake dither). So with higher range formats it could happen too much. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Blurs patch, smaller values possible
Hi:
Lowering the level of blurs, so any positive value is valid.
Index: plug-ins/common/gauss_iir.c
===
RCS file: /cvs/gnome/gimp/plug-ins/common/gauss_iir.c,v
retrieving revision 1.42
diff -u -p -r1.42 gauss_iir.c
--- plug-ins/common/gauss_iir.c 6 Sep 2002 20:44:36 - 1.42
+++ plug-ins/common/gauss_iir.c 29 Oct 2002 17:29:17 -
@@ -126,7 +126,7 @@ query (void)
{ GIMP_PDB_INT32, run_mode, Interactive, non-interactive },
{ GIMP_PDB_IMAGE, image, Input image (unused) },
{ GIMP_PDB_DRAWABLE, drawable, Input drawable },
-{ GIMP_PDB_FLOAT, radius, Radius of gaussian blur (in pixels 1.0) },
+{ GIMP_PDB_FLOAT, radius, Radius of gaussian blur (in pixels 0.0) },
{ GIMP_PDB_INT32, horizontal, Blur in horizontal direction },
{ GIMP_PDB_INT32, vertical, Blur in vertical direction }
};
@@ -150,9 +150,8 @@ query (void)
independently invoked by specifying only one to
run. The IIR gaussian blurring works best for
large radius values and for images which are not
- computer-generated. Values for radius less than
- 1.0 are invalid as they will generate spurious
- results.,
+ computer-generated. Values for radius 0.0 are
+ invalid as they will generate spurious results.,
Spencer Kimball Peter Mattis,
Spencer Kimball Peter Mattis,
1995-1996,
@@ -172,9 +171,8 @@ query (void)
horizontal and the vertical direction. The IIR
gaussian blurring works best for large radius
values and for images which are not
- computer-generated. Values for radii less than
- 1.0 would generate spurious results. Therefore
- they are interpreted as 0.0, which means that the
+ computer-generated. Values for radii 0.0
+ would generate spurious results. Therefore
computation for this orientation is skipped.,
Spencer Kimball, Peter Mattis Sven Neumann,
Spencer Kimball, Peter Mattis Sven Neumann,
@@ -235,7 +233,7 @@ run (gchar *name,
bvals.horizontal = (param[4].data.d_int32) ? TRUE : FALSE;
bvals.vertical = (param[5].data.d_int32) ? TRUE : FALSE;
}
- if (status == GIMP_PDB_SUCCESS (bvals.radius 1.0))
+ if (status == GIMP_PDB_SUCCESS (bvals.radius = 0.0))
status = GIMP_PDB_CALLING_ERROR;
INIT_I18N();
break;
@@ -279,7 +277,7 @@ run (gchar *name,
b2vals.horizontal = param[3].data.d_float;
b2vals.vertical = param[4].data.d_float;
}
- if (status == GIMP_PDB_SUCCESS (b2vals.horizontal 1.0
b2vals.vertical 1.0))
+ if (status == GIMP_PDB_SUCCESS (b2vals.horizontal = 0.0
+b2vals.vertical = 0.0))
status = GIMP_PDB_CALLING_ERROR;
break;
@@ -409,8 +407,8 @@ gauss_iir_dialog (void)
gtk_widget_show (label);
spinbutton = gimp_spin_button_new (adj,
-bvals.radius, 1.0, GIMP_MAX_IMAGE_SIZE,
-1.0, 5.0, 0, 1, 2);
+bvals.radius, 0.0, GIMP_MAX_IMAGE_SIZE,
+0.0, 5.0, 0, 1, 2);
gtk_box_pack_start (GTK_BOX (hbox), spinbutton, TRUE, TRUE, 0);
gtk_widget_show (spinbutton);
@@ -470,7 +468,7 @@ gauss_iir2_dialog (gint32image_I
gimp_image_get_resolution (image_ID, xres, yres);
unit = gimp_image_get_unit (image_ID);
- size = gimp_coordinates_new (unit, %a, TRUE, FALSE, -1,
+ size = gimp_coordinates_new (unit, %a, TRUE, FALSE, 75,
GIMP_SIZE_ENTRY_UPDATE_SIZE,
b2vals.horizontal == b2vals.vertical,
@@ -583,7 +581,7 @@ gauss_iir (GimpDrawable *drawable,
gint *gi_tmp1, *gi_tmp2;
gdouble std_dev;
- if (horz 1.0 vert 1.0)
+ if (horz = 0.0 vert = 0.0)
return;
gimp_drawable_mask_bounds (drawable-drawable_id, x1, y1, x2, y2);
@@ -611,14 +609,14 @@ gauss_iir (GimpDrawable *drawable,
TRUE, TRUE);
progress = 0.0;
- max_progress = (horz 1.0 ) ? 0 : width * height * horz;
- max_progress += (vert 1.0 ) ? 0 : width * height * vert;
+ max_progress = (horz = 0.0 ) ? 0 : width * height * horz;
+ max_progress += (vert = 0.0 ) ? 0 : width * height * vert;
if (has_alpha)
multiply_alpha (src, height, bytes);
/* First the vertical pass */
- if (vert = 1.0)
+ if (vert 0.0)
{
vert = fabs (vert) + 1.0;
[Gimp-developer] Blur patches and comments
Hi:
I saw the mail about small blurs, remembered what I tried months ago
when talking on IRC (blur 1 vs 1.5) and decided to investigate /
test. Changed the filters to allow up to 0.1, and it works, the
description was wrong. Also checking more source found that
gaussian_blur_region allows anything above 0.0. Changed to allow
anything above 0.0, and let the user see if it makes sense.
Searching I also discovered the reason to do two passes instead of a
big single matrix, decomposition of matrices. If someone is interested
check: http://www.engin.umd.umich.edu/~jwvm/ece581/21_GBlur.pdf
Important: current widget does not allow float pixels (I think that
was the reason I gave up with the 1 vs 1.5 test), so to use this
feature one must change to some unit that allows and do some maths.
The easy case is a 72 DPI image, cos then 1 pix = 1 point (pt), and
this unit allows one decimal digit (so you can blur 0.5 or 2.2).
Reported in http://bugzilla.gnome.org/show_bug.cgi?id=91648 to see if
float pixels can be fixed before 1.4, it would be pretty nice.
I include the patches against CVS HEAD and a xcf.gz that demos 1.0 pt
vs 0.1 pt (aka pixels here). Use the color picker or info window,
there are differences in the area that looks like plain black and
white. See http://bugzilla.gnome.org/show_bug.cgi?id=91647
Index: plug-ins/common/gauss_iir.c
===
RCS file: /cvs/gnome/gimp/plug-ins/common/gauss_iir.c,v
retrieving revision 1.41
diff -u -p -r1.41 gauss_iir.c
--- plug-ins/common/gauss_iir.c 4 Aug 2002 15:27:04 - 1.41
+++ plug-ins/common/gauss_iir.c 25 Aug 2002 16:49:05 -
@@ -126,7 +126,7 @@ query (void)
{ GIMP_PDB_INT32, run_mode, Interactive, non-interactive },
{ GIMP_PDB_IMAGE, image, Input image (unused) },
{ GIMP_PDB_DRAWABLE, drawable, Input drawable },
-{ GIMP_PDB_FLOAT, radius, Radius of gaussian blur (in pixels 1.0) },
+{ GIMP_PDB_FLOAT, radius, Radius of gaussian blur (in pixels 0.0) },
{ GIMP_PDB_INT32, horizontal, Blur in horizontal direction },
{ GIMP_PDB_INT32, vertical, Blur in vertical direction }
};
@@ -150,9 +150,8 @@ query (void)
independently invoked by specifying only one to
run. The IIR gaussian blurring works best for
large radius values and for images which are not
- computer-generated. Values for radius less than
- 1.0 are invalid as they will generate spurious
- results.,
+ computer-generated. Values for radius 0.0 are
+ invalid as they will generate spurious results.,
Spencer Kimball Peter Mattis,
Spencer Kimball Peter Mattis,
1995-1996,
@@ -172,9 +171,8 @@ query (void)
horizontal and the vertical direction. The IIR
gaussian blurring works best for large radius
values and for images which are not
- computer-generated. Values for radii less than
- 1.0 would generate spurious results. Therefore
- they are interpreted as 0.0, which means that the
+ computer-generated. Values for radii 0.0
+ would generate spurious results. Therefore
computation for this orientation is skipped.,
Spencer Kimball, Peter Mattis Sven Neumann,
Spencer Kimball, Peter Mattis Sven Neumann,
@@ -235,7 +233,7 @@ run (gchar *name,
bvals.horizontal = (param[4].data.d_int32) ? TRUE : FALSE;
bvals.vertical = (param[5].data.d_int32) ? TRUE : FALSE;
}
- if (status == GIMP_PDB_SUCCESS (bvals.radius 1.0))
+ if (status == GIMP_PDB_SUCCESS (bvals.radius = 0.0))
status = GIMP_PDB_CALLING_ERROR;
INIT_I18N();
break;
@@ -279,7 +277,7 @@ run (gchar *name,
b2vals.horizontal = param[3].data.d_float;
b2vals.vertical = param[4].data.d_float;
}
- if (status == GIMP_PDB_SUCCESS (b2vals.horizontal 1.0
b2vals.vertical 1.0))
+ if (status == GIMP_PDB_SUCCESS (b2vals.horizontal = 0.0
+b2vals.vertical = 0.0))
status = GIMP_PDB_CALLING_ERROR;
break;
@@ -409,8 +407,8 @@ gauss_iir_dialog (void)
gtk_widget_show (label);
spinbutton = gimp_spin_button_new (adj,
-bvals.radius, 1.0, GIMP_MAX_IMAGE_SIZE,
-1.0, 5.0, 0, 1, 2);
+bvals.radius, 0.0, GIMP_MAX_IMAGE_SIZE,
+0.0, 5.0, 0, 1, 2);
gtk_box_pack_start (GTK_BOX (hbox),
[Gimp-developer] Re: GIMP assistance needed
[EMAIL PROTECTED] (2002-06-05 at 1616.39 -0700): In addition, I want to use this to print out a screenshot from the xwd command. Can I use gimp -b to do this from the command line. By the way the screenshot is referenced above as screen.xwd. I wonder why not convert the xwd to something that the print system understands (maybe png?), and just print that with lpr or lp or whatever command you have? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Paint Shop Pro GUI elements...
[EMAIL PROTECTED] (2002-05-06 at 2118.05 +0200): 1) For entering an angle, for example to specify a direction, they use a dedicated widget: kind of a full circle with a line pointing from the center to the selected direction, a bit like the Dial widget that comes with the GTK examples. I like this because for a lot of (non mathematically educated) people this is much more intuitive than entering a number between 0 and 360. It should include a numeric input somewhere too, maybe in the middle, like some mechanical indicators that have both, an analog clock and a digital clock (the one based in wheels with 0-9) all in one. So you can move the arrow or type numbers, and the other updates following as you change. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: What to do when zooming in? (bug #79384)
[EMAIL PROTECTED] (2002-04-24 at 1306.29 +0300): For the record, I would probably like zoom on pointer since then you can avoid the panning-after-zooming to find the place of the image. And Yes, it would be great, place where you want, hit key and zoom there. Saves the switch to zoom tool and back. that is how the zoom tool works too, doesnt it already zoom centered on where you click? I mean, I dont know since I never use it, being so used to the shortcuts. It does, where you click becomes the centre of the window. I think too that zoom should track mouse, or if mouse is out (sloppy focus, ie, or over widgets around image) zoom based in centre. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Notes from the Guad3c GIMP BOF session
[EMAIL PROTECTED] (2002-04-09 at 1542.31 +0200): - Four direction menus to reduce mouse movements necessary to reach a certain menu entry. I'm not sure if I understood this correctly. Someone should draw some Ascii art to illustrate this. I don't like the idea. I take he meant pie menus: +--+ | \ Cut/ | | \ / | |Paste -- Copy| | / \ | | /V \ | +---+__+---+ | \ Edit / | |File \ / Select| |-___\/___-| |Dialogs |--| View| |_---/\---_| |Tools / \ Image| | / Layers \ | +--+ Imagine the angles are more even in 8 entry one. When someone wants to select one of the 8 options, he moves the mouse in that direction, so function is performed, be it new submenu or action. This way users can do things like up, left, left+down, or in the ASCII art, up, right for copy. Problem is the limited entries you get if you want to keep decent angles, and thus it will go nuts when menu entries appear and disappear, like when adding plug-ins. In submenus, it can provide a way to go back or not, but in first case one dir is wasted and in the other a failure means a full restart. The proposition says 4 direction... which limits things a lot, with so many functions as GIMP has it would work only as user configurable helper (thus containing only the user most used items), not as main system, IMHO. - Replace canvas XOR drawing by something nicer. We looked at some commercial apps and found they all get problems if the background color matches the color used to preview lines/beziers etc. GIMP has this problem with gray backgrounds. Should be discussed further. Find two formulas that never report the same result for some colours, and make then appear like ants mode, thus in at least one time interval you see something different. XOR could be one, the other could be plain paint over. OTOH, I guess it could allow undo for fast updates on screen. XOR with different keys (0xF0 and 0x0F, ie)? Text Tool - - Should allow multi-line text with configurable line spacing. - Should allow to modify character-spacing for selected parts of text. Total control of kerning, tracking and leading? Yipe! :] - Clicking somewhere into the image and starting to type should create a new text layer the size of the text's bounding box. Current GDynText behaviour, which is nice. Clicking and dragging should create a new text layer the size of the dragged rectangle. So click and drag overrides font size? Sounds like a nice way to put things in fixed places (with guides snap would be perfect). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: amp photoshop curves
[EMAIL PROTECTED] (2002-04-04 at 1143.34 +0100): If the amp format is simple enough, why don't we just make it the default format for Gimp curves too? The problem I see is that it means not under GIMP people control (basicaly about improving, I doubt the format would change). For example, when moving to 16 bits or other modes, I do not see PS AMP 256 entries LUT or GIMP 17 entry curves as the way to go. It sounds absurd to work in such high mode and then limit other things to brute approximations. Or think about supporting extra channels, AMP only supports one or three channels. Leaving room for improvement should be taken into account. I think it is better to write an external converter (uum, it already exists :] ) than support two formats or discard current (is there any gimp2amp?) and then try to workaround problems in the future. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp development
[EMAIL PROTECTED] (2002-03-26 at 0908.26 -0600): image to Gimp and ask him what my image contains: colours, text, fonts etc... . No, Gimp cannot currently do that. It is not the purpose of Gimp to analyse images but to create them. IMHO, GIMP should absolutely permit batch processing of images - and It does, not the best but good for some things, search a bit. :] if you wanted to write a plugin to count colours or do OCR image analysis to read text - then that should be possible. (Dunno how feasible it is to find text and fonts...but that's not the point). As is, GIMP does not include recognition filters. And I do not think she asked about coding it, but doing now, so no is the right global reply for it, no matter if batch capable or not. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Typo in patch
Hi:
The patch I send recently has a typo that I discovered the other day
when trying to make my own theme (well, recover from the death the old
theme, so it can become Classic-1.2 or something like that). Ed Hunter
confirmed it today and I updated my version and patched imagerc again.
---8---
Index: themes/Default/imagerc
===
RCS file: /cvs/gnome/gimp/themes/Default/imagerc,v
retrieving revision 1.4
diff -u -p -r1.4 imagerc
--- themes/Default/imagerc 2002/03/07 14:42:45 1.4
+++ themes/Default/imagerc 2002/03/10 16:51:51
@@ -97,8 +97,8 @@ style gimp-icons
}
stock[gimp-selection-subtract] =
{
- { images/stock-button-selection-substract.png, *, *, gtk-button },
- { images/stock-button-selection-substract.png, *, *, * }
+ { images/stock-button-selection-subtract.png, *, *, gtk-button },
+ { images/stock-button-selection-subtract.png, *, *, * }
}
stock[gimp-selection-intersect] =
{
---8---
For those who do not know how themes work, the fix is not vital, cos
Default theme is hardcoded, imagerc file is an example to create new
themes, things compile and work fine with the typo or without (until
you try to use as base for another theme).
Sorry for the stupid typo.
GSR
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimp HEAD does not compile - intltool
[EMAIL PROTECTED] (2002-03-11 at 0109.42 +0100): error while opening tips/gimp-tips.xml.in.h for reading: No such file or directory cd tips then ./update.sh and fixed, or at least that is what I had to do. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Patch to include some more images in imagerc
Hi:
Some image were missing.
---8---
Index: themes/Default/imagerc
===
RCS file: /cvs/gnome/gimp/themes/Default/imagerc,v
retrieving revision 1.2
diff -u -p -r1.2 imagerc
--- themes/Default/imagerc 2002/01/13 20:59:56 1.2
+++ themes/Default/imagerc 2002/03/06 20:38:15
@@ -88,6 +88,29 @@ style gimp-icons
{ images/stock-button-visible.png, *, *, *}
}
+ # Selection tool option window buttons
+ #
+ stock[gimp-selection-replace] =
+{
+ { images/stock-button-selection-replace.png, *, *, gtk-button },
+ { images/stock-button-selection-replace.png, *, *, * }
+}
+ stock[gimp-selection-add] =
+{
+ { images/stock-button-selection-add.png, *, *, gtk-button },
+ { images/stock-button-selection-add.png, *, *, * }
+}
+ stock[gimp-selection-subtract] =
+{
+ { images/stock-button-selection-substract.png, *, *, gtk-button },
+ { images/stock-button-selection-substract.png, *, *, * }
+}
+ stock[gimp-selection-intersect] =
+{
+ { images/stock-button-selection-intersect.png, *, *, gtk-button },
+ { images/stock-button-selection-intersect.png, *, *, * }
+}
+
# Tool icons
#
stock[gimp-tool-airbrush] =
---8---
GSR
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Improved patch for imagerc
Hi:
There seem to be some more than four missing, so with some weird
grepping I think I managed to get all the images pointed in
libgimpwidgets/gimpstock.h. Here is the revised patch:
---8---
Index: themes/Default/imagerc
===
RCS file: /cvs/gnome/gimp/themes/Default/imagerc,v
retrieving revision 1.2
diff -u -p -r1.2 imagerc
--- themes/Default/imagerc 2002/01/13 20:59:56 1.2
+++ themes/Default/imagerc 2002/03/06 21:14:05
@@ -88,6 +88,77 @@ style gimp-icons
{ images/stock-button-visible.png, *, *, *}
}
+ # Selection tool options window
+ #
+ stock[gimp-selection-replace] =
+{
+ { images/stock-button-selection-replace.png, *, *, gtk-button },
+ { images/stock-button-selection-replace.png, *, *, * }
+}
+ stock[gimp-selection-add] =
+{
+ { images/stock-button-selection-add.png, *, *, gtk-button },
+ { images/stock-button-selection-add.png, *, *, * }
+}
+ stock[gimp-selection-subtract] =
+{
+ { images/stock-button-selection-substract.png, *, *, gtk-button },
+ { images/stock-button-selection-substract.png, *, *, * }
+}
+ stock[gimp-selection-intersect] =
+{
+ { images/stock-button-selection-intersect.png, *, *, gtk-button },
+ { images/stock-button-selection-intersect.png, *, *, * }
+}
+
+ # Image window icons
+ #
+ stock[gimp-navigation] =
+ {
+ { images/stock-menu-navigation.png, *, *, gtk-menu },
+ { images/stock-menu-navigation.png, *, *, * }
+}
+ stock[gimp-qmask-off] =
+ {
+ { images/stock-menu-qmask-off.png, *, *, gtk-menu },
+ { images/stock-menu-qmask-off.png, *, *, * }
+}
+ stock[gimp-qmask-on] =
+ {
+ { images/stock-menu-qmask-on.png, *, *, gtk-menu },
+ { images/stock-menu-qmask-on.png, *, *, * }
+}
+
+ # X Y linked or not
+ #
+ stock[gimp-hchain] =
+ {
+ { images/stock-button-hchain.png, *, *, gtk-button },
+ { images/stock-button-hchain.png, *, *, * }
+}
+ stock[gimp-hchain-broken] =
+ {
+ { images/stock-button-hchain-broken.png, *, *, gtk-button },
+ { images/stock-button-hchain-broken.png, *, *, * }
+}
+ stock[gimp-vchain] =
+ {
+ { images/stock-button-vchain.png, *, *, gtk-button },
+ { images/stock-button-vchain.png, *, *, * }
+}
+ stock[gimp-vchain-broken] =
+ {
+ { images/stock-button-vchain-broken.png, *, *, gtk-button },
+ { images/stock-button-vchain-broken.png, *, *, * }
+}
+
+ # Wilber *_`@@'
+ #
+ stock[gimp-wilber-eek] =
+{
+ { images/stock-wilber-eek.png, *, *, * }
+}
+
# Tool icons
#
stock[gimp-tool-airbrush] =
---8---
I wrote the size based in the name, and left the eek one as all sizes.
GSR
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Menus, keybinding et al, first draft
[EMAIL PROTECTED] (2002-02-17 at 1230.12 +0100): Also we will need a howto on the web site about making the different window managers play nice with gimp. That would be useful though. What would also be useful is to make _all_ keybindings in GIMP configurable (like SHIFT, CTRL, ALT etc.). So I would be able to assign Meta1 to GIMP-ALT and Meta2 to WindowManager-ALT. You can configure all the menu shortcuts, it is a GTK+ feature, and a good one. Non configurable things are Alt for menus and things that do not appear in menus. That would need some kind of config method, maybe being Alt one impossible. Supposing wm does not hard code, you can get the thing you want. About the doc, yes, and not only for GIMP, but for other features, so people really use window manager capabilities and have info to choose wm. bit OT Another problem I see is the terms workspace and viewport. Some wm have none, some one, some both... and of course names change, I used Sawfish terms, so do not panic if your wm has other things. This is related to GIMP cos you can use one level of stickiness for the GIMP utility windows and leave images non sticky, thus changing fast from image to image. Add any other tricks you have developed. Good usage of things avaliable means less work. /bit OT As far as I know, there are no wide-spread shortcuts involving two modifier keys. It boils down to something like CTRL-Q: Quit, CTRL-W: Close window, CTRL-N: New - very basic stuff. Shift+Control is proposed as related or negative, and not only in the draft. GNOME has a list, Mac too, even Windows, they cover the basics, they have the comment about Shift. OTOH, some like Mac and Windows do not have wm problems, via the quick way (remove the problem instead of fix it, and say you do not need it to people that ask for things like fast and fully keyboard controlable wm). CTRL-ALT and similar bindings are seldomly used by applications and often used by window managers. X and OS too (beware of Backspace, kills X ;] ). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Menus, keybinding et al, first draft
[EMAIL PROTECTED] (2002-02-17 at 1219.46 +0100): As any looked into how all this will work with different window managers? What window managers grab what keys and can the window The reply is easy: pain. Been there done that. When you fix one thing, someone appears with new keys to kick you down pretty hard. ;] managers easily be configured to use alt if gimp isn't using it? Well, if you ask me and you (well, distros) are into fixing all the madness, there is a way, called Hyper or Super keys. Most keyboards now have 105 keys, so instead of having Meta and Alt, you can share that in one key (anybody found a program that wants both?) and make the free keys be Hyper (ta da, window manager key!). So not 100% fixed, but at least fixed for many cases, now the problem is to fix the rare cases, not the common one. It is important to check this since we will otherwise end up with lots of whiny users who can't figure out why thiings aren't happening like expected. We already have them (check the tip of the day list, and search for references to Alt). What is more, Branko found another one the other day (Control key, used by xterms, collides with E... ouch, and Sawfish had some versions with similar wrong defaults, see Carol's PNGs). Also we will need a howto on the web site about making the different window managers play nice with gimp. OK, I can contribute the Hyper thing, and the application into Sawfish (FVWM2 as soon as I get it back, archived the config again). Carol PNGs only make W become Super, but she needs how to get Super or Hyper working, dunno about Debian defaults, but RH does not have Hyper (I prefer Hyper cos Super shorts to S, like Shift... personal mania). Also, are there other apps that use shortcuts like we do that might be using a different set of shift-alt-ctrl keys? Just thinking it would be The doc goes for Shift / Control / Shift+Control and letters for a reason. Then Shift+Alt if needed more. Of course, use Hyper (at wm level) and you never have problems. I would leave Control+Alt for window things (window manager, like maximize, or X, like jump to another VT), so Hyperless people have something at least. I leave out Shift+Alt+Control cos it starts to get complicated, and Alt is reserved for accelerators that have _ (menus, dialogs and so on), so avoided too. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: UI suggestions
[EMAIL PROTECTED] (2002-02-16 at 1432.56 +0100): This dialog should also be optional, so that power users will still keep that power feeling. WinZip does this very nicely (unfortunately, I do not know a Linux tool that gives you the choice between wizard and power access). I'm against adding optional GUI stuff. IMO it will only confuse people, bloats the code and doesn't really solve the problem. If there is a problem with the current user interface it should be solved properly instead of being worked around. Well, people could also learn to drag and drop, launch from filemanager, launch with parameters from command line... general solutions that work always (vs gimp having a new dialog). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Menus, keybinding et al, first draft
[EMAIL PROTECTED] (2002-02-16 at 0939.22 +0100): Something I forget: note that by this definition, the Text Tool isn't a tool either, at least when using Dynamic Text, since the placement of the text depends only on the option in the dialog box. I think Text should be a tool, and, unless otherwise specified in the dialog box, the text should appear in the image at the location that was clicked by the user. This also prevents the problem of having to scroll around to find the text you just made when you are zoomed in. If the text were at the point where you clicked (which is ofcourse within the viewport) you could just finetune it and go on. Text tool is going to be changed, it will be a mix of current gimp freetype (quality) and gdyntext (separate layer, parasite). It should add the layer where the user clicked. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Menus, keybinding et al, first draft
[EMAIL PROTECTED] (2002-02-16 at 0659.48 +0100):
Zoom In + [Yes, changed, a bit more logical, no?]
Zoom Out-
If you have an US keyboard you'll notice that while the minus - is
immediatly accessible, the plus + is obtained by pressing Shift +
=. I think that +/= it's a faster keybinding for an
US-keyboard layout user.
And in non US, maybe the contrary. ;]
Guess why I hate of symbols, and try to find people with other
keyboards. Letters are the few thing everyone has (and with Dvorak,
Azerty and others, some keycombos can be weird).
What about of a bit nationalized keyboard layout, they should be
selected through the Options menu and NOT by using the locale, just
because it's possbile that someone uses a keyboard layout different
from the specified locale (just think a programmer often needing
{} ).
Could be an option. Of course, GTK+ must first solve the problems with
keybindings, cos I used some combos that do not work (input as blank
as does nothing), and others are intercepted wrongly (I have to use
Shift+0 for =, and that fails, and if I try to reset it, I get
Shift+=, which is like saying Shift+Shift+0).
GSR
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Menus, keybinding et al, first draft
[EMAIL PROTECTED] (2002-02-16 at 0929.47 +0100): Well done! I still have some comments though, see below. Thanks, that is why I post. :] I think we need to think very hard about Plug-ins, Filters, Script-Fu, and Tools. Another I forget: no more differences about script-fu, pygimp, perl-fu, C or whatever. If it is under Filter, it is a filter and must behave like any other. I'd like to define a Tool as something that changes the image depending on the coordinates sent by the pointer device. This means that Flip and Transform (which always work on the whole image or the whole selection) aren't tools at all. Things like the Image-Color-* functions, which seem to be implemented as Tools in 1.2, aren't tools either. Interesting definition. Note the implementation is one thing, and you are talking about menu, in this case they are in the right place (well, the one I posted, cos they are Layer level, not Image). I'm not quite sure what to do with the remaining functions. I don't think the user should be able to see the difference between Plug-ins, Script-Fu scripts, and Perl scripts in the interface. That No, they should not. We need a definition for tool, filter and so on. Your tool seems fine, at least to begin with. means that the Xtns-Script-Fu menu entry should go. Throwing them Perl script register under Filter or other places, like C based functions, and that is the way to go with script-fus too. all in one big menu under Filters may be overkill though. I'm open to suggestions for splitting this up (in a way that is based on the function of the plugins) into smaller more manageable parts. By kind, like is now, we have to create the review kind list (starting with current classification, to avoid starting from scratch). Thirdly, we now have three different Transform options. I know that Unix gives you enough rope to shoot yourself in the foot, but with this you can't see the trees for the forest. Why not just a single transform tool, and an option there to do the whole image or just the current layer? Or better even, allow the selection of multiple layers in the layers dialog box, so that you can have finer-grained control over what you are changing and what not. Transform menu entries do some basics and in some cases pretty hardcoded (rotate 90*n degrees), and transform tool is more like the tool definition you use, it uses the mouse, and is more free. Lastly, I think we should look at the names of the functions in relation to their locations in the menu. In GIMP 1.2, there is a function Image-Filters-Color-Map to Gradient..., which is rather confusing. Thing is, there's also an Image-Filters-Map submenu, and I always end up looking for Map to Gradient in the Map submenu. Function-wise I think this is a logical way to organise things, but linguistically it's confusing. I left the Filters one for next step, cos it is tricky, have to add all the scripts, move things around, etc. I wanted to have the basic structure and the other submenus, not the Filter area. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Menus, keybinding et al, first draft
Hi: This is the doc I have now. Any comments? Suggestions? Fixes? Global ideas for this: - Use common keys first (letters, numbers, Shift, Control) - Use Alt but not alone, to allow _Foo with Alt+F, and not the first thing to use - Try to make rules, by mnemonics (C-q) or by pure tradition (C-z) - Use Shift for related (negative, special) cases if possible, and only for unrelated if not usage found - Remove rarely used keys to avoid getting crowded but as this is a pro tool, it is not the first thing I am going to do (those who are cut happy should check the number of combos in other pro tools and how many times they are used once the user is working and not playing) - Leave Fkeys for user (have fun with yellow notes ;] ) Global functions and keys: Hide and unhide extras Tab Show image menu Space [New, cool for tablets or in general] [ to allow menu invocation from ] [ keyboard, anytime ] Menus: Toolbox [Suggestion: make it a single root item like image menu?] [ That would be a bit rare, but would make all fit fine ] [ Could be named Menu [] and give hint for [] ] [ Yes, I am mad and I will get flamed by GUI purists but] [ think about the space we get, and the standarization, ] [ all menus would be vertical and [] is taught ] File New... Ctrl+N Open... Ctrl+O Open Recent 1. filename [No keybindings, they change a lot, also see zooms] 2. filename ... n. filename --- Aquire Screen Shot... Scan... --- Preferences --- Dialogs Layer... --- QuitCtrl+Q Xtns Module Browser... DB Browser... Plug-in Details... Unit Editor... Script-Fu Web Browser Tools Default Colors D Swap Colors X --- Color PickerO Magnify Shift+M Measure Paint Bucket Fill Shift+B Blend L Pencil Shift+P Paintbrush P Eraser Shift+E AirbrushA Clone C ConvolveV Ink K Dodge or Burn Shift+D Smudge Shift+S Selection Rectangle R Ellipse E FreeF Fuzzy Z Bezier B Intelligent ScissorsI TextT Transform MoveM Crop and Resize Shift+C Transform Shift+T FlipShift+F Dialogs Layer, Channels and Paths Shift+Alt+L Tool Options... --- Brushes... Shift+Alt+B Patterns... Shift+Alt+P Gradients...Shift+Alt+G Palettes... Shift+Alt+P --- Input Devices... Device Status... --- Document Index... Error Console... Undo History... Help Help... F1 Context Help... Shift+F1 Tip of the Day... About... Image [Suggestion: tooltip Image menu when over []] File New... Ctrl+N Open... Ctrl+O Revert... --- SaveCtrl+S Save As... Shift+Ctrl+S Save Copy As... --- Print...Ctrl+P Mail Image... --- Close Ctrl+W QuitCtrl+Q View Zoom In + [Yes, changed, a bit more logical, no?] Zoom Out- Zoom Presets [One linear vs one with mod. Still dunno which one ] [ One is more compact and provides some hints based ] [ in powers of 2] [ The second is more linear, not so easy to remember] [ or center hand, but linear] [ I vote for first, you always have key 1 located ] [ 5 would be a more complex, IMHO ] [ Some people want to numbers for brushes, so lets ] [ talk about it, I think brushes need more things ] 16:15 1
[Gimp-developer] Re: Menus, keybinding et al, first draft
[EMAIL PROTECTED] (2002-02-16 at 0006.34 +0100): This is the doc I have now. Any comments? Suggestions? Fixes? I got some questions and suggestions on IRC, so to avoid forgetting and repetitions, I self reply: - Image/Layer is the same menu the will be used for MB3 in Layers dialog. That way you have same layout and same bindings, no more wrong duplication, but perfect one. Sorry for forgetting to write it, I thought but did not type, that was one of the basic ideas behind cleaning menu system. - I have to add Channel menu, and using the same principle that with Layer, share the menu, and so share keybindings and layout. But also share bindings with layers, otherwise it gets mad. Check next to see what and how. - I guess then we need a toggle key to move from Layer to Channel and back. Shift-Tab, ie, and check what does Ctrl-Tab for reasoning (did you know that one? I want it for channels too ;] ). And add new layer keybinding will be the same than add new channel, just change to channels to change the behaviour, like you do now with mouse. I just hope it does not get impossible due coding limitations (resync of changed bindings, ie). Quick example: Shift+Ctrl+N creates new layer or new channel depending if you are working in layers or channels. Branko and Simon talked about indicators for active layer or channel, I think the change key will suit nice with them. Branko should post something soon. Of course we can avoid key reuse, but then if we want bindings for things, we have to duplicate a lot (new, duplicate, delete, move, select, both for layer and channel, instead of one set of commands and operate in current context). Sven talked about drawables but we can not expect to push it to user level, as he pointed. So channels and layers must be separate, but I do not think too much if we do not want it to go out of control with keys. I think users can grasp the idea of channel or layer, and reuse keys, indicators would make even easier. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Script-fu opendir function
[EMAIL PROTECTED] (2002-02-14 at 1120.28 +0100): Is opendir function implemented in Gimp 1.2.x ? If not, how can I do to parse a directory in script-fu ? Tried http://people.delphi.com/gjc/siod.html? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: unsharpen mask radius 1.0
[EMAIL PROTECTED] (2002-01-15 at 1512.52 +0100): I've been following some instructions oriented toward photoshop that talk of unsharpen mask settings including a radius of 0.3 or 0.8. I notice that Gimp's implementation has a minimum radius of one. I'm quite sure that it's just the UI which is limiting the value. In my travels around the code (!= I understand it) I saw some cases in which the functions accept float values, but some widgets do not like it. The one with unit selection in guassian blurs is the example I remember, and Sven told me it could be fixed for 1.3. One note about Photoshop: sometimes the values used in it are not the same than in GIMP, if you want the same results. IIRC the histograms are different. Would you try if it works correct with smaller values and report back so we can remove the silly limitation (if it's silly :) ? In the case of gaussian blurs, half pixels show differences. I did the test, I just had to change the units to one that allowed to input float values (pt vs px), and I got blur (zoom and color picker recommended if the case is not a good one and your eyes are not good either). nonsense=maybe It does not work with 0.9 and 1.0, but there is difference with 1.5 and 2.0. Dunno why it takes values less than 1 as 0. Did people checked it or just think it will be wrong? If you think in analogic mode or using pixel subsampling, it makes sense, IMO... that or I remember wrongly how the function is, the radius is the distance from the center of the bell (integral is 99/2% of total) or from one side to the other (so you have 99% inside)? -+|+|+|+- | means limit, + center of pixel |-| Radius? _ \ ' - _ _ |-| Radius? (diameter is more correct, no?) _ (at least from an UI POV) / \ __-' '-__ As you can see, if the top case is the right one, it would be made sense to support up to a bit over .5 (check 0.5) cos you still get a bit of info from the neighbor pixels. I understand that pixels have a radius of .5 pix to the side (sqrt of .5 to the corner, but the function does vertical and horizontal passes only). What it wrong? The terms used (in UI, code or by me)? Test in code? My brain? Explanations highly appreciated (and why blur is done in two perpendicular passes instead of a matrix, too :] ). /nonsense GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: BW digital, compose w/weighted color channels?
[EMAIL PROTECTED] (2001-12-18 at 1900.27 +0100): What if we add an opacity slider to the channels dialog similar to the one on the layers dialog? The opacity would affect normal selection channels (where it can now be set in the dialog that pops up when you double-click the channel's name). For the red, green, blue and alpha channels it would affect the projection thus allowing for easy interactive color-correction of the whole image. Brute colour correction, I would say. If you want to do fine colour correction, you end using curves tool, I guess (it just needs a button to apply to all layers, not only current layer as is now). With the menu rewrite, it will look fine (layer curves or image curves). OTOH once applied curves change info, so your idea would have some positive points... I guess it goes back to the topic of display filters, like the gamma one that was removed. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Current work
[EMAIL PROTECTED] (2001-12-04 at 2141.20 +0100): We need a Object-structure to be able to store and handle vector imagedata. I am not sure about how far we should go in this way, or where is the point to leave this stuff to other programs like sketch or sodipodi. If there is a lib for all that, it would be nice. If not, I do not think it will hurt to have better vectors in GIMP. The path tool (or vector tool) just asks for the control points and anchors, can render them on the image window and draw lines according to information from the GimpVector object. It could also provide information about restrictions in the freedom of the control points. So the vector tool does not have to know too much about the specifics of the vector data itself. It could even work on Text. Being able to modify text as vector can be nice. I use an app that allows you that, so when you want to deform text, you can use the tools for curves, like in other curves you create. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Common dir of plug-ins (patch about OK button)
OK, I have been reviewing the common dir, I think I rearranged all them so they have the OK in the new place. I also have read some code (that is the only reason for so boring task) and next will try to finish the others as well as improve thos that look pretty bad (like five buttons, of which three just change things, but are not reset | cancel | ok, not anything in that line). The gz was done with cvs diff -u in the common dir, and does not include the patchs I already sent to sven mitch. GSR gimp-plug-ins-common.patch.gz Description: OK button patch
[Gimp-developer] Re: Bug week like thing for GIMP?
[EMAIL PROTECTED] (2001-11-25 at 1551.38 +0100): Are there any other such ideas that have been floating around? Intro (or task oriented) tutorials maybe, instead of the typical web page you create an publish, waiting feedback. IOW do a live class so people can ask questions, and then the final web page covers problems users had when trying the planed steps. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimptool.c
[EMAIL PROTECTED] (2001-11-12 at 0235.28 +0100): I also like the code Tor checked in that replaces user_install.bat and I think we should use it for UNIX user installations also, but the same argument applies here: doing so in the stable branch bears the risk of breaking working code. It breaks, I think, cos it does not pay care about CC env var, it uses gcc always. And I know some people who will not be happy with that. :-/ GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: (Fwd) Re: convert amp files
[EMAIL PROTECTED] (2001-11-11 at 1641.25 +0100): There's good documentation of both PhotoShop formats and of Catmull Rom splines to be found on the net. If you find any that works, tell us, I guess a poll of links would be nice. I tried to search the AMP thing, got pointed to Adobe SDK in its FTP, and it seems that the files are not there. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP Tip of the Day messages
[EMAIL PROTECTED] (2001-10-06 at 1125.23 -0400): Didn't Clippy get fired? Maybe next version should have Wilberpy as helper. The concept image was nice: I see you want to draw a straight line. /me runs GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Film grain: Grey addition and subtraction modes
[EMAIL PROTECTED] (2001-09-26 at 2241.03 -0400): Many thanks to all the regulars on #gimp who answered my questions, gave me advice, and bugged me to write this stuff up. ;] Step (3): To merge the pattern back into the image, create a channel of solid noise, mask it as needed, and add it to the underlying channel. Again, the addition is tricky. Should s/channel/layer/g be applied there? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Thin lines using pencil
[EMAIL PROTECTED] (2001-08-29 at 1719.07 +0200): If you make a new line tool, which would be awesome by itself, it would also eliminate the repetitive stupid questions on gimp-user and #gimp about how do i draw a straight line AARGH! Xachbot is your friend, it has the URL of the tutorial. Also, would that line tool work in airbrush (or any other different to just lines) mode? If not, you still need the tutorial. And do not worry, you will get a replacement stupid question for which no tutorial has been written rather quickly. ;] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: xwd screen shot problems
[EMAIL PROTECTED] (2001-08-28 at 0142.52 +0100): This is perfectly normal. If you don't like it it's possible to disable the support for this feature on some hardware, but IMHO you don't know what you're missing :) In general I was just been cautious about what I say cos I have not looked enough specs / sources to be sure. I have looked a bit now, and discovered that what you say seems to be true, what I heard too, but they are not the same thing (I heard about Overlay/ColorKey 24+8 and you are talking about VideoKey option, or so says the manpage). The CPU usage is very low compared to previous driver and the quality is nice, I saw it as soon as I played a video with the new XFree and gtv. I did not paid all the money to have a crappy card or a nice one but not use it. ;] Any idea about how to capture images? Is there an env var or something that exchanges the speed for the visibility? Screenshots with blue areas are not very nice (I am using mplayer now, BTW). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: xwd screen shot problems
[EMAIL PROTECTED] (2001-08-27 at 0021.59 -0700): xwd: Warning. Error in XWD-color-structure (flag) xwd: EOF encountered on reading xwd: load_image (xwd): XWD-file /root/.gimp/tmp/gimp_temp.277523.xwd has format 2, depth 24 and bits per pixel 24. Currently this is not supported. This message was generated attempting to capture glxgears using Gimp (xwd). I used my script to capture it, it worked, but gears lost speed for 10 secs (first message always gives low speed, then it goes up, when I used the script, I lost like 30% for two messages, then back to full speed, each message cover 5 secs). What do you suppose it means? Reading problems, as Sven says. My script uses xwdtopnm as first step of conversion. Capturing motion video windows is really flakey with xwd. Usually it fails, but sometimes it doesn't. It seems to be influenced by what other windows are being displayed. I tried video, and I got a blue image... fun. I run with depth 24 and fbbpp 32, so I guess this has something to do about it, cos when moving the video window, I get blue areas (I am still discovering the nice and bad things of the new driver for my card). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: xwd screen shot problems
[EMAIL PROTECTED] (2001-08-25 at 2218.12 -0700): Hi. Unless I'm mistaken xwd isn't capable of capturing 24-bit visuals. It seems almost useless on modern hardware. Is this an issue that has been discussed here before? OOh, well, then my computer does magic. ;] Attempting to capture graphics-intense windows with xwd on x86-based XFree86 3.x or 4.x just gives a misleading error message, extra confusing because other simpler windows on the same desktop will capture without trouble. xwd worked here in 3.x and is working with 4.0.3. Can you define intense? Tried with browsers with a anim playing and a OpenGL app to test. Do you mean video playback windows? The ImageMagic import utility works consistently and writes directly to png. Is there any thought to switching Gimp screen capture to use import? IIRC, ImageMagick writes to what you put as name, so if you say foo.jpg, it writes a jpeg, and if you do not specify, you get a miff. And import, at least when I tried with 3.x, had a bug that raised windows even if you do not wanted. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: errors in the TGA plugin
[EMAIL PROTECTED] (2001-08-01 at 1641.57 +0200): prohibited by the standard. Just a small note, that appears in many lists about graphics: TGA does not seem one of those hyperclear standards like PNG. From now and then you see people asking about rare TGAs, save / load problems and other complains. If it is clear, I guess that problems will never appear. About reading: be permissive with what you receive and cautious with what you send is a Internet good rule. So please do not talk about removing the feature in the read process. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: another Perl-Server question
[EMAIL PROTECTED] (2001-07-25 at 1140.55 +0300): but I don't see any way of detaching the gimp process from the controlling terminal so that I can background it without terminating the gimp. Any suggestions, or is this a feature which may be added at a later date? ;) With control terminal you mean X server or a text console? For text console you can use screen, I guess. Try VNC: http://www.uk.research.att.com/vnc/ The traditional way is to use Xvfb, it comes with X (maybe in a accessory package, it varies with distros). It is a dumb X server for testing or background usage. VNC also comes with some distros, but it usage is more for roaming or serving X to machines that do not have X (aka MS Windows when you do not want to pay more software). In both cases, gimp -i saves the creation of interface for faster load and probably faster work due not doing renderings to monitor (you still need some kind of X so the libs can work). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Quesitons about support for Djvu format and Color selection
[EMAIL PROTECTED] (2001-07-16 at 1210.16 -0700): So the only way it would be usable in the gimp is something like a plugin to read and export to that format? Not as part of the main program? Loaders / savers in main program are plugins. The thing is that nobody has stepped forward and said he will do it. You have to find one to do it, and to maintain it. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Quesitons about support for Djvu format and Color selection
[EMAIL PROTECTED] (2001-07-15 at 2036.12 +0200): idea for a gimp color selection dialog. They we call it Palette dialog and it has been around for years. Well, this palette was a bit bigger and the name appeared inside the colour (faster, I guess). But nothing too radical, I guess people ignore the dialogs too much. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Quesitons about support for Djvu format and Color selection
[EMAIL PROTECTED] (2001-07-16 at 0850.45 +1000): A quick skim of the webpage seems to indicate the know what the GPL is. Then they will link to FSF, not Open Source. If you say GPL and Open Source, and a FSF guy heards it, like Stallman, you will get some mails explaining the differences. The only thing I can see that's interesting is what happens if they use the GPL'ed code in their commercial products? Given the nature of the GPL, surely that means they'd have to distribute source of the other products too? As owners of their code, they can use their code with other licenses. They can not put others code into that apps, so I guess patches will only be accepted if copyrights are transfered. Yes, it is possible to do that, to distribute under multiple licenses and to transfer rights. They certainly would have to if they ever accept contributions from the outside world under the GPL, I believe. No, they can say we accept, and it will stay in the GPL codec, but you must transfer the rights so we can use that code as non GPL inside other apps. It is similar with FSF, they want the rights if you want your app to be official FSF, but this time they want it to sue when somebody does not follow the rules (GPL). If you do not want it to be official, so they will not go to courts if problems arise, you can keep the rights. I think they have docs about all this in http://www.gnu.org/. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: UI remarks
[EMAIL PROTECTED] (2001-06-08 at 0200.27 +0200): Also, it is bad that you have to know that ~/.gimp exists and that you may need to hand-tweak the stuff in there. Everything should be configurable through a nice graphical interface; if you need to install third-party plug-ins or scripts or gradients then the GIMP should have an install plug-in command. This command can simply copy a binary into your ~/.gimp/plug-ins. No, some people want to be able to hand-tweak stuff using an editor. That's why we have user-readable config files. Apart from that everything important is indeed configurable through the prefs. But I have to admit that it's probably a bit too much information for a user installation dialog. But I like the way we managed to integrate all the info from the 1.0 installation dialog into this page on the new one ;-) I hope he means user does not need to know it, not files should not be hand editable. One thing is about making life easier for some people, and the other making it painful for other people. BTW, last time I checked there was gimptool. OK, maybe it needs a GUI for some people. Also, in most cases you do not need, it is one of those FAQ's for [choose a name from the common list of 2D/3D apps]: I got a plugin, now what? Now move it to the plugins folder and restart the app. Which, to some point, is a good reason to make the user know that ~/.gimp-V/ exists. It is also the container for scripts, and people want to pass files to friends... gimptool --send-brush-to email ? ;] Message idea: The GIMP stores config info in ~/.gimp-V/ and has been created / as been created based in your previous config ~/.gimp-V-1/ (show the appropiate version). It is also the place to store user plugins, scripts, brushes. Feel free to browse the dir and fill it with the extras you create / download. (Expandind the abbrevs ;] ) I have not yet seen one X-Server giving a close to correct value here unless you manually tell it the correct value on start-up. Last time I tried XF4 (3.3.6 now, it was just a test) the logs shown the monitor size fine. It works if your card and monitor can talk DDC. Maybe some daily users of XF4 could report what is going now. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: GUI comment from an NT user
[EMAIL PROTECTED] (2001-06-07 at 1734.35 +0200): Gimp, under Linux at least, saves layout. And you can do tricks, like copying the sessionrc to a safe place, and reinstall it before each launch. No need for tricks. Simply exit Gimp with your favorite session layout and disable Save Window Positions on Exit on the next run. Gimp will then always start with your favorite session layout. Ah, but doing tricks is much more fun than clicking a couple of buttons :) It it can also be used as a way to move config arround, ie if you have multiple resolutions (if size Foo, copy sessionrc.foo, if Bar, copy sessionrc.bar) or configs (today I want crowded desktop). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: UI Stuff
[EMAIL PROTECTED] (2001-06-06 at 1424.04 +0200): increase their market share they need to fix the UI, and make it Market share? Heeey, guys, how much money are you earning with Gimp? rates. I do earn money with the GIMP, yes. If it weren't for the I am speaking about the people that make the app, not the people that use the app, they are different. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: UI remarks
[EMAIL PROTECTED] (2001-06-06 at 1724.41 +0200): The GPL wants you to put a visible notification about the license into your program. This notice should be seen whenever you start Gimp. We only show it on user installation and one day RMS will come and get us for this lazyness. Well, I doubt that RMS would blame us for that. The notice must not be displayed every time the program is started, as long as it can be accessed easily using some command-line option or dialog box that is commonly used to display some information about the program (such as --help, --version or some About dialog for graphical programs such as the Gimp). Have anybody, in last months, tried any commercial app? Seessh, I have to click Accept even to get some damn docs. Or to get new drivers for a card that I own, and I still have to see the damn license again and again. The point is to show, IMHO, that Gimp is not public domain, it has a license like anyone, and it is serious about that. consequences. Or maybe because they wanted to try the program quickly and they pressed OK or Next on all installation windows, assuming that the defaults are fine and that only the experts need to change them. Most people just hit Next like a mad monkey. In some cases, they are right, cos the config tool does nothing. In others, it allows interesting things, like in Gimp case (cache, monitor resolution). BTW, maybe a guided tutorial would be fine, that way people learn to change things once they have the app installed. With the click Next mania, I guess that could be the default way, no entry dialog, only the tuts. Here is a suggestion. I doubt that I will implement it, but maybe David can do it since he wants to improve the installation process. Keep the current dialog as it is (telling the user to adjust the value as needed), but try to change the default value of 32M on the systems in which the available memory is easy to guess. This means that the users of other systems will still have to change the tile cache size from the default of 32M, but at least those who are using one of the common configurations (e.g., Linux 2.2 or 2.4 on a single-user machine) will get a more sensible value by default. There is not sensible size. Start some apps, and Gimp suffer, close those apps, and Gimp is not using all RAM. Users could try to guess how much RAM free they have when they work with Gimp. IIRC in MacOS users have to decide how RAM was shared (old MacOS, not last version). Calc default, OK, but make sure the user knows it could be really wrong. /tmp. I think that the only way to check that automatically is to run df and parse its output. This is not very elegant, but I cannot think of a better solution. In some cases, IIRC, /tmp is RAM. Here is how it could be done: run df $TMPDIR, df /tmp and df $HOME. Ignore the result if df fails or if the second line of the output does not start with /dev/ (which indicates that the directory is mounted from another host). If there is anything left, then use the directory that has the largest value in the available column. If there is nothing left, then use the old default value. The user will still be able to edit it anyway. df? It will vary if the user have installed today, or has been using the machine a lot and is just about to do a clean up. Also, size is not the only important thing, speed too (think two disks, not local and remote). But oooh, well, seeing how default installs work, and how others do partitions, I understand why some people get doggy slow systems (do you placed swap where?), and other snappy ones. Somebody said disk layout was an art, and it is true, at least until computer become really smart. The dialog should point that non obvious details: use a place where you can get more free space if you want, and in a disk that is fast. And where to change them. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: JPEG comment in existing files
[EMAIL PROTECTED] (2001-06-03 at 1602.02 +0200): I think this is built in the save routines, I don't think there is a separate comment attached to an image. It sounds like a useful feature to me though. this is not currently editable (AFAIK, unless you call save as a comment-editor), but it will be in a future version. If what people want is to change the comment without changing the image data, they should use rdjpgcom to read the comment and wrjpgcom to overwrite / append. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: JPEG comment in existing files
[EMAIL PROTECTED] (2001-06-03 at 1856.59 +0200):
I would like to be able to change comments per image I save, no
Create a file with the names of those images you want to change, one
per line, and name it Files (full path if you can). In another file
named Copyright, put the new text. Then use this bash command:
IFS=
for i in $(cat Files) ; do wrjpcom -replace -cfile Copyright ${i} ; done
What it does? Create a group of items with the lines of Files, and for
each item, call the comment writer with options replace text and load
text from file Copyright. The IFS thing is to avoid problems with
names that have spaces.
You could use other file names (created by hand or from a DB), like
Files_clientname and Copyright_clientname and you will have all
sorted. Yeah, a script could also do the trick of updating all your
disk, if you give it the list of clients and you always keep up to
date your DB (image foo is for client bar).
The concept applies to other shells or scripts, like Perl, you do not
need to do complex programs. And you can always collect the ones you
get, like the one above. :]
GSR
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: New Gimp-web mail list
[EMAIL PROTECTED] (2001-05-31 at 1352.45 -0400): The Gimp-web list has been created to continue the discussion of the updating of the gimp website. Subscribe here: You forgot [EMAIL PROTECTED] with subject help or subscribe (aka MailMan normal procedure). ;] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Scheme style, draft 1
Hi: I read the elisp rules as inspiration, and here is what I think we should do with Scheme scripts, comments / doubts with []: - use prefixes for your own functions, so you avoid problems. [does Gimp's Scheme provide encapsulation? if not, this is a must] - indent in Emacs style, with spaces instead of tabs. [maybe we should provide pointers to indent apps that do it, not everybody has Emacs. Also instructions for common editor, like vim] - put ( ) in the same line that text, not alone in other lines. - cut lines that are longer than 80. [70?] - write documentation strings, so the PDB can show something. And something useful, not no info yet. - for comments use ; (right), ;; (code level), ;;; (left) and (left, separate areas of file). - first line of files ;;; filename --- one line description. - one blank line, and third ;; Copyright (C) the owner (the script owner(s), not the Gimp owner). - license, with the blank lines as separation. - another blank line, and headers like ;; header: content. See http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_657.html for the list. [put here the list] - end files with ;;; filename ends here - do not add Copyright to the copyright field in the register function, it look weird to see Copyright: Copyright (C) owner. - the path, if the script launchs a dialog, must end with ..., if automatic action, do not put [people complain about UI, no? so start applying this basic concept] - data format as -mm-dd. Fill with x if unknown (2001-05-xx), but only if applicable (Copyright is , not -xx-xx). - add _ before strings, so can they be translated. - provide nice ranges for variables, all that will work, not more (it could cause errors), not less (just cos the effect looks weird too big, does not mean it can not be used as base for other thing). - provide sane defaults, at least for normal uses. Take the common cases and apply the script. If a script to remove red eyes look poor when you try to remove the red of a car, it is fine, but not if the input are faces, and all them fail. - use foo string for logos. [which string? logo name? the gimp?] - use constant names when you call plugins, not numbers, if they exist (DISCARD is better than 1). Look script-fu-constants.c for them. [include a list?] Make a pointer to elisp doc, so we give credit about inspiration. Explain why, so everyone knows it (the draft is too short). Put it in CVS and Gimp site (aka this can be one of the test docs for the new system). I am not a Scheme guru at all, so I guess I have put something stupid or miss a basic item. I would like to see comments from Scheme people, or lisp users in general. Fixes? Changes? Who decides? GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Script-fu and Re: The GIMP Webpage
[EMAIL PROTECTED] (2001-05-23 at 1023.57 -0500): Marketers will tell you that you have to change the site Sorry, could not resist, joke ahead: A shepher is in the plains, just watching his sheeps, and an all terrain vehicle appears from nowhere. A guy with a nice suit and a laptop jumps to ground, and asks the shepherd: - If I tell you how many sheeps do you have, would you give me one? - Uummm, OK. The suit guy starts to do some computing, requests extra data via mobile phone, process satellite photos and after an hour of activity says: - You have 1457. - Yes! Choose a sheep. The guy gets one, and the shepher asks with a funny face: - If I tell you what is your job, do you give me it back? - Ooh, why not. - You are a consultor. - How do you know? - You appeared even if I have not called you, you told me a thing I already know... and you have choosen my dog. ;] It can be applied to other professions, consulting was just the one at hand, but I guess it shows clearly the modern trend of doing things just cos someone says it, not cos they are needed. We can give some kicks to the site design, sure, but I would preffer to give some kicks to the content, so it is useful and updated. What is more, a plain looking site, while not appealing at first visit, would be visited again if people see it is useful (looks plain, but it has all the info I was searching, oooh! no more time wasted browsing!). I guess that is the reason people like Google: it works and does not look overworked. BTW, is there a Script-fu coding style? I have an idea in mind: clean scripts a bit, and publish some rules, in the same way Gimp C code has some rules (published?). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Script-fu
[EMAIL PROTECTED] (2001-05-23 at 2056.32 +0200): As far as I know, there is no Script-Fu coding style described anywhere. I tried to find some references when I modified many of the logo scripts in order to add support for Alpha to Logo, but I did not find anything. I wanted to clean up all scripts, but I did not do it because I did not know what style to follow. I would like to suggest: - use spaces, not tabs. - for comments use (left, heading, optional), ;;; (left), ;; (code level) and ; (right). - use headers in comments, so you give some info, not just the code. - files start with ;;; filename.scm --- description. - files end with ;;; filename.scm ends here. - put ) at the end of something, not in a new line. - and ( just before the text, not in the line above. - if the script launchs a dialog, write ... in the path. Mainly, Emacs Lisp rules. We can read them fully and use what we think that applies, writing a new doc for Gimp site (and start patching as time allows). TOC http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_toc.html Tips and Conventions http://www.gnu.org/manual/elisp-manual-20-2.5/html_node/elisp_652.html I have not checked all the Gimp scripts, but I know some follow the rules quite good, and others not at all (not even just what you think about lisp languajes). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: plug-in distribution choices
[EMAIL PROTECTED] (2001-05-20 at 1535.17 +0200): Am I to understand that there is no recorded instance of this discussion? Well, let's start now, then, so that next time we can point to the mailing list archives. You can request IRC / mail logs, maybe someone has them. First of all a definition of the problem area: what are considered plug-ins? Everything that goes into the directory 'plug-ins'? Anything else? Some modules too, like the colour selectors, could be considered plug-ins. When talking about scripts earliers, I noticed that there is no clear way of distinguishing which scripts belong in the core distribution and which don't. I suggest we tackle this problem (first?). Scripts depend on the interpreter, so that would mean the interpreter should be in core app, which is not bad, but also not necessary. Scripts are plugins for plugins. My suggestion is that the following plug-ins belong to the core distribution: - those that perform a task that the GIMP should have provided for itself or will provide for in the future; I doubt Gimp will provide more, the idea is to have a small system where you plug things as needed, even GUI will be separate (and that for me is plugable). This general idea can be read in somewhere, this list archive probably. - those that will help other plug-in authors better understand how to write plug-ins; That should be in a devel package. Why do a user need a plugin that does nothing or near nothing? It is like the test script fu, lots of controls and you get a plain ball. Or like devel packages, users do not need to waste space with .h files that will never use. - those that will make the GIMP look good when compared to other raster image editors; and Then you include all those working, so you are sure you are giving the maximum you can. - those that perform a task the best in its field. I doubt there are repeated plugins, people do not code to have two, they patch instead. And if they did not know, they try to join the work, or deprecate the bad one. Can such a distinction be made? Yes, but you forgot: - plugins that are maintained. I think your point of view is what users want / need and the real thing is what volunteer coders can do. And from that comes the idea of reducing the number of core plugins, moving the rest to 1..N packages. That or somebody finds a way to keep all plugins updated (pay a coder with comunity money like with a Perl one? create a company to support it?). :] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: plug-in distribution choices
[EMAIL PROTECTED] (2001-05-20 at 1636.07 +0200): It turns out we need a plug-in manager. What functionality should such a beast have? Here's a list of things that came to my mind: [...] It should be able to download and install precompiled binary packages or download sources, compile and install them. A solution for the binary packages would be to use the binary packaging system provided by the distribution. Since there are a bunch of different distrbutions out there, this might be tricky. I would make a basic plugin handler so users can remove / add them to menus, if installed, and let the real task of getting the plugin to user / pkg system / whatever. If you use a pkg system, it can do it for you better than anything, if not, there is a make install target or a gimptool mode for that. I do not think becoming another Red Carpet is worth the time (which in place seems to be APT with GUI). Also it would mean secutiry audit for UID 0 routines. We all know how fun would be messages like I got new plugins, but my other account does not have them or it gets them, and then hangs while CPU and disk go 100% (compilation) or it seems hung, but after some minutes it says error, missing lib, and I have that lib (but not lib-devel). If people with knowledge can have problems, imagine the rest. So I would split the system more at source level, so you get x groups and build install them (or make distro pkgs then install) following an order, like you can do with GNOME, ie. ATM I already use that (with x=2): gimp and gimp-data-extras. GSR PS: OTOH it would be nice if Gimp could read post mail news. And IRC too. /me ducks runs. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
