Re: [Gimp-developer] A letter of complaint
It would also be helpful to know the individual's tendencies towards usage of development versions during their difficulties. A dev version would certainly be a strong candidate for crashes and should never be expected to perform properly in a production environment. On another note: I can look back fondly at all the times I lost work in Photo$hop. Frequent saves were usually my only saving grace. Except of course when PS would crash during the save. Then all was lost. Effort had to be put into version saving as a work-around. At the time, I really had nobody to blame but myself since Adobe clearly stated that saving across a network was not supported behavior. Back then, Apple's PowerPC's were the norm, 1gig drives were about as big as they came and the files we were working were 314res (8000) ppi for 8x10 LVT film-recorder output on transparency and negative films. External drives were slw, too small for the files we were working. We needed every bit of free scratch disk to work the files, so saving them locally was not an option. Even with the potential for crashes and corrupted scan lines, saving to the network was a risk we felt we had to take. The learning experience brought realizations that bad things happen that are not within our control. What we could control is how we responded to the situation, what we did to work around the potential for the issue to happen again, and the use of careful note taking so that proper bug reports could be submitted to Adobe when appropriate. After all, devs can't fix a problem they are not aware of. Much like complaining about a three month old pothole on your street. It's not like the transportation department has some magic fairy that automatically tells them when a pot hole appears! Step up, make a polite phone call and the work will get done. Have an issue? Report it Bug won't go away? work around it. Don't like the way something works? Find something else that does. Taking responsibility for my own stubbornness, lack of follow through and the results they create has removed more stress in my life than just about anything else. When I stopped blaming others for the pain in my life I could have done something about, my life change immensely towards the positive. IMO the OP is acting as if they are the victim of the developers and their code. When someone plays the role of the victim, they surrender the power to change their situation. It's OK to stand in the pile of poo you were reluctant to get out of, but please don't splash any on the rest of us. On 07/23/2012 11:15 AM, Akira Tanaka wrote: To all the developers of GIMP software... In the five years that I've used your program for my own creative purposes, I've dealt with some of the good aspects of GIMP and the negative aspects of it as well. The variety in brushes was good and the option to create animated GIFs with ease is a nice addition as well. However, there have been many negative aspects that have given me so much grief with this program. I've dealt with the instability of tablet devices being added on to my computer when I use GIMP. The times that GIMP has crashed and so many irretrievable hours of work lost only fueled my rage against this program. But after accessing an already usable file only to get an error message that doesn't make any sense, that was it. That was the straw that broke the camel's back. After five years of putting up with this mediocre excuse for a software, it's time for me to hold my hands high and say enough is enough. I feel like I've been put through something and this is the breaking point. A software that crashes on you and then has the audacity to refuse a direct order makes for a truly negative experience. This is it. I've had it. I will never use GIMP software again for as long as I live. I know you have some sort of bureaucracy set up to review letters from anonymous users. There is a chance you will reject this letter but if that's the case, I'm willing to give you these parting words. GIMP is, without a doubt, the most unreliable, poorly programmed, pathetic excuse for a software program ever conceived by a human being. That is all. If you took the time to read this, you have my thanks. If you just carelessly rejected this without even looking into the letter, you can all go fuck yourselves. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Update and apology
I am not intimately familiar with all the compression modes that the plugin supports, but I'll give a stab at a possible cause. The P$D file format provides support for several compression types in it's PSD format. LSW(native), JPG, RLE, plus image pyramid options. It might be possible that during the export from SAI, one of these options was included. I attempted to download SAI to test it on my end (from sai.detstwo.c*m http://sai.detstwo.com/), but my ClamAV shows the install file as infected. I would be willing to give it a go if someone can point me to a clean download. Sorry I can't test the theory on this end just yet, but I do hope the idea helps. On 07/24/2012 10:33 AM, Akira Tanaka wrote: Yesterday, I wrote a letter out of frustration in regards to GIMP. I feel that my actions were juvenile, immature and socially unacceptable. I haven't bothered to update the software and in a fit of misguided and dumb rage, I unleashed that attack against those who did not deserve it. I'm not a victim, I just made a foolish mistake out of anger. And for that I apologize. I meant no disrespect to any of you and I'm pretty sure I'd give GIMP another chance with its newest version. So please disregard everything that was said in a letter of complaint. Anywho, here's the problem that I faced with GIMP yesterday. There is a PSD file converted from SAI that I tried opening with GIMP. I was able to beforehand up until that morning in which an error message popped up saying unsupported compression mode. I wasn't sure why I was getting this error, because I could open up the file beforehand without penalty. I probably don't deserve any pointers after that episode from yesterday, but just thought I'd bring up what happened now that I've put things into perspective. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] the Gimp lcms.c plug-in
Elle, I am not a programmer but I am a color professional. so here is my input regarding your last question: It seems to me that you will always need ICC profiles, to convert an image from whatever ICC color space profile it happens to be in, to your internal working space, and from your internal working space to the monitor profile, and from your internal working space back out to whatever color space profile the person wants to use to upon exporting to a non-xcf file. Yes? No? always is a bit strong. Some individuals, such as myself, prefer to do as little profile swapping as possible, and in some cases work in complete native spaces during the entire flow. Display calibration excluded. I rarely take an incoming file from it's native space to some other working space unless the file needs extreme adjustments. So converting from native to working is not a given. There will be some situations where I will send the image file directly to the output device without a conversion to the output profile. An output profile should be able to be used in soft-proofing without the need for conversion to profile. The Adobe workflow refers to this as Preserve RGB. Having this option allows me and other users to proof the output on screen and never convert the file to any profile, thus keeping the working file in it's fullest integrity, free of banding, loss of color fidelity and other profile related issues that can result from remapping. There may also be times when I will maintain the files native space but print using a convert to profile flow, and there are times when I DO convert from the native space to a larger space. The latter is often the case when the file needs major adjustments for density and contrast. I may also go from a larger space, such as ProRGB or Adobe1998 down to sRGB if I am working a file that will only see usage on the web and never go to wide gamut print. Feel free to reach out to me with specific questions that might be off-topic. On 07/19/2012 11:12 AM, Elle Stone wrote: I've been working on porting the Gimp lcms.c plug-in from using LittleCMS version 1 to using LittleCMS version 2. This will make possible high bit-depth ICC profile conversions. I'm not a super-experienced c-coder, nor have I ever worked with the lcms engine before. So I'm learning as I go. So far I've: (1)compiled the existing Gimp lcms plug-in, (2)modified the existing plug-in to use lcms2.h and attempted to compile it (knowing it would fail) (3)tracked down all the errors and warnings that result from the differences between LittleCMS version 1 and LittleCMS version 2 My next steps will be to add a whole bunch of print to screen commands to the current Gimp lcms.c plug-in so I can get a better handle on the flow of the code, and then start rewriting (or perhaps writing from scratch) the plug-in to use the LittleCMS v2 engine. If anyone is curious, I've documented what I've done so far: http://ninedegreesbelow.com/temp/gimp-lcms-1.html http://ninedegreesbelow.com/temp/gimp-lcms-2.html Comments, input is more than welcome. I have a couple of big-picture questions: Will Gimp be using as its internal working space some variant of Microsoft's scRGB? What about: Wikipedia: http://en.wikipedia.org/wiki/Scrgb scRGB is a wide color gamut RGB (Red Green Blue) color space created by Microsoft and HP that uses the same color primaries and white/black points as the sRGB color space but allows coordinates below zero and greater than one. . . . the cost of maintaining compatibility with sRGB is that approximately 80% of the scRGB color space consists of imaginary colors. Two encodings are defined for the individual primaries: a linear 16 bit per channel encoding and a nonlinear 12 bit per channel encoding. . . The 16 bit scRGB(16) encoding is the linear RGB channels converted by 8192 x + 4096. Compared to 8-bit sRGB this ranges from about 1/2 the color resolution near 0.0 to more than 10 times the color resolution near 1.0. That last sentence is a bit worrisome - losing resolution in the shadow areas. It seems to me that you will always need ICC profiles, to convert an image from whatever ICC color space profile it happens to be in, to your internal working space, and from your internal working space to the monitor profile, and from your internal working space back out to whatever color space profile the person wants to use to upon exporting to a non-xcf file. Yes? No? Elle ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 splash screen suggestion
While this is certainly true, GIMP, along with PS and others like them, fall into a class called Paint Programs. This may have been the artist's inspiration. On 04/17/2012 05:23 PM, Kevin Cozens wrote: On 12-04-17 05:38 PM, gespert...@gmail.com wrote: After some tweaking... http://dl.dropbox.com/u/255376/gimp/gimp-splash_gez-V3.png If a person was to get picky they could point out that GIMP has more than paint brushes in its toolbox. ;-) Looks good. Nice and colourful. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp 2.8 splash screen suggestion
Is it OK if I chime in? Yes the diagonal lines behind Wilber and across the largest brush are distracting, but I LOVE the overall concept. It's fresh, clean, professional and colorful. The use of a bokeh layer is fantastic and well executed. The new layer order is much better and shows Wilber properly. The first thing my eye goes to is the 2.8. To me, it carries the same visual weight as Wilber. I am not sure that the version number is the primary focus of a splash screen. Is there another creative element you might replace that with? While we are all celebrating this much anticipated release, the version number is not critically important. Could we completely remove the version number from the splash or at least make it much much smaller? Say 12 to 14 px high and subtle. Or, as an idea that is a bit outside the box. spell it out i.e. V e r s i o n Two Point Eight. This could still fit in the bottom of your vertical banner as your third element, yet it would minimize the visual weight. Also, the white margins on top and bottom seem unnecessary and I find them distracting, especially the bottom. It's quite a bit of empty space and appears unfinished because it carries so much visual weight yet does not serve an immediate purpose that I can see. Fantastic work so far. Perhaps Gimp's best splash to date! John H On Tue 17 Apr 2012 12:17:44 AM MDT, Martin Nordholts wrote: Den 16 april 2012 13:52 skrev Bernhard Stockmann de...@devvv.de: I've made a version with Wilber above the lines. Hope you like it more now ;) see here: https://bugzilla.gnome.org/show_bug.cgi?id=674154 I like it more, but I still think the white diagonal line is too distracting / Martin ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Text-Handling in GIMP: Vision
Just my two cents as a professional user: * Text in GIMP is always part of the composition - (unless it is an annotation) * There is no such thing as paging in gimp Agreed. Multi-page layout work is best performed by word processing apps, and advanced design using illustration apps. * Text in gimp has form and symbolic meaning, but meta levels of information in text are not supported I invite us to consider changing this paradigm. With the expanding adoption of DAM tools in the professional environment, having the text within Gimp files searchable can be a plus for the user and potentially beneficial for further adoption by professionals. * /Complete control over typography and the layout of text on the canvas/ This needs expansion. What exactly would be included in complete control? If this is referring to traditional typographic adjustments such as kearning, leading, tracking,justification, decoration etc., I believe the developers have that covered already. If you are suggesting enhanced tools, I have some ideas such as * Drop shadow adjustments o Color o Opacity o Blur levels o Blending modes * Rapid Access to character maps * Access to additional font metrics and character sets when available within the font file. * /unicode supported localisation of text tools/ This sounds like a great idea! * /text editing for ever/ This could use some clarification. Can you reword this in greater detail? super-fast workflow, when they are experienced While the existing text tool performs decently for me, speed-wise, I would like to vote up faster workflows. Sometimes though, a faster workflow just comes from a simpler interface. Having to go back and forth between the text box and the pallet is an example of where the existing system is lacking some simplicity. I also understand that at some point, a limit to the number of features added to the tool will be reached, or we are in danger of bloat, both visually and virtually. On 02/06/2012 06:56 AM, Dominique Schmidt wrote: In the process of redesigning text handling in GIMP we have come up with a vision. It draws from responses on the list and IRC discussions and has been put together by Peter, Kate and me. http://gui.gimp.org/index.php/Text-Handling_in_GIMP:_Vision Particularly asking for comments from mitch and nomis as you guys are probably the main developers for this work. thanks, dominique ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
