Re: [Gimp-developer] Some questions
Hi, Jordi Cantn [EMAIL PROTECTED] writes: How can a plugin have access to this preferences? They cannot yet. I have a suggestion. I think that it will be useful if a new folder list for ICC profiles could be also included in the preferences dialog. The default ones could be: $prefix/share/gimp/2.0/color $user/.gimp-2.3/color The original patch that I applied to HEAD did have this option but I removed it since I think we should rather use the established locations for ICC profiles that are shared between apps. I have noticed that parasites are saved/restored from file depending on the file format used. (for example in tiff they work and in jpg not). I assume that it is not a bug, but a limitation of the graphic format itself. Is this theory true? Parasites can only stored in XCF files. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: Really, you are putting words intgo my mouth that I didn't say. _Please_ stay out of this thread _or_ read my original mails where I clearly differentiated between gimp-specific issues and gtk+-specific ones. Marc, it is you who is constantly trying to change your words. As soon as you figure out that you have been wrong, you start to claim that you didn't say this or that you referred to a different subject. You did this at least twice in this very thread. Please try to acknowledge when you have been wrong. Others are doing that here as well. You will also have to apologize to Mitch or stay not only out of this thread but out of this mailing-list. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some questions
Sven Neumann wrote: How can a plugin have access to this preferences? They cannot yet. ok. The original patch that I applied to HEAD did have this option but I removed it since I think we should rather use the established locations for ICC profiles that are shared between apps. You mean /usr/share/color/icc and ~/.color/icc ? What about running Gimp on windows? I think that it could be useful if that user can add additional profiles directories to the default ones. Think about advanced users that could have a lot of specific profiles depending on the situation. I have noticed that parasites are saved/restored from file depending on the file format used. (for example in tiff they work and in jpg not). I assume that it is not a bug, but a limitation of the graphic format itself. Is this theory true? Parasites can only stored in XCF files. But I have checked that the "icc-profile" parasite can be recovered from a Tiff file, but not from a jpg file. I assume that "icc-profile" parasite can be stored in tiff, but not in jpg. Am I right? -- Jordi Cantn http://www.virtual-sub.org
[Gimp-developer] file chooser performance
Hi, a few people have claimed that opening the file chooser dialog would take a considerable amount of time if it is opened in a directory with lots of files. While I have myself observed this behaviour in the past, I haven't been able to reproduce it for a while. I have tried with GTK+-2.6.2, GIMP 2.2.3 and current CVS. The folder that I tried this with has close to 2000 image files and a couple of directories. The file-chooser dialog opened in less than a second which I think is a reasonable delay. If anyone sees this problem and updating to gtk+-2.4.14 or gtk+-2.6.2 doesn't solve it, I'd like to hear about a way to reproduce it. We would have to check whether it's a GIMP or a GTK+ problem and either take care of it or delegate the solution. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some questions
Hi, Jordi Cantn [EMAIL PROTECTED] writes: You mean /usr/share/color/icc and ~/.color/icc ? What about running Gimp on windows? Color management on Windows would ideally be implemented using the color management capabilities of the operating system. Same on Mac OS X where ColorSync should be used. For now we will however concentrate on the LCMS based implementation and of course we will make sure that it works on all supported platforms. I think that it could be useful if that user can add additional profiles directories to the default ones. Think about advanced users that could have a lot of specific profiles depending on the situation. Users will be able to load color profiles from whatever location they wish. I don't think we need to provide a way to specify profile directories. GIMP will remember the last location you loaded profiles from and if you need to use multiple profile directories, it's easy to add bookmarks for them. This goes however way too much into details yet. We can figure out such usability concerns as soon as the basic framework has been put in place. But I have checked that the icc-profile parasite can be recovered from a Tiff file, but not from a jpg file. I assume that icc-profile parasite can be stored in tiff, but not in jpg. ICC profiles can be stored in TIFF files. The parasite is just the way that GIMP deals with this information. I don't know off the top of my head if JPEG allows to embed ICC profiles. Since I would rather get back to work on the color management implementation, I kindly ask you to look that up in the JPEG spec yourself. http://developer.gimp.org/standards.html has some links that you might find useful. If you know of any URLs that should be added there, let me know. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP and multiple processors
Hi, since hyperthreading and multi-core CPUs are becoming more and more common, I think we should put a little more focus on making use of these features. For that reason, I have made --enable-mp the default in CVS HEAD and also changed the gimprc preference so that GIMP uses 2 processors. This default doesn't have necessarily have to make it into the next stable release. The main concern now should be to make sure that it works at all. I had a look at the current implementation and also cleaned up the code a little. We are talking about app/base/pixel-processor.[ch]. There seems to be room for improvement. I'd like to hack on this myself but my time is limited, so I thought I'd ask if someone else would like to take this job. So here are some ideas of what could be changed: - Port the thread code to g_thread functions to make it more portable. That would probably be necessary since we don't want to maintain our own thread abstraction layer. It would mean that we would have to call g_thread_init(). I am not sure if that would introduce any noticeable overhead on systems that only use a single CPU. Might be worth to investigate that. - Use GThreadPool instead of continuously starting new threads. Creating a thread has a considerable overhead. The current implementation continuously creates new threads that finish after they have done their job. GLib provides a GThreadPool that would probably fit nicely here. As you can see, this is a rather small task coding-wise. It would however be good to also do some benchmarking to find out how much overhead is introduced by using the threaded pixel-processor. We don't want to make things worse for single-CPU systems. Any volunteers? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some questions
Hi, On Sat, 12 Feb 2005 13:54:39 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Color management on Windows would ideally be implemented using the color management capabilities of the operating system. Same on Mac OS X where ColorSync should be used. For now we will however concentrate on the LCMS based implementation and of course we will make sure that it works on all supported platforms. My understanding (please correct me, I don't have personal experience of this) is that the windows CMS is (or was?) rather broken: that was one of Marti Maria's original motivations for the development of LCMS. The apple one is supposed to be better, but there are some benefits to having the same CMS on all platforms. ICC profiles can be stored in TIFF files. The parasite is just the way that GIMP deals with this information. I don't know off the top of my head if JPEG allows to embed ICC profiles. Since I would rather get back to work on the color management implementation, I kindly ask you to look that up in the JPEG spec yourself. You can embed ICC profiles in JPEG files. The lcms distribution contains code to insert and extract profiles: check the sources for jpegicc and friends. John ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some questions
On Feb 12, 2005, at 11:13 AM, John Cupitt wrote: Hi, On Sat, 12 Feb 2005 13:54:39 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Color management on Windows would ideally be implemented using the color management capabilities of the operating system. Same on Mac OS X where ColorSync should be used. For now we will however concentrate on the LCMS based implementation and of course we will make sure that it works on all supported platforms. My understanding (please correct me, I don't have personal experience of this) is that the windows CMS is (or was?) rather broken: that was one of Marti Maria's original motivations for the development of LCMS. The apple one is supposed to be better, but there are some benefits to having the same CMS on all platforms. This is what Adobe does: They ship their own CMS with their products. They do however give you a choice of using the native CMS. All CMS will give slightly different results when you compare their output. For consistency purposes, it makes sense for an application to use the same CMS on all platforms if the app is available on multiple platforms. Karl Heinz ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some questions
On Saturday 12 February 2005 08:13, John Cupitt wrote: On Sat, 12 Feb 2005 13:54:39 +0100, Sven Neumann [EMAIL PROTECTED] wrote: Color management on Windows would ideally be implemented using the color management capabilities of the operating system. Same on Mac OS X where ColorSync should be used. For now we will however concentrate on the LCMS based implementation and of course we will make sure that it works on all supported platforms. My understanding (please correct me, I don't have personal experience of this) is that the windows CMS is (or was?) rather broken: This is still correct. Window CMS is basicly broken and applications implement CMS is what amounts to pockets of fuctionality. So on Windows I use Photoshop's CM and Adobe gamma to implement my CMS. I even turn off the CM functions in my printer drivers because these are not usable for serious CM work as it is to hard to predict what it will do. So all Windows has at this time is a frame work for where profiles are stored. I think we can do much better. -- Hal V. Engel pgpboJuq7ZTWa.pgp Description: PGP signature
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sat, Feb 12, 2005 at 01:15:02PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: where I clearly differentiated between gimp-specific issues and gtk+-specific ones. Marc, it is you who is constantly trying to change your words. Ehem? as you figure out that you have been wrong, you start to claim that you didn't say this or that you referred to a different subject. Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp. did this at least twice in this very thread. Please try to acknowledge when you have been wrong. Others are doing that here as well. You will Sorry, but bullshitting and bullying around does not help. If at all it's Mitch who should apologize :( If that is the new kind of tactics of you, namely calling others as spreading FUD, trying to intimadate them and bullying them around then you are very poor. You should learn to argue based on sound arguments instead of relying on lies and distasteful bullying tactics. also have to apologize to Mitch or stay not only out of this thread but out of this mailing-list. What's that supposed to mean? I have to stay out of this mailing list because I won't apologize to Mitch that he made a mistake? That is, of course, not what will happen. I am not responsible for you and mitch's personal problems, but it's bad that you take it out on others who are trying to be constructive :( -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Marc Lehmann ([EMAIL PROTECTED]) wrote: On Sat, Feb 12, 2005 at 01:15:02PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: as you figure out that you have been wrong, you start to claim that you didn't say this or that you referred to a different subject. Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp. Can all of you please take this off list? It is not at all on topic for this list. Thanks, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Marc, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: as you figure out that you have been wrong, you start to claim that you didn't say this or that you referred to a different subject. Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp. We had already figured out that the file-chooser issues don't belong here and were discussing the keybindings in the layers dialog. I explained the Image-Layer menu to you and you claimed that it would be hidden. I explained to you that it is clearly visible and documented. That would have been the moment for you to shut up. Instead you claimed that you were still talking about the file-chooser. You are taking your words out of the context they originally appeared in. That's not what I would call good style. Look at the thread again, you are obviously only interested in a flamewar. You've been accusing us of ignoring usability issues. That is ridiculous since we have been working on nothing but usability for the last two years. Other people are obviously capable of proposing enhancements without pissing people off the way you do. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Interested in color management
First to say I am sorry if some of my last post have been a little rought, I dono t have a great command of english, as you, I'm afraid, can experiment in this moments. Thanks to Hal, Sven and Carol for explain what CVS is. I do not have any experience with this technology, though I have a certain skills in C programming, programming application for scientific and technical solutions. I have certain knowledge of color management (I usually work as advisor in digital technology in prepress, CAD and photography) and are really interesetd in a free soft solution to prepress and photographic fields. I have been working, on my own, on a library for color processing. Not a great thing, but I have some knowledge of color science and light physics (no, I am not physic, I studied a minor electronic engineering) and some experience in fuzzy expert systems. I would like to work in the backend of the color system. As I say, I am photographer, wishing a professional use for Gimp. As photographer I see 3 lack for professional use of GIMP: 1 Not efficient CM. 2 Not working on 16 bits. 3 Not color separations neither an efective CMYK use. As photographer I work in this way: The image comes in an specific color space. That of the camera/scanner. The engine read this RGB numbers (say image data) and translate it to a device independent color space which have a specific color mean. There are ideal color modes to represent this real color (Lab, XYZ) and some not so idealm, but practical spaces (AdobeRGB, ColorMatch). Once I have the real color I need to translate one sample of color to send to screen. This translation uses as dictionary the screen profile if it exist, or a sRGB if not. But, as photographer I am not interested in what I see on screen, but what I can get in a developing machinery. So I need to see how the color will appear. This is, use the screen as a proofing machine. Then I can translate the color from the real color (working space in adobe way of saying) to the print color space and then translate it again to the screen. Maybe with the sRGB definition or with the screen profile. There are color that printer can render, but do not can render the screen. So we never will have that color in the monitor. And there will be some colors that the printer cannot render but can be doit by the screen. I need an advise when this happens. In Adobe color management systems there is a out of gamut mark in the info palette. What I have been working is in a system to translate from the file, to the screen and to the printer. I have not been programming the CMS. I have to connect my library to the CMS engine (one thing to do) and I do not have an user interface. Actually my work is not much advanced, and I would like how can I help in the gimp color system management with this color management for photographers aimed system. Thanks to all for the help. About the CVS. I am not skilled in gnu programming and I almost cannot understand the faqs. Because I see there are many overunderstaded concepts that, for some like me, results a little confusing. Thanks again Sven, Hall and Carol for their help to read that documentation. /*--*/ Podemos refutar el antiguo mito, tantas veces aludido, del papel predominantede la sección áurea en la época renacentista (Rudolf Wittkover, La proporción en el arte y en la arquitectura Parte IV Las proporciones renacentistas y la conmensurabilidad, 1949) Francisco Bernal Rosso Traducción y redacción técnica-CAD-visualización arquitectonica-fotografía técnica-iluminación y color. Webpage at: http://www.geocities.com/pacorosso http://www.fotoforum.net/socios/b/b_f/fotos.htm http://www.michelle7.com/contributors/r/paco_rosso.htm ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
On Sat, Feb 12, 2005 at 08:29:10PM +0100, Simon Budig [EMAIL PROTECTED] wrote: Marc Lehmann ([EMAIL PROTECTED]) wrote: On Sat, Feb 12, 2005 at 01:15:02PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: as you figure out that you have been wrong, you start to claim that you didn't say this or that you referred to a different subject. Ehem? Is this bullshitting tactics? I never changed my words. I originally described a problem with the gimp file dialog, which is caused by two things, a problem in gtk+ and a less disastrous problem in gimp. Can all of you please take this off list? It is not at all on topic for this list. I will now, completely, except for noting that svens postings resulted in precisely what he claimed it wouldn't: yet another thread with actual usability problems has been *killed* in the worst possible way. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
Hi, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: I claimed and still claim that I cannot set shortcuts in the layers dialog, which was possible before, and posed a problem for other people in the past, too. I would call this hidden, yes, and I still think it's a usability problem, because 1.2 clearly worked better. Marc, I shouldn't argue with you but I have to disagree with you here. The GIMP 1.2 behaviour was a major pain in the ass. Behaviour of keybindings was dependant on the window that has the focus. I don't know if this has ever been a problem to you but have you ever seen a new GIMP user struggling with this? Keybindings are vital in an application like GIMP. If Ctrl-Z for Undo doesn't work in the Layers dialog because it's only bound to the image window, then you end up moving focus between windows only to make keybindings work. This is how GIMP 1.2 worked. For a newbie it takes a long time to get used to this behaviour. Sorry, but 1.2 didn't clearly work better. With GIMP 2.2 you can finally concentrate on your work instead of tracking what window your keypress might go to and what action it will cause there. I don't understand you. I described various problems. You claim they are simply not there. Why? You may have not realized, but I didn't ignore your problems at all. There's a new thread I opened to discuss file-chooser performance and I realized that we should have more pre-defined shortcuts in the Layers dialog. So I added shortcuts for New Layer and Duplicate Layer actions last night. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] update from the bleeding edge
Hi, I've started to update the NEWS file in the HEAD branch again. Perhaps some of you haven't followed development since we branched. This might be of interest for you then: http://cvs.gnome.org/viewcvs/*checkout*/gimp/NEWS I certainly missed a couple of things while reading through the ChangeLog, please excuse that. Or, better yet, point me to the missing points so that we can fill them in... Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Some questions
Hi, Karl Heinz Kremer [EMAIL PROTECTED] writes: All CMS will give slightly different results when you compare their output. For consistency purposes, it makes sense for an application to use the same CMS on all platforms if the app is available on multiple platforms. Fully understood. The point was not to necessarily use the CMS of the underlying operating system but to not tie us into a particular CMS. The framework, that is being worked on, should allow for different implementations. We will use lcms for the default implementation and it should work on all supported platforms. The goal is though to allow people to develop alternative implementations, based on other CMS or perhaps simply with different policies. As soon as we have extened the modules and plug-ins API as described, you will be able to develop a different color management implementation without doing any modifications to the GIMP core. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
