Re: [Gimp-developer] discussing the roadmap for 2.6
On 10/24/07, Sven Neumann <[EMAIL PROTECTED]> wrote: [...] > IMO it would be best if people proposed features here so that they can > be discussed on the list. We should then collect these proposals > somewhere and try to decide on milestones for them later. It would > probably help if we try to be strict bout only proposing a single > feature per mail. Sound good. Bugzilla seems like overkill until the roadmap is laid out. I'm not a contributor though - I'm still (slowly) becoming proficient in c/c++. Looking for some low fruit on the GEGL switchover... Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor
Sorry - I always forget to Reply-All to this list... On 7/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: [...] > GIMP IS A TOOL, NOT A TUTORIAL. > > Take an analogy: > > A builder needs to nail a piece of wood as a guide but all the nails he > has to hand are too big. To get round the problem he takes a couple of > screws he has in his pocket and hammers them in to tack the guide into > place. > > Well we all know you should NEVER hammer in a screw but it gets the job > done. As a high-end builder he uses the tools and materials to hand to get > the job done with the minimum of wasted time. > > Now imagine he'd just bought the new "high-end" Gimp Hammer, the high-end > solution for high-end users. > > When he comes to hit his nail he realises the his new high-end hammer has > a specially crafted end that slips off screw heads because the guy who > designed it thinks you should NEVER work this way and wants to force his > work flow to the one and only _correct_ way to do this job. > In this analogy, the new "GIMP Hammer" would auto-provide a nail (since the nail is clearly better). The carpenter would flip the GIMP hammer around and use the other end to drive in the screw. Since carpenters are pretty dextrous - high-end ones anyway :) - I think the carpenter would enjoy the versatility of the GIMP Hammer. No one in this discussion has ever said anything about removing GIMP's ability to produce JPEGs. What (I think) is going on is a discussion about whether or not "Save" is an appropriate command for an action that discards data. IMO opinion this pertains more to the newbies than anyone else. Those who've used graphics for some time now (should) know what we're doing. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On 7/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Tue, 10 Jul 2007 02:08:45 +0200, Chris Mohler <[EMAIL PROTECTED]> wrote: > > > I expect the "Save" command to retain > > *all* data: not just some. > > If you expect that when using jpeg you are wrong and need to see the first > use warning that has been suggested. I understand that JPEG drops data. My point: in most applications, 'save' means "save your data". In the image editing world, 'save' has come to mean "save as much data as you want given the limitations of the format - here are (or might be) some options". > > Exporting is preferable to a "lossy save". > > Says you. This is not always the case. It depends what is required. It's just my opinion: save != lose > > Just because most image editors throw away > > parts of your file, there's no reason for GIMP to follow suit (anyone > > ever play Lemmings?). > > I dont recall anyone having advanced that as an arguement. I really think > we should stop exagerating this issue. It's a non-issue - we have enough experience to dodge the pitfalls of lossy formats. It's the status quo, and we live with it. My source files stay XCF, TIFF, or PNG and my web files end up JPEG or PNG. Such is life. I just wonder if it could be easier. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
At the risk of lengthening this thread... :) I agree with Peter - saving in a lossy format is a last-step operation in a good workflow. I respect the case of simple tweak and saving, but in the long run, all users should never being able to choose "save" and then lose data. I expect the "Save" command to retain *all* data: not just some. Just because most image editors throw away parts of your file, there's no reason for GIMP to follow suit (anyone ever play Lemmings?). save != lose I see recent activity on the 'Save for Web' dialog. Once completed, it should offer the user enough ways to publish a lossy image for end-use while retaining a lossless original image. Exporting is preferable to a "lossy save". The solution of presenting the dialog on first save is a Good Thing (thanks Sven!). Having a lossless workflow is a Better Thing, and hopefully the direction of the future. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Three point layer distortion mapping feature?
On 5/2/07, Mark Lowry <[EMAIL PROTECTED]> wrote: [...] > What are everyone's thoughts on this? Is it worth > initiating an enhancement request in Bugzilla? IIRC, hugin[1] can align stacks of images. Chris 1 - http://hugin.sourceforge.net/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK palette info from Photoshop
On 4/10/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > The lcms plug-in is a good example as it already uses the color profiles > you need. That is the profiles configured in the Color Management > section in the prefs. > > The problem that we are facing here though is that the bug you are > looking at is supposed to be fixed in the core. And the core doesn't > know anything about color management and doesn't link against lcms. Not > sure how this would best he handled. We could add functions to the lcms > plug-in so that it can do the CMYK->RGB conversion for you but that > would likely be too inefficient. Perhaps it's easier to write a > standalone palette converter? Including lcms is a bit ugly, and there's a 1000% (estimating) performance hit - but that might be something I'm doing wrong. I've also failed to get a solid conversion with lcms so far - and unless I missed it, there's no built-in CMYK profile in lcms so there's the issue of what profile we'd have to use. "Naive" conversion is fast, but obviously the colors are not accurate. I'm leaning toward just throwing out the CMYK data for now, but I'm still fiddling with it. Chris > > Sven > > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK palette info from Photoshop
Thanks all - I should be able to figure something out from your suggestions. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK palette info from Photoshop
On 3/31/07, Hal V. Engel <[EMAIL PROTECTED]> wrote: > You might consider using a color transform using ICC profiles. For example > you could use sRGB as your generic destination color space and perhaps a SWAP > profile for the CMYK side. Once you have selected your two profiles doing > the conversion is almost trivial using calls to lcms. Hal, Could you point me to an example? I see some functions in plug-ins/lcms, but have not figured out how to use them. Most seem to operate on drawables - I want to push CMYK number values into RGB. Thanks again, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] CMYK palette info from Photoshop
Hi, I'm working on bug #316618: http://bugzilla.gnome.org/show_bug.cgi?id=316618 I was cruising along until I found that Photoshop palettes have many CMYK data. What's the best method of converting these colors to RGB and getting reasonably close? I tried the functions here: http://developer.gimp.org/api/2.0/libgimpcolor/libgimpcolor-GimpColorSpace.html But they aren't working very well - is there a better method? Thanks, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 3/19/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > We aren't using cairo yet. But I don't see what you would want to use > gdk_draw_drawable() for. OK - I have more to learn! > app/dialogs/dialogs.c, IIRC Thanks. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 3/4/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > But yes, the most obvious and by far the easiest solution is to add a > tracking view that users can add to their docks similar to the > Navigation dialog. I've filled out a feature request based on this approach. I've also taken initial steps to implement it, but I have some questions ;) 1. gdk_draw_drawable - should this be used, or dropped in favor of cairo/gnomecanvas/other? 2. adding a new widget was pretty straightforward, but mine is still missing the icon in the tab, and I see this in the terminal: gimp_menu_factory_manager_new: no entry registered for "". My grep-fu isn't working - where does one reference the icon/menu item? Thanks, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
First off, I want to apologize - it's not my intention to be combative, and I can be a total ass sometimes. Secondly, I wonder if we should make two feature requests: the first for a dockable magnifier with options, and the second for a key-triggered pop-up version of the same magnifier. Should there be no objections, I'll file the first request in BZ. Peter, do you have any problems with writing up the second request? Sounds like you have a clearer vision of how it should be implemented. Finally, I'm looking at the latest SVN to see if this is a project that's within my abilities. It looks like a lot of the code that's needed already exists and just needs to be extended into a new dialog - pointers/pitfalls welcome. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
On 3/4/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > On Sun, 2007-03-04 at 12:53 -0600, Chris Mohler wrote: > > > [1] This seems like the best existing dialog to place this. It > > doesn't seem to warrant it's own dialog, unless we were to extend the > > funtionality into a new "info" dialog similar to PS, in which the > > color values under the cursor are reported > > GIMP already has such a dialog among the dockables that the user can add > to their docks. The easiest and the most consistent way for adding a > magnifier view is to add it as another dockable. It should be pretty > much straight-forward to do that and it would solve most of the use > cases that have been brought up. Wow. Until today, I had overlooked the 'pointer' dialog. D'oh! Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
Here is the feature request (as I see it): distill away. Magnifier: (Needs a better name - spy glass, super loupe?) The maginfier provides the ability to see an "up close" view of the area immediately surrounding the cursor, in a manner that does not interfere with the current view of the image. The center of the up-close view represents the cursor, the image "scrolls' past the center of the up-close view as the cursor moves across the image. In case that's clear as mud: the cursor is fixed in the magnifier view, and only the image data moves. (Think of the bombsight on a war plane) A "static" magnifier could be added to the navigation dialog[1], below the current image "map", and small in size. Additionally, a command or shortcut could be applied to "pop-up" (and banish) a magnifier. Both the static and pop-up magnifier should have a simple plus or minus zoom setting[2], and possibly a text entry for percentage. In short, the main purpose of the tool would be to provide a precision view of the cursor when making selections[3] that are too large for the image window when zoomed in - removing the need to zoom in and out multiple times while making a selection, therefore making workflow easier. Chris [1] This seems like the best existing dialog to place this. It doesn't seem to warrant it's own dialog, unless we were to extend the funtionality into a new "info" dialog similar to PS, in which the color values under the cursor are reported, along with selection size, tranform values, etc. Most of this info is reported already in the status bar though. [2] Another shortcut for zooming the magnifier? [3] A suggestion was made to tie the magnifier to the selection tools, but it seems that a magnifier could also prove useful when performing other operations besides selections. Moving a selection for example: one could grab the selection at the very edge and watch for alignment with a particular area (in the magnifier), while still being able to see the overall layout. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enhancement Proposal: Add a temporary magnifier
> how should tool interaction work with this? Would you want to see the > mouse cursor in the magnified view? Should you able to interact in it or > is it just a view? IMO, there should be a fixed crosshair or something in the center of the "zoom window" that corresponds to the cursor. As the tool moves around the image, the image scrolls but the crosshair does not move. I do not think there needs to be be any interaction, other than being able to set the magnification level desired - either in prefs or in the window itself. I'm not sure whether it would be best to implement it as a pop-up as suggested, or as a dialog. I'd probably vote for some type of toggle on the existing navigation window, or a new dialog similar to the nav window. I would probably find the pop-up annoying after a time. Just my 2¢, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fonts Dialog
> You don't really need to restart GIMP. > Its enough to rescan and it's done. > Just click on "open font selection dialogue" and you'll find rescan. > > Salvatore Awesome! Now I feel like an ass for requesting a feature that exists... Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fonts Dialog
On 12/30/06, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > On Sat, 2006-12-30 at 15:29 +0100, iwkse wrote: > > > Such feature is useful when the user has a really high number of fonts > > cause loading all them slow down whole gimp at the start. > > Why not just fix the slow startup instead? If your copy of fontconfig > would work correctly, GIMP would only have to scan the fonts the first > time it is started. Subsequent runs will use the cache file. If that > doesn't work for you, then something is wrong with fontconfig on your > system. Well, if you *do* have thousands of fonts and they're all activated, the font list is two kilometers long! That's a problem not specific to the GIMP, but system-wide. I've been using an app (called fontypython) that creates symlinks in ~/.fonts and then restarting GIMP (or whatever program) whenever I need to switch fonts out. It would be nice to "rescan" for fonts, though I'm not sure how much work would be involved. I'd love to hear your thoughts... Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Fwd: [Gimp-user] Color selectors, which one do you use?
> Actually, during the user observations we found out that > print-oriented professionals have learned to thing in CYMK. How I wish I could remove that part of my brain that translates RGB to CMYK. Back on topic - I use the default picker. I would use the triangle were it snappier. The CMYK sliders are a must - but they could be added to the 'scales' color picker in order to consolidate. I don't have any use for the watercolor picker, but I can see why some folks would like it. The palette picker doesn't seem useful unless you can edit/load/save the palette(s). Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Spot channels in TIFF files.
Hi, I thought I'd give a shot at adding spot colors to the GIMP TIFF implementation. If I understand, I need to look at /gimp/plug-ins/common/tiff.c and add some of the functionality found in /gimp/app/xcf/(?) (specifically, the portion that assigns the channel color and opacity), and have tiff.c write the channels to file following the TIFF 6 spec. Please correct me if I'm way off-base... I've see a separate bug (feature request) regarding saving spot channels in PSD files - perhaps adding the channels to TIFF will be easier, since the spec is readily available... (and add pretty much the same functionality). Thanks, Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Intro and a CVS question
> If no specific branch is mentioned, "current CVS" usually means the HEAD > branch. > This is what you get if you just do a cvs checkout without specifying a > revision > or branch (i.e., no option like "-r gimp-N-N"). > > -Raphaël OK - thanks! Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Intro and a CVS question
Hi - My name is Chris Mohler. I'm not a hard-core programmer, but have some experience with C and Python. I've recently set about to assembling a prepress environment with OSS tools. Of course GIMP is a cornerstone of the project, so I'd like to become more involved with GIMP development. What release should I be checking out of CVS? Or stated another way - on various bug entries, I see "please create a patch against current CVS". Is current CVS gimp-2-2? Sorry if this is a dumb question! Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
