Re: [Gimp-developer] I need help about CMYK on gimp
> On Mon, May 23, 2011 at 11:05 AM, Bogdan Szczurek > wrote: > > One final thougt: CMYK support subject was touched more than once > > on this list, but I think we should consider much broader view on > > the matters of printing. CMYK is only most often used set of > > colorants but there are much more colorants out there. Having > > native CMYK would be cool thing but even cooler would be to be able > > to add more colorants to prepared images. What about having > > "metallic" overprint/underprint in your projects? What about > > Hexachrome? Sure, one could prepare image in wide enough RGB > > (example ;)) and rely on profiles with hexachrome or prepare > > metallic layer in separate file but hey… one could also edit RGB > > files stored channel by channel in separate files but what for? > > Note that GIMP does offer support for such a a "manual spot-color" > workflow through the use of Channels - it can work for jobs sporting > one or more distinct spot ink such as metallic or fluorescent. > Although there is no preview or separation for that, at least one can > edit everything in the same .xcf project and export to distinct files. Yup, I know, but how appealing it would be to have a preview :). A man can dream… a man can dream… ;) > As for yor other comments, even though they might express a need of > some designers, as you stated, they are not in current GIMP road map > neither seem as a goal of the program. It's a pity, though understandable… > If one is willing to ditch > color profiling alltogether, and wants to compose an image work only > with colorant intensity, it should be clear that GIMP's code base does > not support that, and another program should be used, unless it can be > achieved with the naive approach offered by image Channels. My best! tb signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] I need help about CMYK on gimp
-- cut -- > The agrreded idea among GIMP developers is that CMYK as an _image > editing mode_ will not be implemented in GIMP. Where as there maybe > in the future more straightforward ways foreasier CMYK separation and > printing. > That is due to the fact that CMYK is more the mapping to inks of a > printing method > than a color mode. Quite similar can be said about RGB or any other device dependent color model. But first of all there is not only one CMYK. CMYK name itself denotes a family of color spaces. So it is for RGB too. > Even though this is the "de facto" printing method for > volume, and even personal printing, CMYK values don't have a > 1:1 mapping of color values as are visible to the eye, or representable > in computer videos or images. It's not so easy. Each CMYK color vector can be injectively mapped to color visible to the eye. > (which color is "black" in an image? > (100, 100, 100, 0), > (0,0,0,100) or (100, 100, 100,100)? ) > That said, for generating CMYK Tiff files as expected for some of > today's printshops, and even allowing for some per-plate correction > of the amount of colorants in each part of the image, there is the third party > plug-in Separate+ ( http://cue.yellowmagic.info/softwares/separate-plus/ ) > I believe that installing and getting used to that might your requirements > for CMYK. While useful I consider it only a half-solution. > So ..what is the idea for GIMP presently and on the long term, is that proper > printing requires actually conversion between the color spaces of the various > devices used in the press chain (video monitor, proof printer, large > scale printer), > making use of _color profiles_ . With proper calibration of devices and use of > color profiles one can ensure that a color shade will look on paper, under > certain lighting conditions, as it does look on the screen at editing > time. All the > time the colors are represented internally as an RGB tripplet, and > just the printing > driver, or software, takes care of mapping the normalized color to the actual > colorants in use on the device - taking into account information on the > device's color profile. Even so, if we consider ICC color management scheme, there's still potential problem: rendering intent. Which one will printshop use? It's all OK if used colors are well within output color space, but what if not? It's not so rare case. In such case the decision which colors to transform unreproducible colors to is left to printshop not the designer. And what if you want to use some non-standard trick with colorants values? Every color conversion can be done with properly prepared color profile but in practice it's much easier and faster to modify color values in device color space and preview results e.g. on RGB device than mangle color profile each time. Quite often it's better to drop color management completely on "printing side" and prepare material directly for specific device (more exactly: CtF/CtP + actual printing machine + paper) – gives you less surprises in the end. Color management is cute idea but it's not panaceum and sometimes we're better off without it. > On GIMP's roadmap, there lays, in the future, a way to preview a per plate > separation of the image prior to having it exported to a CMYK file in a > more integrated way than currently possible with the separate+ plug-in. But > that > depends on the implementation of a new, very different, U.I. that will allow > for non-destructive editing, among other things. Work on this U.I. will start > only after current development cycle (which will yield GIMP 2.8). > > Meanwhile, if you find that GIMP with the Separate+ plugin is not > enough for your > office's needs, there are other Open Source graphic editing programs that > offer varying CMYK capabilities, such as Krita and Cinepaint. -- cut -- One final thougt: CMYK support subject was touched more than once on this list, but I think we should consider much broader view on the matters of printing. CMYK is only most often used set of colorants but there are much more colorants out there. Having native CMYK would be cool thing but even cooler would be to be able to add more colorants to prepared images. What about having "metallic" overprint/underprint in your projects? What about Hexachrome? Sure, one could prepare image in wide enough RGB (example ;)) and rely on profiles with hexachrome or prepare metallic layer in separate file but hey… one could also edit RGB files stored channel by channel in separate files but what for? My best regards tb ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL Editor - Idea for GSoC
W dniu 11-04-01 23:55, Marek Rogalski pisze: > Hello, everybody. > I have a quite simple proposal for this year GSoC: make a nice editor > for GEGL pipelines. > > Why do we need it: because the GEGL eats XML files. GIMP could eat > them too. It would introduce much greater reusability in the work of > designers. > > Who will use it: graphic designers (who else? :p). The concept of GEGL > operations is sufficiently simple to be used even by casual users. > > How it could be used: GIMP could show a list of GEGL XML files that > can be applied to current layer. Very similar to how the filters are > exposed right now. The editor itself could be located in GIMP (I would > like that :) ) or as a separate program. > > I have been generating various content on this topic for around a year > and made a few concepts. Their code is packed at > stud.ics.p.lodz.pl/~mafik/prototypes.tar.bz2 (contains a few interface > ideas) (bother to look only if > you want to deal with lots of unfinished code). I have made a sample > here: http://www.youtube.com/watch?v=sEm9M2O6xC0 (second part shows > much better, what I am thinking about). > > There are many areas where the idea could be clarified, but the > concept should be clear. > > Request for comment: > - what do you think of the whole idea? Would it be useful or not? > - should it be merged with GIMP or work standalone (or both :) )? > - is Vala mature enough to use it as the main language? >(I'm asking because I saw some discussions about it recently on this list) > - what gui toolkit would be appropiate? GTK or Clutter? >(I fell in love with clutter, but there may be reasons not to use it > for such program) > > Other ideas: > - shebang at the beginning of the GEGL XML - drop files on the script > and get them processed > - automatically generate GtkBuilder XML for marked parameters of GEGL > operations - could > be used to display filter-like dialogs of arbitrary GEGL pipelines. > > PS. (note to GSoC mentors) I would like to take part in this year > GSoC. If you encounter my submission, take it under considerations > only under this idea (if it passes, of course). Blender's Composite Nodes anyone? ;> http://www.blender.org/development/release-logs/blender-242/blender-composite-nodes/ Personally I love the idea. What is more, I think that such editor could be developed as an external project, independent of GIMP, yet "pluggable" to the latter. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Announcing AdaptableGIMP
> On 03/12/11 00:03, Bogdan Szczurek wrote: > > It seems most promising! > > > > Best regards! > > thebodzio > > > > > > > > ___ > > Gimp-developer mailing list > > Gimp-developer@lists.XCF.Berkeley.EDU > > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > > What seems promising ?! > > Best not to cut off whatever it was that you are replying to . I > don't want to have to go and search and online ML archive just to > find out what you comment relates to. > > ;) That: :) > We would like to announce the availability of the initial release of > AdaptableGIMP, a modified version of GIMP that integrates new social, > community-based customization features into the application. The > project page and software can be found at: > > http://www.adaptablegimp.org > > This initial release is available in source code form only. Binaries > will follow. > > AdaptableGIMP introduces a new way of interacting with software: > Rather than hunting through menus to find commands, users simply > enter what they wish to accomplish in a search box. As they type, a > list of interface customizations appears. These customizations---what > we call "task sets"---streamline the interface by putting every tool > and command necessary to accomplish a task in one, centralized > location. > > Task set customizations can be created by any user, and are instantly > shared with the rest of the user community. Wiki-based documentation > accompanies each task set, enabling users to pair tutorials and > "how-to's" with the customizations they create. > > AdaptableGIMP is the result of ongoing research by members of the > University of Waterloo's Human Computer Interaction Lab. It is > directly informed by our previous project, ingimp, in which we > collected over 2 years' worth of data describing how people use GIMP. > Like ingimp, AdaptableGIMP collects data about how it is used in > practice, to help us continue to research new and innovative user > interfaces. > > Feedback about the project and its goals is welcome and can be > emailed to the project at the address found below. > > Michael Terry and Ben Lafreniere > adaptableg...@cs.uwaterloo.ca Oh, gee… ;) I found that announcement “most promising” :) Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Announcing AdaptableGIMP
It seems most promising! Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
> On Tue, Mar 8, 2011 at 8:00 PM, Bogdan Szczurek > wrote: > >> > I've got a dream about visual editing program consisting of > >> > different components, each taking care of one of presentation > >> > aspects with one underlaying rendering engine (target aware > >> > angine—I don't like cairo's “I don't care what's on the end” > >> > attitude ;)). > >> > >> It's what we, utter geeks, call a framework :) > > > > That adds +10 to "coolness" but don't let everybody know ;) > > > >> Deneba/ACD Canvas was an attempt to create such one, but it was > >> done on top of software started in mid 80s. Sometimes a whole week > >> passes when I don't wake up in cold sweat seeing it in my dreams. > > > > Funny stuff… :). But seriously, sometimes it's good for somebody to > > try a thing that didn't work out last time. Because of that > > stubborness we're able to fly by airplanes nowadays ;). > > > > I consider idea of one flexible uberapp much more sensible and > > appealing than implementing wee bit of “alien world” in different > > apps—just seems half-solution for me. > > So do I,. and a "framework" that can make something like that happen > is called GEGL ;) I'm happy to hear that! :) > http://pippin.gimp.org/tmp/gegl-foo/ > > Buried in history of the GEGL repo is a GTK+ based UI with at various > revisions both freehand painting with simple dynamics, as well as.. > node based both bezier and spiro curve editing bits, integrated with > generic layer filters and more.. it is/was not really that much code, > but it was sloppy code thrown together with left-over pieces from a > video editor. > > I am from time to time toying with resurrecting that project as a > minimal thing show-casing what is possible to achieve. If I do get > around to do that I would probably avoid doing it with C though, so it > would be a complete rewrite and not really a resurrection. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
> > Yes, but why use RGB at all if one can use e.g. XYZ from the start? > > So "wide" RGB would also require greater than 8 bit depths to work > > satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per > > component). I think one consolation is possible backward > > compatibility with some other RGB spaces, but isn't BC a b**ch? ;) > > Besides there's a trouble of defining such “new” RGB workspace: > > what white point should be choosen and what primaries (all have to > > be defined in some absolute color coordinates BTW)? Whatever space > > would be choosen we wouldn't escape color conversions in color > > managed workflow, so while I'm not RGB enemy I fail to see the > > reason to stick to it especially since there are “wider” color > > spaces that are more intuitive to work with. > > It is a matter of which well defined color space the operations > desired provide sensible outputs. For some types of operations doing > them in premultiplied linear light RGB is superior to doing them in > sRGB, CIE Lab or other more or less perceptual spaces, for other > operations the opposite is true. My stance is that the sliders on an > operations should be predictable and always do the same thing for the > colorimetrically absolute same color - whis is why the operations of > GEGL request temporary working buffers in their preferred working > space (this is where babl does the; optimized; conversions you > correctly state have to happen) rather than blindly handling incoming > numbers. All of it seems reasonable to me :). > The RGB space defined by and used by babl uses the same > primaries as sRGB, and has well defined conversions to CIE Lab, Xyz > and others. Docs state it as “scRGB”. I don't argue about well defined conversion to absolute color coordinates (every color model have them, I should think). My only concern is about 20% of visible spectrum missing from scRGB. If operation yields a color from that absent 20% of spectrum, that color have to be “pushed” into available space. That's the obvious. What isn't is how often it happens (are some statistics available?) and how serious is that for color reproduction? If it's less than a couple of pixels then I'm calmed down :). > The preferred^Wenforced working space of some operations in GEGL might > need some scrutinization and review, though for compositing; gaussian > blurs; interpolation etc I think the current choice of linear light > RGB. > > GEGL also does not support working in an internal 8bit or 16bit mode, > it is floating point with high precision and additional > headroom/footroom (wide gamut/HDR) for all temporary buffers, if the > desired output is 8bit it happens when displayed or exported. > Operations like for instance unsharp-mask does not work correctly if > termporary results are clipped. I can only say that I back that up. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
> I really miss some basic vector functionality in Gimp. In my last > works i used Inkscape and Gimp together. Drawing sharp outlines in > Inkscape, exporting them to PNG and imported them into Gimp again, to > work with brushes and colors. Basically i used Inkscape to create > Alpha-Layers for accurate strokes. The exporting and importing was > some kind of pain. Just the ability to create basic shapes (Bezier > contours), would be a great improvement. It doesn't need to provide > anything. But it should be as simple as the Polygon-Tool and the > Node-Tool from Inkscape. That would basically all i would need. > Opening Inkscape, drawing a simple Shape (outline), exporting it, > importing it and then fill it in Gimp is not a comfortable way. Skippping back and forth from Inkscape to GIMP doesn't sound good to me either, but wasn't existing “path” tool sufficient in your case? Don't get me wrong, I'm just trying to understand the task you were up to do. My best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
> >> - vector layers and drawing geometric primitives [1] > > > > I'm not convinced of the notion of vector layers. Sure they can be > > nice addition but I fear they'll end up being quite frustrating. I > > think so because to make them as ellastic and usable as in vector > > graphics editors one'd have to double such editor in GIMP. If one > > won't do that then there's a danger of whole tool being not much > > more than a toy. I'm not generally enemy of the idea, but I've got > > my fears and doubts if it hase to be done that way. > > There are, in fact, different proposal, if you read the page. Each of > the three groups came up with a different idea. So there is not *one* > way, but actually three ways for you to have fears and doubts about > :) Oh dear! ;) > > I've got a dream about visual editing program consisting of > > different components, each taking care of one of presentation > > aspects with one underlaying rendering engine (target aware > > angine—I don't like cairo's “I don't care what's on the end” > > attitude ;)). > > It's what we, utter geeks, call a framework :) That adds +10 to "coolness" but don't let everybody know ;) > Deneba/ACD Canvas was an attempt to create such one, but it was done > on top of software started in mid 80s. Sometimes a whole week passes > when I don't wake up in cold sweat seeing it in my dreams. Funny stuff… :). But seriously, sometimes it's good for somebody to try a thing that didn't work out last time. Because of that stubborness we're able to fly by airplanes nowadays ;). I consider idea of one flexible uberapp much more sensible and appealing than implementing wee bit of “alien world” in different apps—just seems half-solution for me. Best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
> >> I could think of fully hardware accelerated rendering. Most modern > >> hardware provides accelerated rendering and many tools could be > >> speed up significantly. The CPU just doesn't scale well when it > >> comes to current image resolutions and some brush types (smooth, > >> smear, etc.). Also the performance to display multiple layers or > >> adjusting them could be much faster. > > > > I think it would be more of a wish for GEGL as the GIMP's engine of > > tomorrow ;). > > "Awww, well, come on over, baby, step into my time machine." (c) GFR buehhehehehe :D Best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
> On 03/08/2011 07:50 PM, Bogdan Szczurek wrote: > >> On Tue, Mar 8, 2011 at 3:12 PM, Bogdan > >> Szczurek wrote: > >>> I also have high hopes for GEGL, but I'd rather have it use some > >>> more abstract color model for that. I know it's not so > >>> simple—maybe even undoable–that way, but I do like the idea of > >>> color model that has complete coverage of visible spectrum. > >> > >> Using a color model with full coverage of the visual spectrum > >> would be an extension along the lines of RGB and the responses of > >> the human visual system/physics, entirely additive. > > > > Not entirely along the lines I'm afraid. First of all it strongly > > depends which RGB we're talking about. Even if we take scRGB into > > account there's still some considerable parts of visible spectrum > > that can not be described by scRGB's triad. I know scRGB is > > tempting for it's quite broad and seems easy to implement in RGB > > dominated world, but I've got a premonition that using device > > agnostic color space would pay off more. But again–I don't know > > that :). > > > If all you want is a color space that can encode all visible colors, > i.e. the entire CIEXYZ color space, RGB is fine. Transforming from > CIEXYZ to RGB (and vice versa) is a simple matrix multiplication, > where the matrix depends on the primaries and white point chosen. > It's just that sometimes the RGB components will be negative and > sometimes greater than 1.0, but each color that can be perceived by a > human can be encoded in such a boundless RGB color space. Yes, but why use RGB at all if one can use e.g. XYZ from the start? So "wide" RGB would also require greater than 8 bit depths to work satisfactorily (HSV, HSL or Lab do quite nicely even with 8 bits per component). I think one consolation is possible backward compatibility with some other RGB spaces, but isn't BC a b**ch? ;) Besides there's a trouble of defining such “new” RGB workspace: what white point should be choosen and what primaries (all have to be defined in some absolute color coordinates BTW)? Whatever space would be choosen we wouldn't escape color conversions in color managed workflow, so while I'm not RGB enemy I fail to see the reason to stick to it especially since there are “wider” color spaces that are more intuitive to work with. > If you want a color model that doesn't lose the information about the > spectral power distribution of the stimulus, then RGB won't do, but > from your reply above it doesn't sound like that is what you meant. No, I didn't, but still I think RGB “could do” since it's able to describe absolute color. Well… I don't know if my longing is good or not, or if that way is better—I'm just thinking aloud :). My best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
> On 2/13/11, LightningIsMyName wrote: > > > I'm starting this thread to list ideas for Google Summer of Code > > 2011, for the GIMP project. Since in the last year collecting ideas > > was done partially by the mailing list, let's try it again this > > year and keep most ideas here. > > In 2009 and 2010 guiguru did GIMP related usability workshops that > haven't resulted in a spec yet (the 2008 one has), but some useful > material presumably is available: > > - vector layers and drawing geometric primitives [1] I'm not convinced of the notion of vector layers. Sure they can be nice addition but I fear they'll end up being quite frustrating. I think so because to make them as ellastic and usable as in vector graphics editors one'd have to double such editor in GIMP. If one won't do that then there's a danger of whole tool being not much more than a toy. I'm not generally enemy of the idea, but I've got my fears and doubts if it hase to be done that way. I've got a dream about visual editing program consisting of different components, each taking care of one of presentation aspects with one underlaying rendering engine (target aware angine—I don't like cairo's “I don't care what's on the end” attitude ;)). Such program would load dynamically a set of editing tools if needed and only the needed. So if one's editing vector there'll be full blown toolset for that–no compromises, no implementation doubling. If one's to typeset a book, there would be loaded typesetting engine loaded with all controls available and so on. But I digress :). > - unification of selection tools (no reports from it, IIRC) > > [1] http://blog.mmiworks.net/2009_07_01_archive.html > > Could those be GSoC projects as well? At least unification of > selection tools could become a project to povide infrastructure for > gegl based selection tools (or am I missing an existing one?). I think that could do some good :). > Another idea was, IIRC, an on-canvas iWarp implementation on top of > improved gegl op implemented last GSoC for cage transform so that it > worked out of cage. I like that :). Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
> I could think of fully hardware accelerated rendering. Most modern > hardware provides accelerated rendering and many tools could be speed > up significantly. The CPU just doesn't scale well when it comes to > current image resolutions and some brush types (smooth, smear, > etc.). Also the performance to display multiple layers or adjusting > them could be much faster. I think it would be more of a wish for GEGL as the GIMP's engine of tomorrow ;). My best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
> On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurek > wrote: > >> Considering the use cases where fine grained control over the > >> resulting offset plates/actual ink used for C,M,Y,K to be a subset > >> of the more general cases where individual ink control is desired > >> (spot-colors (including metallic, glossy and other overprints) as > >> well as duo tone and more). > > I also have high hopes for GEGL, but I'd rather have it use some > > more abstract color model for that. I know it's not so simple—maybe > > even undoable–that way, but I do like the idea of color model that > > has complete coverage of visible spectrum. > > Using a color model with full coverage of the visual spectrum would be > an extension along the lines of RGB and the responses of the human > visual system/physics, entirely additive. Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But again–I don't know that :). > Spectral processing is not > similar to subtractive models like CMYK I can't agree more. > models needed for simulating > print, mixing aspects, subsurface scattering, ink interactions and > more (some of which are better indirectly modeled by ICC transforms > backed by actual test-runs). Some effects can be modelled that way (maybe even all). Other thing is if they actually are. Getting specific paper profile is most of the time undoable. Maybe something could be done in that matter? For example instead of painfully standard “color settings” dialog in preferences and “assign profile”, “convert to profile” options some new layout would work better? Maybe instead of going to a kind of “image mode” menu, we should go to “color workspace” menu with all available profiles listed there? The truth is that whenever we use color model that is unable to describe whole visible spectrum we are using some cutout of this spectrum, a working space. Giving an option to just convert image to “grayscale” or “CMYK” seems to blur that truth and IMHO tries to bury color management concept. > >> with almost enforced > >> strict working spaces for the algorithms to ensure predictability. > >> The ability to do separation to CMYK, spot colors and more with > >> associated processing on such will most easily be done as > >> abstractions implemented using a planar approach where each ink is > >> represented by a graylevel buffer. > > > > True enough, but we mustn't forget about target material > > characteristics when considering print (and soft proofing), paint > > printing order and their attributes (opacity among them too). > > All of these, like the simulation of glossiness or reflectiveness of > metallic inks are things for the final separation/composite/simulation > though - which very well can take into account both substrate and > perhaps even an animated illuminant ;) Tempting… tempting… :) > Such soft-proofing would not > be a space that GEGL itself would be doing processing in however, even > though it might have op(s) to take the individual grey level buffers > to create an RGB simulation to be shown on a display,. taking into > account the RGB profile. > > Allowing the user to configure a largeish set of predefinable inks for > separation and simulation/softproofing would possibly allow some very > nice workflows in GIMP and other softwares using GEGL. Yup! That's what I hope for too. > Implementing the capabilities of doing such workflows is something > that only can happen after GIMP itself has more naive initial support > for storing its image data in GeglBuffers of higher bit depths. So if > someone wants to play with, research and make prototypes for such a > thing it would be a nice and welcome addition. I don't think that higher bit depths are more important for transformations than for storing color samples. If image is to be displayed, most of the time it'll end up being crammed into 3 8-bit values :). If it's about to be printed most often it'll be pushed into finite (and not so big) number of possible raster point sizes. I think transformations are really the things that are to benefit most from bigger number of possible sample values. Images of course too, but not everytime. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 3:34 PM, Øyvind Kolås wrote: > On Tue, Mar 8, 2011 at 1:33 PM, Bogdan Szczurek wrote: >> have nice black background. Most of the times CMS will try to simulate >> that with all colors while it's better to use e.g. just full black and >> cyan. Another example: you need to do some trapping. Sometimes it can >> be done in RIP but you need to trust that to RIP itself and print >> house. These are only a couple of arguments, leaving aside quite >> similar cases of printing with paints different than C, M, Y and K. > > There are use cases where direct control over the separated result to > CMYK is desired, this is however the corner cases and not the generic > sense, True enough, but I'm living on "that edge" ;). > it is my impression that a lot of people are editing in CMYK > without understanding color management at all, effectively > circumventing proper color management to happen. I believe, color management is one of the most misunderstood and non-understood subjects out there generally :). > In the few cases > where you need to include text or vector elements on top (or embedded > within) an image and want to ensure a matching color with the > (adjusted) photo,. or do other things to avoid problems with > registration problems yes I see this as beneficial. To edit photos in > a device specific (or even geography specified least common > denominator CMYK profile) by default is however in my opinion not good > advice. I don't see it different. > Considering the use cases where fine grained control over the > resulting offset plates/actual ink used for C,M,Y,K to be a subset of > the more general cases where individual ink control is desired > (spot-colors (including metallic, glossy and other overprints) as well > as duo tone and more). I love that notion! I think of it similarly. Yet there's one thing in print specific color models that's notoriously neglected in color managed systems: image isn't magically put on some white (what is white exactly? ;)) universal material. Image goes through CtP (most of the time nowadays), machine and is placed on material of different characteristics. So, what is really needed for good color management is the profile of each of these stages, or at least whole process. Of course there are some "standard" profiles (e.g. FOGRA) but they all fall short when one is to use for example uncoated, dark red paper. I know, I know… egde case, yet as I said before I'm quite often on such edge :). > This the direction I have encouraged GIMP to move in on the UI level. > This distances it from color managed, photo retouching etc. In the > foreseeable future I see GEGL as primarily aiming to provide the core > to do color manipulation, processing and image processing in > colorimetrically managed (RGB) color spaces; I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum. > with almost enforced > strict working spaces for the algorithms to ensure predictability. The > ability to do separation to CMYK, spot colors and more with associated > processing on such will most easily be done as abstractions > implemented using a planar approach where each ink is represented by a > graylevel buffer. True enough, but we mustn't forget about target material characteristics when considering print (and soft proofing), paint printing order and their attributes (opacity among them too). Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 3:23 PM, Alexandre Prokoudine wrote: > On 3/8/11, Bogdan Szczurek wrote: > >>> Since we got carried away from the topic anyway, I keep hearing users >>> complaining about various bits of GIMP still not color managed, most >>> notoriously -- filter preview and sample points. The latter is sort of >>> critical to those who uses separate+ and/or CMYKTool after editing >>> things in GIMP. That makes one wonder if it will be addressed in 2.8 >>> or later. >> >> I think that we could touch here a broader problem of system wide >> color management. I think leaving color management to every single >> graphics editor separately is a no-no. > > Oh, but you don't have to do it :) GNOME Color Manager already > provides D-Bus methods to request stuff like working color space > profile. Any D-Bus enabled app (and GIMP is one) can do that. For 2.8, > however, simply fixing what's already there would be enough. I didn't know that (obviously ;)). It's nice, but I've got a hunch that such thing should be placed "lower" than DM. My ideal would be even something placed deeper than "display manager"/X.org. I'd love to e.g. make my X theme using HSV or Lab color tuples. Also, such thing could take color management and color model support entirely of off applications shoulders. > (Albeit I heard from users who deal with DTP that they actually like > advanced cms display filter: http://registry.gimp.org/node/24944) Hmmm… I'm not sure of the reason of having that. Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 2:30 PM, Alexandre Prokoudine wrote: > On 3/8/11, Bogdan Szczurek wrote: > >>> When you define a color >>> using the color chooser, I suppose you work in HSV, not RGB? >> >> In fact, most of the time I use CMYK color chooser. > > Since we got carried away from the topic anyway, I keep hearing users > complaining about various bits of GIMP still not color managed, most > notoriously -- filter preview and sample points. The latter is sort of > critical to those who uses separate+ and/or CMYKTool after editing > things in GIMP. That makes one wonder if it will be addressed in 2.8 > or later. I think that we could touch here a broader problem of system wide color management. I think leaving color management to every single graphics editor separately is a no-no. It just makes keeping color managed workflow somewhat a nightmare. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On Tue, Mar 8, 2011 at 12:28 PM, Michael Grosberg wrote: > Olivier gmail.com> writes: > >> >> >> 2011/3/8 Michael Grosberg gmail.com> >> >> Debi Rapson mansd.org> writes: >> > Can you point me in the direction of a list of places that actually use >> > GIMP for photo retouching and graphics creation. >> Hmm. GIMP is not well suited for professional photo retouching - it lack the >> necessary CMYK color model (among other things). I'm not sure what the focus >> of your program is but if you're looking for real-world use I would look more >> into video game art creation or online content. >> >> >> Could you explain why retouching photos should be made in CMYK rather than >> RGB? > > Photo retouching is usually done by print magazines. It stands to reason that > they would use tools that are able to work with CMYK. If I may interfere :). In my work I use CMYK on daily basis and I think the question "why photos should be retouched in CMYK" is not the right one to ask. One could do that but it's not the point. CMYK is not needed because it's nice to retouch images but because it provides fine control over cyan, magenta, yellow and black color components in four color professional print. One could only relay on color management in print workflow, but oftentimes it's insufficient. There are (not so rare) cases when CMS doesn't yield expected results—I mean: conversion can be done all right according to theory but in spite of that it's better to manually decide how some colors end up looking like. Sometimes one need to add or remove some "paint" from reproduction before it's going to be printed. Example: you need to have nice black background. Most of the times CMS will try to simulate that with all colors while it's better to use e.g. just full black and cyan. Another example: you need to do some trapping. Sometimes it can be done in RIP but you need to trust that to RIP itself and print house. These are only a couple of arguments, leaving aside quite similar cases of printing with paints different than C, M, Y and K. Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
> We are not speaking about the same thing. The fact that you want to change > some channels in some color model does not mean that the internal > representation of images must be based on this color model. True, it doesn't. > You need tools > for generating a proper CMYK representation of you image, suited to your > printing shop hardware, but that does not mean that the image you handle > must use this representation from the beginning. I agree, it doesn't have to, yet it is convenient to use such representation when the image is to be send to print house. > RGB is the internal representation of the images. That's untrue. > It's also a color model, I'm not sure if it's right to try to set apart "internal representation" and "color model". > not especially suitable for manipulating colors. I agree, but also it's easy to use in digital environment. > Thus you need tools that handle the image in more convenient color spaces. Meaning: tools that convert image to different color space for the time of their application. Which, by the way, can be quite tricky step. > When you define a color > using the color chooser, I suppose you work in HSV, not RGB? In fact, most of the time I use CMYK color chooser. Choice of color model often depends on your "notion" of that model. I prefer to use the same color model in my chooser that is the color model of my image. Using e.g. HSV chooser for RGB image can be deceitful since some color values can be silently changed by CMS. I prefer to use e.g. Lab for color adjustment and after I'm done with my modifications convert image to destination workspace. That way I've got full control over things that happen to my colors during conversion. Anyway, I believe we should be able to use different color models used to represent color samples stored in images not because it's "just a nice thing" but because there's one silent assumption about every color model: every color model is bound with some workspace not necessarily bijective in regard to other workspaces. Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
or better yet: Lab? ;] Anyway CMYK is neccessary too... W dniu 2011-03-08 10:08 użytkownik "Ofnuts" napisał: On 03/08/2011 08:46 AM, Olivier wrote: > > 2011/3/8 Michael Grosberg >>... Could you explain why retouching photos should be made in RGB rather than HSV/HSL :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
> Our school system appears to be headed for using GIMP as a way of > teaching our students about graphics. > > Can you point me in the direction of where I would go to get GOOD > tutorial information about GIMP so that I can properly teach it? > > Can you point me in the direction of a list of places that actually > use GIMP for photo retouching and graphics creation. We are trying to > give our kids real-world skills and we need to be able to point to > real places that are using GIMP for photo retouching and graphics > resolution. If I am going to teach using this software I need as much > ammunition as possible to make this seem exciting and something that > the kids will WANT to learn to use. If I might give a piece of advice: if you're about to teach some real-world skills, try to be as much software agnostic as possible. Most of the tools and ideas in graphics editing are in fact common and present in different applications, so if you'll put pressure on learning “the way of thinking” rather than on “go to the X menu and choose Y tool” you'll win. Maybe some examples will help clarify what I mean: • If you talk about keyboard shortcuts, try to lure your students into experimenting with them (customizing, discovering new ones etc.) instead of just listing existing shortcuts and closing the subject :). • If you talk about e.g. image tonal adjustment try to move (if possible) to using “curves” as soon as possible. It's one of the most universal tools out there and one of the most powerfull to that. • If possible, make your students do the same task, using similar tools but in different applications. This should lessen the possibility of one's sticking to one-app-way-of-doing-things (much like using strange variable names on math ;)). • If possible, don't take rundowns on the contents of menus. Instead choose consecutive exercises to be practical, to use each time some new tools and to emphasize method rather than click-here-to-get-that-ism. • Be extra careful about teaching filters. One's natural tendency, I think, is to use different filters extensively and aggressively in one's works. The trick is to show your students how to use filters to enhance their images in nondestructive way. • If possible, leave some subjects unsaid and let your students search their own way of getting demanded result. Only after they're done show them (again: if possible and most of the time possible it is) a couple of different solutions (won't leave your student with “I did it wrong way” feeling). Also, try to survey your students about their ways of completing the task–they can be interesting and non-standard. • Always try to explain, in comparative manner, why this or that tool or filter was used, e.g.: “it's faster to use X”, “it's safer to use X” and so on. • Encourage your students to use internet to find tutorials and solutions. Well… sorry for such a long list. I work for a small publishing house and I'm using most of these tips when I'm to take care of some interns (which happens once in a couple of months). I put these points here only because I truly hope they'll be of help to you, so please, don't take me as a pompous prick ;), even 'though they may sound “ex cathedra”. My best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
> >> ... elision by patrick... > > How about having (hideable of course :)) on-canvas infos? IMHO that > > would be even fancier. Infos could be aligned with control that > > modifies them. Numerical input could be done similarly on-canvas. I > > think hovering pointer above e.g. rotation control and clicking > > middle button (?) could activate input (displayed on the place). > > That way we'd save considerable ammount of mouse movement between > > canvas and dock. To make things even more unobtrusive input could > > “slide” after activation to some place on the screen (bottom of the > > screen) util value would be entered and whole control could be > > hidden. Well… there's the thing about this being fast, but I think > > that's what new, fancy compositioning infrastructures are for ;>. > > It seems to me like a reasonable application of new capabilities. > I would prefer the dock-able thing. Working with my tablet, touching > on the side instead of on the drawing is a negligible movement. I > also prefer things not be mapped to middle mouse buttons because most > mice don't have them (and tablets neither) and though a simultaneous > click of right and left are often mapped to a middle mouse click, it > isn't always reliable. You certainly wouldn't want (IMHO) to make > this something that someone would have to do to use the tool. Yup… That's why I said “hideable” and used “(?)” after middle button (used also quite often for panning) :). As for the first: I prefer the idea of on-canvas because it means the least ammount of movement (hence fastest work)–be it stylus or mouse. Of course I'm not trying to force you into my way of working :), but I'd like to avoid “hunting” with pointer for appropriate control as much as possible. If the control is right under pointer… you don't need to seek it on the screen *at all*. As for the second: middle button is here just as an “e.g.” :). Equally good it could be some set of modifier keys or sumthin' ;). Anyway, I think it would be best to choose something sane for default but leave final decision about it to the user choice in the end. Best regards! thebodzio PS. I believe that most mice have the middle button nowadays, but that's just a little digression… signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
> Users who have a comment on the list should raise it now. The ideas > list was divided in to two parts, as discussed on IRC. > Developers who wish to make small corrections should feel free to do > so, but please do not move projects between the lists / add/remove > projects or do any other major change without a discussion first. Great to have such list! :) I've got a word about slicing tools. I think it would be even nicer if slices as that: --- | - | | | | | | - | --- didn't have to be considered as nested. If they'd be treated as independent entities it would be easy to have e.g.: - | | --+---+-- | | | | | - | | | - Each slice could have, as one of properties, list of layers brought into account when generating final slice image. That way one would be able to easily “cut” some slice for background, even if the background is overlayed with some content. Furthermore, slices could have been able to create “stacks” of graphics exported as one image. I mean a situation when “idle” for of menu is on one layer, “hover” on another and finally “clicked” on third. So: one slice is created, “stack” for that slice is defined in such a way that first layer is topmost part of exported graphics, second layer is the middle and so on. It would give from single slice final image of: --- |idle | +-+ |hover| +-+ | clicked | --- Vertical alignment is choosen purely for the example's sake. Heck! One could even make some tool to visually place such images from different slices. Details remain to be discussed :). I think that gain from such solution is great. This way one could easily create not only menus but also sets of icons cropped from source image with css. And to do it without creating another image or layer on page layout project with icons packed accordingly, but “cut” them directly from layout. Elements could be then placed only once, so possibility of making a mistake while exporting them would lower considerably. That's just a couple of simple things that “traditional” slices make somewhat horrid to achieve :). I'd love to see something like that in GIMP! :D Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
> > I'm a little uneasy at the moment about the "ban working with > > numbers for transformations" comment. > > It would be nice (IMO) to have a dockable that displays the "numbers" > of the transform tool's current selection and transform, and also > applies numerical input to the transform tool. > > Photographers could ignore/hide the dockable entirely and still use > the transform tool by "feeling", and designers would have a method for > performing precise transforms (for example a radial design needing > several exact rotations). How about having (hideable of course :)) on-canvas infos? IMHO that would be even fancier. Infos could be aligned with control that modifies them. Numerical input could be done similarly on-canvas. I think hovering pointer above e.g. rotation control and clicking middle button (?) could activate input (displayed on the place). That way we'd save considerable ammount of mouse movement between canvas and dock. To make things even more unobtrusive input could “slide” after activation to some place on the screen (bottom of the screen) util value would be entered and whole control could be hidden. Well… there's the thing about this being fast, but I think that's what new, fancy compositioning infrastructures are for ;>. It seems to me like a reasonable application of new capabilities. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pencil Tool
> But of course under the hood it's the same paint core with just one > setting changed. But that is true for more tools. Paint tools, as the > user sees them, are solely a user interface thing. They represent a > certain bunch of properties set on the paint core. We could of course > expose all these properties to the user and doing so would allow us to > merge some tools. But actually I think it would be much better if we > would offer more presets to choose from. Instead of merging Pencil and > Paintbrush we should rather offer more variants like a "Soft Pencil" > that works more like what Liam expects, a "Hard Pencil" for > pixel-pefect icon retouching, a "Crayon", ... It makes me think that maybe it would be good to offer such presets, agrred, but only if there's a way for user to define custom toolsets. So, instead of one fixed palette for everyone, we would have a flexible one. You want to draw or digipaint with GIMP? Fine! Have your own set of brushes for that. Possibly even with some colors preassigned. You want to retouch a photo? Okee! Have your set of smudges, patches, stamps, whatever rows your boat :). Anyway _your_ set of tools for _specific_ need, without a clutter of tools that you'll never use for your task. Maybe it all could be bound in one “perspective”, “workspace” or whatever-to-be-called that could be easily interchangeable between users (e.g. as a sinle file). This, I think, would give us one GIMP core with multitude of faces. Heck! Maybe even GIMP as raw photo editor for that matter ;). Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pencil Tool
> I've begun working on GIMP documentation so GIMP is on my mind a lot > lately. So, I have a suggestion - remove the pencil tool, and > instead, add a checkbox to the brush tool with an "antialiased" > label. I'd go even further with that: make “antialiased” one of specific brush settings, not the “tool” itself. That way one would be able to have as much “pencils” predefined as one sees fit. And all that without touching tool tickbox back and forth if needed. BTW. Is it possible to assign shortcut to a brush type or tool preset? Without it presets are only half-usable IMHO. > My reasoning is that for a new user, the difference between > "brush" and "pencil" is not evident from their name or icon. They do > pretty much the same thing with they only difference being that > pencil is not antialiased. The pencil tool is nothing like an actual > pencil. So, if we want the UI to reflect the actual workings of the > program, it makes sense to do this. I agree with that. After all, both these tools are made to scribble on the canvas with some shapes :). > The only objection I can think of is if in real-life situation people > actually use the pencil tool in conjunction with the brush tool in > such a way that they have a separate settings for each, and the > change from one to other a lot. But that is what tool presets are for. Not a problem, I think, as far as presets are accessible through shortcuts. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
> > And let me throw in another thing. It's been in my head for some > > time but now I think it's good to show it to the world. Just in the > > matter of shear curiosity: I'd like to see some conceptual > > work/code/working example/whatever about automatically configurable > > grid processing. It may be more of GEGL project than GIMP one, but > > I believe still beneficial in the end. Since 3D rendering engines > > do that, maybe it would work nice in 2D world too. Of course a > > metric and some kind of benchmark would be needed to decide if > > sending some part of work over network to another node is > > beneficial. Anyway I think it have chances to make things snappy > > even on slow machines. I see it as a something between freakin' fat > > workstations, thin clients with some heavy “mother goose” and > > mighty cluster. It would (hopefully ;)) help to use what is at hand > > more optimally. > > GEGL is designed to be able to split up the rendering requests from > the public part of it's API internally and to distribute it among > threads/processes/hosts without needing changes to the application > using GEGL. At the moment there is only experimental support for using > threads in this fashion, but the architecture has been made with > distributed processing in mind. This also applies to the GeglBuffers > for which there a few years ago already was done experiments with > doing multi process/user concurrent manipulation of the same buffers. All of which makes a great opportunity to go from “some experiments” to “actual application” :). Agreed such project would fit GEGL better but some GUI to control GEGL behaviour in that matter would be required nevertheless. Besides… design with delegating processing to multiple threads in mind is one thing and “making it just work” over net is another. That's why I think some (at least conceptual) work is needed to make such thing automatically configurable (avahi shouting about such service available maybe, some metric to decide if letting a node to take part of work is beneficial). Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
Great thing to bring this up! > Implement the free transform tool > > For exact specifications, see: > http://gui.gimp.org/index.php/Transformation_tool_specification Oh yeah, thumbs up for that! :) > Replace the GimpSizeEntry widget > > Right now both the code and the UI is a mess. The unit should for > example be in the text entry itself instead of in a combo box How about a new type of widget “SizeArea” or somethin' that would remeber value along with entered measurement unit? I know this is a long shot and thing more feasible in vector editing app but still I've been in a couple of situations when I'd love to have such thing. Currently all I can have is widgets that get value and mercilessly convert it to default units no matter what. I think it would be cute if such widget could hold equation leading to some answer e.g. “2 * .25 in + 6 in”. It would display then “6.5 in” but it would allow to correct equation if clicked upon. “.25” could be for example bleeds. > Slicing tool > > One of the most requested features by web designers and/or interface > designers, is the addition of a slice tool. Currently slicing images > inside GIMP can only be done in grids (using guides and the guillotine > action) and you can't split just one rectangle in the middle. > > For example, the following slice can not be achieved: > > --- > ||| > ||| > ||| > ||| > -|| > ||| > --- Am I the only one who feels that current notion of slices is well… a bit retarded? I'm often in a position when I've got to make slices that are overlapping or take only some selected layers into account when producing output images. In such cases slices like shown and widely implemented are nothing short of being useless. Agreed: the slices type presented make producing “WYSIWYG” sites easy but I don't think they're much use for HTML writers. So, long story short I propose making slices that could look something like that: - | --- | | | | | | | | | | | | --- | | | | | - The biggest would be e.g. background, next (in the terms of size) would be menu and the smallest would be some icon. And let me throw in another thing. It's been in my head for some time but now I think it's good to show it to the world. Just in the matter of shear curiosity: I'd like to see some conceptual work/code/working example/whatever about automatically configurable grid processing. It may be more of GEGL project than GIMP one, but I believe still beneficial in the end. Since 3D rendering engines do that, maybe it would work nice in 2D world too. Of course a metric and some kind of benchmark would be needed to decide if sending some part of work over network to another node is beneficial. Anyway I think it have chances to make things snappy even on slow machines. I see it as a something between freakin' fat workstations, thin clients with some heavy “mother goose” and mighty cluster. It would (hopefully ;)) help to use what is at hand more optimally. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Square brushes
> And hi one more time! > > Couldn't we have a square (and square fuzzy) brush by default on Gimp > or it's out of the scope/vision/something else of the product? I think that solid, one-color, vector-based brushes would be even better to have. They would make square, round, oval and you-name-it brushes just a subset of possibilities. All that by implementing one infrastructure :) — the rest would be defining brush shape. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
> On 2/2/11, Bogdan Szczurek wrote: > > > different after all. Please don't be mad at me for saying that for I > > don't intend to offend anybody. > > Nobody's mad at you :) And I said that to be sure that nobody will be :). > I see where you are coming from, I even spent > some time in the past providing this kind of solutions for e.g. > Inkscape users (http://bit.ly/i2HJeR), but you see, the whole topic is > really about near-term outlook vs. long-term outlook. I guess it is after all… > Providing an easy way to switch to Ps shortcuts scheme is a near-term > solution, i.e. useful for people who just need GIMP once or twice in > their life after having used Ps for a decade or so. For people who > want to switch from Ps to GIMP this near-term solution will do a > terrible job: they will never get full mapping of keys (believe me, I > know what I'm saying), they won't be motivated enough to move to > native shortcuts, and they will find it difficult to follow all kinds > of documentation. Frankly I didn't expect such oposition agains idea of switchable shortcut “profiles”. Since shortcuts are modifiable anyway then why shoudn't they be changable en masse with profiles? – were my thoughts. I guess my mistake was to bring Ps case in ;). > (I'm not even saying how introducing this switch will motivate > everyone to ask the team to provide Ps-like menus using the very same > reasoning.) Possibly… but dropping Ps out of the thing, I still like the idea of “accelerator themes”. Yet I totaly respect people's opinion on that matter. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
> Furthermore, collaborating with Inkscape *instead* makes a lot of > sense, because GIMP + Inkscape are a usual combo. Blindly reusing > shortcuts from old Adobe products doesn't make a lot of sense. Blindly—yes. But proposition is not to do it that way. My reason is: I want to promote GIMP to e.g. my collegues who are used to using Ps. Most of their work is doing some corrections and while doing so they rarely use anything else than the pointer and keyboard shortcuts. If they want to try new app they'd like to hit the usual key to get to usual tool. Not getting it leaves them simply frustrated. I hope to lessen the frustration by offering them shortcuts they know. I can do that by telling them to seek some file and change it with the one I've provided or by asking project leaders and comunity what do they think about having “shortcut switch” and option to use Ps-accels by default. Then I'd be able to tell my friends: “Just go to preferences and choose Ps shortcuts”. This solution appears harder to get but easier to use when provided. > I'd > have to look at Ps again to make sure nothing changed, but Illustrator > carries around somewhat inconsistent shortcuts exactly because old > habits die hard. I'd say that the idea of reusing shortcuts from an > application where they had been stacked on top of each other over > years without review is a bit on the crazy side. > > The very same "many people" who don't care about GNOME want GIMP to be > a drop-in Photoshop replacement. I do honestly care about them both. > Needless to say, this is not the > point why GIMP exists and is being worked on. One would have to lose > all self-respect and joy of life to work on a free drop-in replacement > for *any* software project. Yet GIMP is often compared to Ps and I think not only due to the fact that both are raster graphic editors. I think that now they share too many ideas about graphics editing to avoid being compared any other way than tool for tool. There are voices in this conversation about having GIMP a quite different tool than any other, but I'm afraid it's not so different after all. Please don't be mad at me for saying that for I don't intend to offend anybody. I just see it that way. If somebody would be willing to kindly prove me wrong, I'd be happy to talk it over on another thread :) (it could be beneficial to enumerating GIMP distinct features and workflow ideas e.g. as a part of wiki). Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
> On Jan 30, 2011, at 12:12 PM, Liam R E Quin wrote: > > > On Sun, 2011-01-30 at 01:43 +0100, Bogdan Szczurek wrote: > > > >> The thing is, that we concluded that permamenet transition or even > >> occasional use of Gimp would be much more appealing for Ps-bred > >> guys (like me ;)) if one would have possibility to use the same > >> (or at least much similar) keyboard shortcuts. > > > > There's some danger here -- as people in Germany found when they > > compared moving to KDE or Gnome from Windows: when the new system > > is too similar to the old, people start going into automatic mode, > > and trip up much more over the differences. > > > This came up at linux.conf.au this week. I had a chance to talk with > a couple of users and graphic designers about UI, including the issue > of being made similar to Adobe products. The almost immediate > response was that if the program is not going to behave *exactly* as > the Adobe one does, in smallest detail, then it is far better to have > an explicitly distinct UI. Yes, _if_ the program _is_not_going_to_behave_exactly. But there's much convergence here. Most paradigms and ideas are the same. I dare to say in many cases shortcut is what differs most. Anyway, I didn't suggest to change _default_ shortcuts but to enable one to choose between a couple sets of them _by_ default. I'd like to see some _real_ innovation in GIMP (like “display filters” or quite novel GUI) but by this thread I'm trying to refer to here and now. Since I'm a graphic designer I'm trying to pull things towards my side to have the tool I'd really like to use. Forgive the blasphemy, but maybe it would be nice to try to build new tool from the scratch instead of evolving the old one (please don't tell me that I can “fork off” ;)—I really don't mean to offend anybody, most honestly). Thinking about the problem from “point zero” could help to throw away old habits and ways of thinking. I remeber one time some attempt to revolutionize GIMP's GUI but the changes, if brought, haven't been of such great magnitude as I expected. > Being "close" just leaves the end user with a vague feeling of > incompleteness and that the software is not really ready for serious > use. I agree, but also I think that similar shortcuts would help to lessen such feeling. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
> And all this conversation is because you think CTRL+Backspace makes > more sense than CTRL+. (because you're used to that combination) and > you don't want to take 30 seconds of your time to personalize the > accelerators? > Seriously? If think so then I'm afraid that you didn't read my posts carefully or misinterpreted them. Yes, I'm used to some combinations and I fail to see the reason why should I change my customs. I doubt the new ones would improve my speed or any other quality. I sure can replace default shortcut set with the other quite easily but not everyone would if it had to be done by seeking the right file and placing another in its stead. My poll is tiny (2 persons beside myself) but at least it is real. So 3 graphic developers says: we'd like to have it, how about you? That's all. Not we demand, we require, but we'd like to. I've stated the reasoning behind my suggestion a couple of times and right now I can't think of other arguments “for”. > GIMP accelerators are customizable using a visible option from the > Edit menu, and you can even choose to assign accelerators dinamically > from the preferences. > The menurc file in the prefs folder has the list of accelerators. You > could create a custom version with the combinations you want (or > google for it, just to find that someone already did it). That's true, but also it is _not_ the point of the whole conversation to state it. > A couple of days ago a voluntary coder (with an impressive CV) arrived > to this list offering his help and he only got a couple of replies. My proposition, if applauded, could give him one thing to help at. But even if not, I feel that threads that state the problem and propose a way of solving it are great sources of tasks for anybody who's willing to do some work. Surely one would see that if only considered things calmly. > This pointless discussion got a lot more of attention. Pointless it is if it doesn't bring any changes but that can be said only after it's over. Right now I can see that there's at least a will to at least make things clearer about the subject in documentation. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
> On Tue, Feb 1, 2011 at 5:17 PM, Michael Grosberg > wrote: > > Add a single "For Photoshop users" page to the help file. There, > > tell users how to change the menurc file so they have > > photoshop-like keys. This won't change the application in any way, > > and will enable those who insist on it to have photoshop key > > bindings. I can't see any downside and it's very easy to implement. > > I see no reason why this mod should be maintained in the GIMP tree. > It's an optional mod and as such, along with other PS specific > customizations should belong in a separate project, just like GPS > presets(that are valuable even on vanilla gimp, instead of the patched > one) and FX foundry. The reason is: most graphic developers I know don't like to mingle more than what can be mingled with their app GUI. Almost everytime suggestion to change some file manually is welcomed with an unpleasant grimace ;) and rather nasty feeling about proposed tool. I'd love to avoid that with GIMP while trying to promote it. That's why I suggested the whole shortcut scheme/theme thing. I did it even more so because in fact GIMP is halfway there with configurable shortcuts. What I'd love to have is being able to change all of them with one switch. In my GIMP 2.7.1 there are options to save shortcuts, restore fatory defaults and clear them. I'd like to be able to change them not only to Ps-like but also to ones custom defined suitable for cleaning some scans while preparing reedition of a book or while retouching some photos. I don't like to do that by exchanging config file every time I need to make a general change or by hunting down proper actions in menus or shortcut editor. That's all :). Maybe all this conversation would turn other way if I didn't use the dreaded Ps banner ;). Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
> On Tue, 2011-02-01 at 17:16 +, Michael Grosberg wrote: > > Alexandre Prokoudine gmail.com> writes: > > > > > *sigh* > > > > > > http://git.gnome.org/browse/gimp/tree/etc/ps-menurc > > > > > > Alexandre Prokoudine > > > http://libregraphicsworld.org > > > > > > > I will refrain from expressing my opinion on undocumented, > > undiscoverable features. > > This is documented in the user manual even: > http://docs.gimp.org/en/gimp-introduction-history-2-0.html > > I am sure the gimp-docs team will appreciate a patch that moves this > information to a better place though. It's somewhat difficult to > locate it in the list of changes for GIMP 2.0. I'd welcomed this as an improvement. Not exactly as convenient as I hoped but still. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
> As it was stated before, making applications act "similar" doesn't > turn out in "familiarity", but in a percepction of incompleteness. The > most our applications looks like others, the most former users of > other applications will spot what's missing, perceiving differences as > limitations. > When I switched from GIMP after almost 15 years of Photoshop the first > reaction was the same. I wanted GIMP to behave like photoshop, because > I considered Photoshop's the right way of doing things. > Now I'm glad it didn't work that way, because it forced me to > understand that I was using a different program. My experience in that matter is that my workflow is _unchanged_ wheather I use GIMP or Ps. I use curves in the same places, quick mask and mask in general too, brush, stamp, healing… the list goes on. I love the idea of “display filters” that I use when working on bitmaps with GIMP but I fail to see more such grounbreaking features like that. The paradigm of raster graphics editing stays pretty much the same. I think that most of the work towards the shortcut scheme switcher is already done. What is missing it seems to be the final step—small but completing the whole thing as “being convenient”. I like to think about this list as a place of meeting both developers and users. I'm a graphic designer with not enough time to do crucial coding, but enough time to try to improve GIMP with a simple suggestion: shortcut “theme” switcher and within it Ps “compatible” shortcuts as an option, how about that? I don't think it's much in the sense of coding, but it is much if you're trying to convince somebody to use GIMP. Why? Maybe in time the'll contribute their own ideas as well—as long as they'd be willing to use GIMP in their everyday work. I think that similar shortcuts will help to promote GIMP to them. I _DO_ appreciate the developers work, admire it in fact because it's selfless, but still I think both devs and designers should work together. I'm telling what I'd like to have, trying to reason it the best I can. If I fail to convince the others to my ideas then, well… no problem at all :)—that's the right of democracy, which I respect. > In the future I'd love to see even more differences. > Who knows, maybe a node UI instead of layers, for instance ;-) > Moving in that direction, imho, would stop this endless and pointless > flamewar about GIMP vs. Photoshop, and people who moves to GIMP would > be doing an informed choice instead of seeking a free-of-charge > Photoshop. I'd love to have them too! But _real_ differences, not the ones made only for differing's sake :). Node editing could be promising. Especially if used nodes could be grouped as larger blocks for further use. That would work somewhat like “recoded actions” but much more powerful. But that's the subject for yet another thread… ;). Best regards! thebodzio PS. Sorry if somebody felt my unleashing all this a bit trolly ;) but one have to try to improve what one likes, even if the process is about to be painful. signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop ?compatibility? mode
> On 02/01/2011 06:25 PM, Alexandre Prokoudine wrote: > > On Tue, Feb 1, 2011 at 8:16 PM, Michael Grosberg wrote: > > > >> I will refrain from expressing my opinion on undocumented, > >> undiscoverable features. > >> Now only a help page is needed. I think I'll go and join the > >> Gimp-Docs mailing list and take it from there. This is an area in > >> which I have a lot of experience (I've been documenting graphic > >> apps for several years now). > > So far it looks like the best outcome of the thread :) Thank you. > Let's remove one stroke from the name of the program. > > Let's call it GINP. > > GINP Is Not Photoshop. Nobody says it is or it ought to be. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
Actually, I intended this thread to be about “Photoshop «compatibility» mode” (quotation marks to emphasize that I meant only particular kind of compatibility :)). I'm afraid the conversation went a bit off-topic since I didn't suggested changes in _default_ shortcuts scheme for GIMP. What I suggested was _possibility_ to easily choose, via GUI, among some predefined shortcut sets. > I am also not suggesting blindly following "old Adobe products". > However, it is equally a mistake to blindly follow "old GIMP products" > when it's clear the rest of the world is moving to another set of > default keybindings. The crux of my argument is simply that - > regardless of what we've become used to - it is beneficial to all > users - existing and future - to monitor default keybindings across > peer applications and mimic each other where appropriate. I agree. If GIMP would have simple shortcut switcher, whole problem of “what should be default” could be marginalized, because the keyboard control “profile” will be so trivial to change that it wouldn't matter “what's default” anymore. At least it woudn't matter so much. > I do like the page Alexandre put together on the Create wiki, but I do > not like that closed-source applications appear to have been excluded. > I don't want to diverge into a Free Software "Purity" versus Open > Source "Practicality" debate but closed source applications are an > important part of the software ecosystem -- if for no other reason > than we're trying to provide a better alternative to them. And > "better alternative" in no way, shape, or form means "clone". I think that word “better” is very important here. “Better” does not mean “different at all costs”. If “curves” paradigm works nicely then we're not trying to replace it with something else just for the change's sake. I think shortcuts are similar in that matter. If Ps shortcuts are much used in practice and tutorials then why not give a chance to have them mimicked as an option? Again, I know it is possible right now to have Ps-like behaving GIMP but the way to achieving it isn't so much appealing to a graphic designer. Believe me I've heard some words of frustration from a couple of persons. So the question is not “if” it is possible but “how hard” it is to be done. I propose to make it simpler for the sake of less-technical userbase (which would be “a lot” among graphic designers). > However, if an application is intended to be cross-platform, it should > conform to the conventions of that platform. Very broadly, that means > on MacOS it should do the weird titlebar thing by default; it would do > single window mode on Windows; Ok/Cancel conventions would match the > platform; and as there really aren't that many expectations of what a > *nix system looks like, it can pretty much be whatever - but should > follow the GNOME HIG on GNOME and the KDE HIG on KDE ... ideally. And > these HIGs should not have sections called anything like "Keyboard > shortcuts for raster image editors". Here shortcut scheme switcher would be much appreciated. It could choose proper defaults on the first run, but also allow to change the whole set of them on the fly. Interesting is that Adobe apps have shortcut switcher which is a blessing to use in situations when I have to change the seats with one of my collegues. He uses quite queer shortcuts so to work as fast as usual and not to swear frequently I revert back to default shortcuts. When my work is done I set his own shortcuts and it's as simple as that. Anyway… such thing is _convenient_. And not such a revolution too. Simply: I vote to have shortcut set switcher in GIMP and apart from GIMP's own shortcuts a scheme that mimicks Ps' “in the same package”. Best regards and thanks for upholding the discussion! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Photoshop “compatibility” mode
Hi! > > Lately I've been discussing with a collegue of mine some differences > > between Gimp and Photoshop and how long-time Ps user feel when > > seated in front of Gimp. I know… I know… the neverending subject, > > but I'm not trying to start the flame again, > > Do you genuinely expect us to believe it? :))) Since it being the truth… yup :) (but I'm glad it made you smile :)) > > So, how about a small extension to GUI to let one choose one of > > predefined shortcut sets and including “Photoshop compatible” > > shortcuts to the source tree? I know many people would be much > > pleased with that, since a seasoned Ps user tend to rather “just > > poke the right key” to do his bidding that to wander through the > > menu. I'm not trying to prove one shortcut scheme better than the > > other. > > > > Now seriously… what do you think? > > Being the utter bastard who updated the Photoshop mocking keyboard > scheme file a while ago to match CS4 shortcuts I can only say that I'm > terribly sorry about having done it. A wicked doing indeed… ;) Anyway, I'm not trying to discuss if such scheme should be made (it is and will be done regardles of one's views) but if it is a good thing to have such a scheme budled with standard GIMP release. > Here is my reasoning. > > Shortcuts are integral part of the whole thing that shapes habits of > users, especially the motor function. If you keep a bug chunk of > interaction from one application and replace one of its integral parts > with a bit from a different application with different approach to > user interfaces, you get a monster of a very nearly tentacular nature. > > By adding the scheme switch you advertize this monster (well, a > halfhearted measure at best). As we use to say in Uberwald, if you > don't want a monster, you don't pull a lever :) I see possibiliy of choosing right away between different predefined shortcut sets as an extension of the idea of user defined accelerators. In the end if one allows users to create their own shortcuts then one's giving them the aformentioned lever anyhow. The only difference is how convenient it is in use ;). The thing that I can't agree upon is what it releases ;). > P.S. So, should I go ahead and update it again to match CS5? :) I'd love to have it! :) Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Photoshop “compatibility” mode
Hi! Lately I've been discussing with a collegue of mine some differences between Gimp and Photoshop and how long-time Ps user feel when seated in front of Gimp. I know… I know… the neverending subject, but I'm not trying to start the flame again, so… please keep your matches and petrol away ;) — I'm geuinely interested what you think. The thing is, that we concluded that permamenet transition or even occasional use of Gimp would be much more appealing for Ps-bred guys (like me ;)) if one would have possibility to use the same (or at least much similar) keyboard shortcuts. I know—there are a couple of ready “configs” to be placed in Gimp's config dirs, but that's the part of the problem. There's significant number of people among graphic designers for whom navigating somewhere in directory structure to change this or that file would be too much to ask. I'm saying that NOT to laugh at them—they're skilled and tallented designers I'm sure, but let's face the fact. So, how about a small extension to GUI to let one choose one of predefined shortcut sets and including “Photoshop compatible” shortcuts to the source tree? I know many people would be much pleased with that, since a seasoned Ps user tend to rather “just poke the right key” to do his bidding that to wander through the menu. I'm not trying to prove one shortcut scheme better than the other. Now seriously… what do you think? Regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Megapixels counter
> I can certainly see that showing size in megapixels can be useful for > our target user base. We're even lucky enough to have the prefect char > 'M' free for it. So I have pushed a cleaned up version of your patch > (that only uses 1 decimal) to git master: That's great news! Thanks for accepting and modifying my patch! Regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Megapixels counter
> > There's a small thing that I missed in GIMP for some time. That > > thing is a megapixel counter to add to window title or status. > > Hi! > > IMO we need to make it easier than editing a complex format-string to > get this info in the window title. Well… I haven't thought of that, to be frank, since I'm comfy with the current state of things :). Also, I just wanted to fill the gap that was important for me. > But that's a different project... > > Are you sure it is best to divide with 100 and not 1024*1024? Yes, I'm sure. Megapixel is decimal unit so 10e6 is right. As an afterthought I would change presentation from 2 to 1 decimal places. I don't think there's much use of having such precise measurement as 1/100 of MP. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Megapixels counter
Hi!
There's a small thing that I missed in GIMP for some time. That thing
is a megapixel counter to add to window title or status. It's quite
useful for considering if image can be used as a stock graphics,
since most stocks constrain acceptable image sizes by Mp value. If
somebody thinks the same as me that this is worth including here's a
micro-patch:
--- gimp/app/display/gimpdisplayshell-title.c.old 2010-09-27
01:37:29.040691516 +0200 +++
gimp/app/display/gimpdisplayshell-title.c 2010-09-27
01:35:02.591824852 +0200 @@ -322,6 +322,15 @@ }
break;
+case 'M': /* image size in megapixels */
+ {
+i += print (title, title_len, i, "%.2f",
+(gfloat) (gimp_image_get_width (image)
+ * gimp_image_get_height (image))
+ / 100);
+ }
+ break;
+
case 'l': /* number of layers */
i += print (title, title_len, i, "%d",
gimp_image_get_n_layers (image));
thebodzio
signature.asc
Description: PGP signature
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
