[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] Ooops, error (Re: Redo shortcut)
[EMAIL PROTECTED] (2003-09-26 at 2226.34 +0200): > Grouped undo, or call undo history, ie. Hardcoding would be more > problem than harm, btw. Argh! "...problems than help, btw." 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: 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: 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: 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] More undo things (Re: Redo shortcut (was: Undo shortcut))
[EMAIL PROTECTED] (2003-09-22 at 1959.36 +0200): > So, if it's possible to have two different keybindings for the same command > I'd like very much to have both. You can always redefine commands, I will, I prefer the finger-dance with two letters than with modifiers. Related to this, on IRC we have been talking about undo ideas, for the future. One was some kind of grouped undo (using Shift, that is the link to this thread), but not clear how it should behave. When you are painting, you can do lot of strokes, and undo one by one is tedious and slow (so would be redo), suposing you do not waste all undo steps. Thanks to the new system, consuming undo steps is no such big issue like in previous Gimps (check the part about storing undo info if memory is avaliable, in preferences). But the workflow problem is still there. Undo history window can help... sometimes. For example painting or drawing (hundreds of strokes without changing tool) are not in those cases, cos the preview is not enough for the task (the size of it vs the size of the real change) and the description text saying the same always. If all is undone as Sven proposes... I think you can change workflow to use new layers or cloned layers, and forget about undo (discard layer = undo). That plus Revert is what I have been doing in 1.2, to cope with limited undo stack and single step undo (but not happy with it). Thus the next idea is choosing how many normal steps should be a group one, and if limiting it to "same kind" of step (IMHO, yes). I would put it in preferences with the other undo things, to cover from "click machine gun" to "all in one stroke" users. That or a spinner in undo history window. The user defines what is his "unit" for an important change, be it 5 or 50. Side of effect of grouping, it could be used to compact really old undo steps and save memory. Another idea floating around was time stamps. It can be interesting in some cases too. But the one that called my attention was grouping, due what I have been doing latelly. 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: Edit Alpha as Mask
[EMAIL PROTECTED] (2003-09-09 at 1857.11 +0200): > 1. Follow these steps: [...] > 2. Copy the following script (which uses an undocumented hack and may cease 3. Use the other script. Thanks Pedro for making me think again if my old one worked or not. It seems preview and image window have some issues updating, that made me think it worked when it did not. This revised script does not have problem with selections (that is the part I had to fix today, by copying the code I already wrote for other scripts) or undocumented values (used a different approach since day 1). Temp location (if not there, it got a page, so navigate the site): http://www.infernal-iceberg.com/gimp/alpha-to-mask.scm 4. Maybe instead of a script it could be an option for the add layer mask dialog. What do people think about this other solution? Personally I do not think changing the behaviour (without option) would be nice, cos it will disallow effects that are based in already transparent layers plus extra control via the mask (think fading text layer or animations). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: Gimp-developer Digest, Vol 12, Issue 12
[EMAIL PROTECTED] (2003-09-08 at 2144.30 +0200): > On Mon, 8 Sep 2003 21:18:32 +0200, Jean-Christophe Dubacq <[EMAIL PROTECTED]> wrote: > > As I do not think my former message reached gimp-users, I will try there > > (it also seems more fit, and I am subscribed): > > > > Is there any way to directly edit the alpha layer of a layer. Layer > > masks do only reduce the alpha, never increase it; and sometimes I would > > like to somehow delete any opacity information in a layer, without > > having to repaint all. So maybe there is a solution, but I didn't find > > this (since editing a mask is not the answer)... It is the way, I did an script for that, it passed alpha info to mask, removing it from alpha, completly. If you can not find it, ask me. > Anyway, please check the Eraser tool and enable the "anti-erase" option. > This is an ugly hack, but this is probably what you are looking for. Nice hack, I have been using it a lot latelly. For some things it is enough and fast. > I think that this option should disappear. Instead, we should have an > "undo brush". Because in most cases, what you want to do is to > recover some data that has been deleted by accident. So you could get > that from the undo history. It does not make much sense to "un-erase" > something if you do not know what was there before, even if this quick > hack was easy to implement in the early versions of the GIMP. So if > it becomes possible later to "paint with undo," then we should remove > the anti-erase option. Fill layer with something, make some holes... change your mind, rearrange holes. My usage was for hose brushes. Doing if from undo is going to be a bit more complex technically, and will not only do unerase, you will be able to undo paints too or filters, for example. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Third big serious meeting from GIMPcon
[EMAIL PROTECTED] (2003-08-24 at 1423.45 +0200): > - current debian unstable => 2.2.2 (2.2.2-3) > - current mandrake cooker => 2.2.2 (2.2.2-6mdk) > - current rh rawhide => 2.2.2 (gtk2-2.2.2-2.1) > > mdk9.2 is scheduled to be released on septembed, i do not remebed > exact date for rh but it's supposed to be at the same time. > debian is expected to be releasd on december. I hope debian pushes the unstable to the testing one before going for the release, otherwise we end with a bad version in the released distro (2.2.1, which has some nasty problems with Xinput, IOW, tablets, while 2.2.2 seems to be working). > so this issue may not be a real one. Some people, while compiling some things, prefer to have the rest from normal releases, not bleeding edge ones. Sometimes that is posible, sometimes it is not, I think we got caught in one of those "out of sync" moments. > - those who know how ot build programs: they're supposed to know how > to build dependancies How to and have time to handle all. ;] > well, ones can use its bugzilla mail box for such queries :-) Which tool are you talking about, btw? The full name, please. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Allow Maximise in Dialogs, like in Paint ShopPro 8
[EMAIL PROTECTED] (2003-08-17 at 1923.39 +): > Sorry if this is a silly question, but does the "maximize" button on > modern X11 window managers behave differently than in Windows? Doesn't > it always make the window fill the whole screen? It can do anything the WM wants, but the norm is like in MSWindows. Here I get vertical, horizontal or both, in full screen with or without borders and "collision" with things like pagers. > (Hmm, or is it so that even on Windows it is possible to make the > maximize button not always maximizing to the screen size, but to some > pre-set max size? If so, few applications seem to use this. Will have > to investigate.) The discussion is about which windows should be maximizable and then making sure they have the button (details about what maximize is are left to the wms). Typical fight wms vs apps. 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: 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: 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-21 at 1016.13 -0400): > At 11:42 PM -0700 8/13/03, Manish Singh wrote: > >Supports IEEE floats, but not float16 (a 32-bit float cut in half). R&H > >added this to filmgimp since they had established this format in their > >workflow with other tools already. > Why would you only use half of a 32bit float?? That reduces > your accuracy/precision and makes you incompatible with the rest of > the world doing floating point imaging. It is a trade off, ints vs floats. Better ranges than ints (in a rough sense) with less bandwith than floats. Currently supporting float is is the contrary of incompatible: it is a format for video cards (that explains why it was created and the tradeoff). People working in games want it, people working in using hw to render 3d anims want it to. > >GEGL uses XYZ as a native format. > Why? Lab is a richer model esp. for handling chromanicity > and is also a standard in the print world natively. Why limit to > XYZ?? Does using XYZ imply that LAB is not supported? > >It's not just the tags, but extending value ranges for tags (needed for > >the two cases above). And a lag time means either waiting for an updated > >spec, which is a holdup, or going ahead and running the risk it not being > >granted because someone else tried to get their conflicting values in first. > The spec is only updated every 18-24 months when Adobe > releases a new version of Photoshop - so you definitely don't wait > for that! As for the other, yes, that is true you could wait, but > nobody does... Where are those updates? Is it some kind of errata or addon? The PDF I have says 1992 (TIFF v6.0). > Never implemented a file format, have you ;). > Reading/Writing the 'ar' archive, and reading/writing the XML > is the easy part - because you can leverage existing libraries to [...] > Worth the work, sure! Trivial - no way! That is the reason other ideas are being examined. 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: 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: 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-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 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: 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: 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: Gradient dithering
[EMAIL PROTECTED] (2003-07-17 at 1854.40 +0100): > I've created a little patch against GIMP 1.2.5 to allow dithering of > gradients, which significantly improves their appearance when printed. This is bug number 9 (http://bugzilla.gnome.org/show_bug.cgi?id=9). It does not only affect printing, screen too. I had to use spread filter to fake this sometimes. You should check what is going on with CVS version (or 1.3.16), so it gets fixed there, which is where it should be. 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: 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: 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: 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: New thread on GIMP 1.3+
1.4. 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 L&C 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: 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: 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: 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: 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: Preferences suggestions
[EMAIL PROTECTED] (2003-03-03 at 1145.16 -0600): > Comments on the Preferences dialog: > 0. General comments >a. Why is the default font for labels so small? My eyes are old! Uh? If I understand you, what you have is to change your font, cos the font size looks like the default one, and in some places just bigger, but I do not see where it is smaller than the default one. So I do not get it, or the problem is elsewhere. > 1. Page: New Image >c. Why a "dpi" *AND* a Pixels/inch setting? The bottom set, > with the "Pixels/inch" options menu should be enough. "DPI" > should be part of the text header for this frame. No, DPI should not be in the header, cos if you set the menu to pixel/mm, you are not talking about DPI anymore. You are always talking about resolution. Removing the top one could be an option, keeping is another, and this one is nice for those that want to use see DPI (typical unit for printing) and at the same time get an unit they can imagine quickly (all non inch users), which I think is a noticeable group of people. It is a tricky area for those who have to mix the local units with the graphic units. >d. Why do we have a "maximum image size?" Shouldn't GIMP > handle any image size? Should this value be set as a > percentage (rounded to a power of 2) of installed memory? Hehe, the talk about disk cache and such again. ;] BTW, it is not a hard limit, just a warning limit, so errors are corrected faster (ie, not waiting your computer to swap tons of MBs). The problem is the label, probably. > 8. Merge the Display and Monitor pages. They're similar enough >and can fit on one page. The transparency thing is more an Image feature (like padding colour). But the 8 bit part could be placed somewhere with other Monitor things. >b. Maybe it's me, but I think the icon for Environment ought > to be trees and a sun, not a nerdy IC. Think in other languages too, maybe in those the correct translation of computer environment has nothing to do with trees. And from looking at the contents, a chip makes sense, it lets you configure memory things. > 10. Page: Folders >a. What do the green dots in the "Folders" page represent? "OKness" of the path. If path is wrong, it appears red. 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: Re: alpha vs. transparency / translucency
[EMAIL PROTECTED] (2002-12-19 at 1208.55 +0100): > the user shouldn't be confronted with the term RGBA at all. IIRC, this > is the case unless she's writing a script or plug-in in which case she > is not a user any longer but a developer. Then no confrontation with CMYK either, or with bit depth or DPI or moire or lots of other terms. Sorry, but all these are terms of the trade, dunno why should that be not under user control and view, at least if the app is not a basic paint app but something more advanced (like GIMP was, is and I thought will be, at least in one of the modes / interfaces / whatever). And BTW, Alpha channel is one way to get (1 - Transparency) or Opacity, Layer Masks are another. If this is not the situation, tell me what is. 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: 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: 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: bug hunting -- squashing windows bugs
[EMAIL PROTECTED] (2002-12-03 at 1038.37 +0100): > > > And guess what, it fixes all GIMP bugs too!. After all, GIMP is > > > part of GNOME, so if you don't install GNOME, there won't be > > > GIMP, so there won't be any GIMP bugs! Yay! > > Erm, maybe this is a stupid redhat thing, but I thought GIMP just > > used GTK, (ala, it works on all desktops, including my > > anti-desktop environment desktop) > True, but there are more programs that are part of GNOME, but don't > (necessarily) use the GNOME libs. Anyway, on the webpage, GIMP is > listed as part of GNOME Office: > http://www.gnome.org/gnome-office/gimp.shtml They list OpenOffice, so the "what is and what is not" is really fuzzy. http://www.gnome.org/gnome-office/index.shtml Oh, well, another "is mine" war. 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: layer groups (was: Film Gimp and GIMP)
[EMAIL PROTECTED] (2002-11-29 at 1833.03 +0100): > - Simple linking of layers so that some operations such as toggling > their visibility or moving the whole group of layers can easily be > applied to them (bug #86337, bug #86277). These operations would > not modify the pixels in the layers. This could probably also be > used for implementing the clipping groups (bug #51112). Clipping sounds more like ATOP operation in other docs, not like simple move or visibility, so I would put it in the other group, or make it some kind of blend mode (hidden) or pre process in blend operations. It "modifies" pixels, by looking at the bg alpha. The traditional document about digital composition is from Siggraph 84, by Porter & Duff, just in case people want to read more this ATOP thing. Scanned copy at http://www.keithp.com/~keithp/porterduff/. > - Grouping of layers in such a way that a merged image of the layers > is stored in a virtual layer and some operations can be applied to [...] > (merged view + results) and to apply the PDB function only to the > regions that have been modified, but this is only an optimization. You say they are the same, which from the one point of view is correct. But from other they have some differences that would make nicer to consider them a bit special. Layer effects would allow external ops, and use two drawables only, "in" and "out", with "in" one being updated rarelly (and thus "out" too). They are more artistic oriented, to say it quickly. Adjustment layers would allow core ops and N inputs, with those N changing a lot, and thus lot of recomputation, like blend modes. What is more, I would see them as blend modes that have some vars to control the formulas, and the RGB channels working as selection does. This also means that, probably, layer effects have a region of interest of multiple pixels for each output pixel, while adjustment layers only get a pixel, operate and put back (use LUTs?). If the system can be done so fast that there is no big differences, I see no problem with making all the same. Otherwise, maybe a forced separation would be better. 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: regex
[EMAIL PROTECTED] (2002-11-26 at 1036.29 -0800): > My confusion relates to script-fu and gimp plug-ins with respect to regex. > Why query a plug-in as a regular expression? What's the point? Gimp keeps a DB of info about all plugins. In startup all are checked, if they changed since last time, they are queried, asking them what they do, and the replies are stored. The regex is used to search in the DB that stores all the info. Read gimp-procedural-db-query and gimp-plugins-query in / Xtns / DB Browser, and guess how the browser works. :] 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 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: 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] Help with icon theme
Hi: I am trying to make a icon theme to mimic 1.2, but found a weird problem. See attached tarball demo, here is README: ---8<--- Can you help seeing what is going with GTK+ icons? It would make a Classic theme for GIMP work, and probably discover what is going on (GIMP? GTK+? this install?). You should unpack the tarball so you have: ~/.gimp-1.3/themes/Classic/ ~/.gimp-1.3/themes/Classic/images ~/.gimp-1.3/themes/Classic/images/single-pix.png ~/.gimp-1.3/themes/Classic/images/test-blue.png ~/.gimp-1.3/themes/Classic/images/test-green.png ~/.gimp-1.3/themes/Classic/gtkrc ~/.gimp-1.3/themes/Classic/gtkrc-no-icons ~/.gimp-1.3/themes/Classic/gtkrc-icons ~/.gimp-1.3/themes/Classic/README Then in ~/.gimp-1.3/gimprc add a single line: (theme "Classic") Launch gimp-1.3 and check if you have the blue square or the green one where the four arrows icons is in image windows. Blue, the bug is general, green you got the right thing, the bug only happens in my machine. Thanks in any case. If you have the GTK+ module named GLE (gle module in the same cvs server than GIMP), you can use the inspector, navigate to the GtkImage of this and change the size from 4 to 3 and back to 4... it appears. :-/ --->8--- Thanks in advance. GSR Classic-test.tgz Description: GNU Zip compressed data ___ 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] 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: 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] 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);
[Gimp-developer] Re: Re: YCbCr (de)compose support [PATCH]
[EMAIL PROTECTED] (2002-10-22 at 1941.37 +0200): > > you would save us some work by attaching a "fixed" version of your > > patch to the bug-report you opened for it. > done Thanks, I took note of it here too, btw: http://bugzilla.gnome.org/show_bug.cgi?id=28889 GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: YCbCr (de)compose support [PATCH]
[EMAIL PROTECTED] (2002-10-22 at 0048.04 +0200): > i changed Y,Cb,Cr to brightness, blueness, redness in the patch on the > bug-report, that should be more descriptive I always heard Y to be luminance, not brightness, and never heard people using redness, just Cr. Remembering which version was used could be nice (important? a time saver?), so for the image names I think they could be luminance_y709, redness_cr470, blueness_cb470f and so on. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[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,
+
[Gimp-developer] Re: GIMP Print Dialog Box
[EMAIL PROTECTED] (2002-07-17 at 1129.11 -0400): > How do I get the title of the print preview window. I can get the window id Use xprop and cut out what you do not need. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[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: Curves files
[EMAIL PROTECTED] (2002-04-04 at 2309.59 +0200): > > something about the curve widget, I guess, but today I am a bit > > "obtuse" with my grep and coding skills. > More than you think ;-) > from 0 to 16, that's seventeen values! Can I delete this day? :] GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Curves files
[EMAIL PROTECTED] (2002-04-04 at 1942.21 +0200):
> I have a question about this limitation: why the Gimp spline curves is
> limited to 17 entries and the procedure gimp-curves-spline use a 32
> items array of points?
> May be it is not the same goal but that is the difference?
Code from the file, it reads 16 pairs:
for (j = 0; j < 17; j++)
{
fields = fscanf (f, "%d %d ", &index[i][j], &value[i][j]);
if (fields != 2)
{
g_print ("fields != 2");
return FALSE;
}
}
Umm, hehehe, it reads 16 pairs, x and y values, not 17 (< 17, not <=
17). Sorry, my fault. I am still investigating why 16 and not other
value (could be 256 as amp files, and avoid the x value). Must be
something about the curve widget, I guess, but today I am a bit
"obtuse" with my grep and coding skills.
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] 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] 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] 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] 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] Re: Re: Menus, keybinding et al, first draft
[EMAIL PROTECTED] (2002-02-22 at 1248.44 +): > I'd like to whine: I use ALT+mouse1 *inside* a window to quickly move > it somewhere else on the desktop, therefore any ALT clicking is going > to annoy me severly. Alt+MB1 has been used to move the selection for a long time, it is even documented in the tips messages (something like "if your window manager does not interecept... blah blah"). So you have been missing it for a long time. > Could someone post a summary of the differences between the current > setup and the proposed new setup? I have been moving menu things around, and proposed some extra keys, but did not get into tools keys (make circle for ellipse select and such). Maybe they should get a config area too? 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: 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. 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. > 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: 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] 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 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: 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 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: - /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] 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: > [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... > [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:1
[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: TODOs for GIMP-1.3
[EMAIL PROTECTED] (2002-02-13 at 0058.58 +0100): > IMO the menu structure would benefit from a well-planned overhaul. If > someone feels annoyed enough by the current situation, he / she could > try to come up with a proposal for a better menu hierarchy. We have > done this before several times and I think it always got better, so we > should prolly do it again in this development cycle. That one is easy, I will check what I have from IRC and other comments, then start post revisions. :] > Related to the menus, we also need a concept for accelerator keys in I will write as I do the menu doc, I already have some keys in it. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: [Gimp-user] Opening Photoshop Files
[EMAIL PROTECTED] (2002-02-07 at 2038.50 +0100): > > Went to an Adobe conference yesterday and they claim photoshop 6 has > > been tested with images up to 8000 layers. They said it can probably > My GIMP crashed somewhere between the 300th and 400th 16x16 layer. I I went up to 420 by hand (64 * 64 pix, and not big RAM usage, BTW), no crash and dialog updated (can I say Windows problem?). And now that some people seems to have a layer festish, maybe a script that adds 256 (or choose a number) per run could be done, so some people become happy. But also... how many layers are really useful? IOW, "my foo can do n^2 bars" vs "user just uses n". Of course, the fun factor is there, "this script goes up to n^n in one click". :P 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). 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 :] ). GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Include plug-in in Gimp distribution
[EMAIL PROTECTED] (2002-01-11 at 1220.31 -0600): > How about something that could connect to the plugin registry from within > Gimp so users could see all plugins availiable, get a description, and > install plugins they might want by just clicking a button. How would you handle compilation, btw? There is no binaries provided, and the compilation is not unified at all (some work with gimptool, others use auto* tools, some do not compile with version x.y, etc). If you can convince everyone to use the same methods, it would be easier. Hint: all those people that complain cos do not know how to compile, could use their social skills to politely make requests to coders, and also make a status list (who coded what, who is in charge now, what mail address is valid now, what webpage...). > Being a newbie I'm not even sure really where to begin but maybe with a > bit of direction I could attempt something like that. I know I could > probably do it in Perl but that would probably be a bit slow. The bottlenecks will be compilation and network, not the logic glue, IMO. Also, some plataforms do not include / have easy access to Perl or compiler (more things to add to "you need this list of devel packages to get this filter running"). A global solution is hard (binaries for everyone or enough logic to cope with most problems in a heterogenous environment), and the half solution is already there (you can install, you just need to know what you are doing or pay / bribe / abuse someone to do the maintenance job for you). Yeah, it looks bad... but many times the topic has appeared, and many times the things have followed more or less in the same state. :[ GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: what's up
[EMAIL PROTECTED] (2001-12-20 at 1223.19 +0100): > Guillermo helped finishing the task of switching all dialog buttons > over to the button ordering for GTK+-2.0. It is not finished, I have to finish lot of plug-ins, I review groups when I have time. I am also trying to improve some interfaces too (first the curve bend filter one). And if I discover a way to dump the widget tree, adapt my gtkrc experiments so they become useful (basically remove extra icons for those users that just want an ultra clean interface), as theme or config option. This one filled as bug 65843. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: B&W 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
