Re: [Gimp-user] Changing house colour
Sven Neumann [EMAIL PROTECTED] wrote: Steve Litt [EMAIL PROTECTED] writes: By the way -- I use select by color a lot when I scan yellow receipts. I use select by color to turn the yellow to white, then save it as grayscale and save mucho megabytes. The classic method to make the paper on a scan to appear as white is to use the Levels tool. Use the white-point color picker and click on an empty spot of the scan. Or, even better, define the white-point before doing the actual scan. Most scan software (including XSane) supports this operation. That has a quite different effect from what Steve mentioned. Adjusting the white point will scale all the colours in the image. For example if you had green writing on yellow paper, adjusting the white point like this would change the green to cyan (and red to magenta, but not affect any blue writing). Mind you, for Steve's receipts and his use of them, the final result in BW might be OK. Adjusting the white point is a very useful technique for colours _within_ an image, but it's a bit flawed as a general method for rendering the surrounding paper as white (unless the ink is pure black). Cheers __ David ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Environment settings big images
Kevin Myers wrote: As mentioned in my previous message, Photoshop's limit is 32K maximum pixels in either dimension. Your image did not exceed this limit in either dimension. We typically work with images that are up to several hundred thousand pixels in one dimension, by 2 or 3 thousand pixels in the other dimension. Thus we almost always exceed the Photoshop limit. I presently run GIMP 1.2.4 on a 2.4 GHz P4 based system under Windows 2000, with 3GB of RAM installed (only 2GB of which can be used by the GIMP). We usually work with 8 bit grayscale images, and as described above our typical image sizes are on the order of 200 megapixels. As you mentioned, your image was only 98 megapixels. On my system, I have no problems with menu delays at all (far less than one second response), and initial image loading speed is reasonable, typically on the order of 5 or ten seconds. Strictly speaking PS 8 (CS) can go larger in pixel dimensions (if you use the new .PSB file format) but there are other operational issues that still make this awkward. But for me it's not the pixel dimensions that define a large image. As a photographer I work with full RGB images, not piddly little greyscale files ;-). I have two systems here. Apples aren't quite apples, but it's a vaguely interesting comparison anyway: System A is a 1.6GHz P4 with 512MB RAM, running Gimp 1.2 on FreeBSD. Working with large files (e.g. only 6400x9600 24-bit pixels) can be painful, especially if I decide to add layers. I've done an A0-sized poster on this machine and it was ridiculous. I got the job done eventually, but it was VERY painful. System B is a PowerMac G4/450 with 1GB RAM. This machine is old and slow by Apple standards. It's running Photoshop CS on MacOS X 1.3. It's a pleasure to use in comparison to System A. The speed difference (and a few other advantages) has made it worthwhile to get used to the different (Photoshop) interface. I regularly work with 48-bit image files, at large print sizes, and with at least 5 or 6 layers. The filesize when saved as a layered uncompressed TIFF is often larger than will fit on a CD. As the files get bigger the processing time increases, but it feels like a simple geometric progression based on the CPU/megapixel relationship, not an exponential/whatever progression based on RAM shortfalls. Sure the Mac has more RAM, but I've tuned Photoshop's RAM allocation back to 256MB as an experiment and it was still faster than the Gimp. I normally have 576MB allocated to PS. In the Gimp there seems to be no upper bound to its RAM use. No matter what size you set the tile cache to (right nowe I have it set at 320M) and the number of undo levels, its memory footprint seems to keep increasing, and when it gets painful it's typically paging (i.e. it's not managing its own scratch space like Photoshop does - the OS is paging it in and out). Shutting down other applications does improve things for a short while, but very soon that extra memory is chewed up and performance goes down the tube again. It seems that often the Gimp's active memory footprint is very large, and information is being paged out that was only just paged in. When the Gimp's performance drops off it's saturating the disks with VM paging, and the whole machine is painful to use. When Photoshop's performance drops off it's mainly just hogging CPU and the rest of the machine is vaguely usable. I would say that on machines with equivalent RAM sizes Photoshop is a better performer (on the images I deal with at least) but I should load Gimp 2 onto the Mac for a better comparison. Using Photoshop 7 on my wife's XP machine which is a 1.8GHz version of my System A seems OK, but I haven't done a lot of work with it as she keeps wanting to use it... __ David ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Environment settings big images
Carol Spears wrote: On Fri, Apr 23, 2004 at 11:23:32AM +1000, David Burren wrote: Using Photoshop 7 on my wife's XP machine which is a 1.8GHz version of my System A seems OK, but I haven't done a lot of work with it as she keeps wanting to use it... i am curious. do you think that if the adobe geniuses could make their software compile on linux, if it would slow it down. No. In fact they've got it to compile on a Unix (ie. MacOS X) and it runs great. I don't believe it's inherent in the OS that the application is running on. I do think that Photoshop currently does a better job at managing its memory resources, but that's at the appliction level. i am not sure where gimp is losing this race of yours but the fact that i can run gimp on linux and can not run photoshop (any flavor or version) to compare gives photoshop some weird edge. Interesting. I'm sure you and I have different requirements so we'll come to different conclusions. As an opensource developer (primarily on BSD platforms - both in the OS/kernel and at the application level) I would love it if the Gimp was able to do all the tasks I need of it. But as a photographer trying to earn a living (I currently supplement this with short-term Perl and SQL development contracts) I can't afford to be without the tools that Photoshop provides me (the most high-profile of which are complete ICC support and 16-bit files). Now that I'm happy that OSX has progressed to a point that I'm happy to use it, the fact that Photoshop is available for it is reason enough for me to move to OSX instead of BSD or Linux. I look forward to the day when the Gimp or CinePaint come up to speed on the features I need, but I can't afford to wait. My observations about memory consumption behaviour between the Gimp and Photoshop have been coincidental to that. It's not the reason I started using Photoshop, but it's a pleasant side-benefit. is the very fact that the linux community shared with YOU part of what slows gimp down? Now this sounds like you getting all snooty for no good reason (these snide comments have never been good for your image Carol). In fact I wasn't aware that the LINUX community shared with me. The GIMP community that I have been a part of for years (as a Unix user, even if using NetBSD/FreeBSD instead of Linux) has shared the Gimp with me, and I've been grateful for being part of that community. But that's completely irrelevant to the discussion at hand... Cheers __ David ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: Re: Re: Monitor for Gimp
Just in case this wasn't clear in my last message, I'll expand on a few points. You can implement either or both of calibration and profiling. Having systems calibrated to a common standard means that you don't _have_ to worry about ICC profiles etc IF ALL YOU'RE DEALING WITH IS RGB DATA IN THE COLOUR SPACE REPRESENTED BY THAT CALIBRATION. Thus with the Gimp in its current form, calibration is important (it's the only thing available!). But if you want _accurate_ colour you need to implement profile support (e.g. building on top of lcms) including dynamic conversion from an image's colour space to the display system's profile. With full profile support it doesn't matter what the user's system is calibrated to (e.g. weirdarse 1.8 gamma). If an image's data is in sRGB the colours will get converted so that what is displayed on the screen is accurate, even though sRGB has a gamma of 2.2. My systems are calibrated to a gamma close to 2.2, and I can view images in ColorMatch RGB (which has a gamma of 1.8) with no problems as the profile conversion takes care of that for me.. Calibration benefits the non-colour-managed applications, but with only limited usefulness. Mac and Windows systems implement both calibration and profiling in an attempt to serve both CM and non-CM applications (and the calibration can help ensure the system is in a reasonable state prior to profiling). Full profile support is important because the colour response of your inkjet printer, scanner, printing press, etc will probably not match that of your calibrated system, and for accurate work you need a profile describing the colour space of each and to convert between them as required. I'll shut up for now. ;) Cheers __ David Burren ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp and prepress functions
Kelly Martin [EMAIL PROTECTED] wrote: Someone would have to develop the profiles. The way Photoshop does it is by buying printers and doing test prints and gathering colorimetric data. The GIMP developers are short on people who have access to colorimetry labs, not to mention lots of printers. A lot of the processes that go into prepress are tied up in patent and trade secret law. Getting those processes into the GIMP will be no easy task. This is a furphy. Generating the profiles is quite different from using them. There are existing libraries (e.g. lcms) to convert between colour spaces (defined by profiles) and there's even a Gimp plug-in to do this. There is even software for generating profiles for printers/scanners/etc (not part of the Gimp, but it doesn't have to be). For accurate colour work you typically need to profile your own devices, as each has a slightly different colour response (e.g. for a printer it depends on the driver settings, the ink, and the paper choices). Monitors in particular constantly change their behaviour and need to be reprofiled regularly. Good print labs profile their devices and provide the profiles to their clients. It's not up to the Gimp to generate profiles, it's up to the Gimp to use them. Unfortunately Gimp has a way to go before it has a concept of your monitor colour space (and dynamically converting displayed images into that colour space) and a colour space for each image. This is something that Photoshop (and most of the other Adobe software) does very well. The Gimp has a plain model where there is only one colour space: your monitor's. Everything is dealt with as just RGB (disregarding the HSV/etc composition/decomposition feature) and sent to your monitor as-is. I think a more-sophisticated model is required to support a colour-managed workflow (and things like 16-bit support, CMYK, L*a*b, etc are just part of that). Other projects like CinePaint (nee FilmGimp) are making progress on this. Hopefully the Gimp will catch up. But I don't think patent and trade secret law has much to do with it. __ David Burren ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp and prepress functions
Kelly Martin [EMAIL PROTECTED] wrote: My gf used to work for a large prepress company. They spent a lot of money generating and validating matching profiles, and they're not going to just give them to anyone. If you want them, you pay for them. This is silly. The profiles would be for their specific machines, and would be useless with anyone else's (even with the same make hardware, as the knobs and dials would probably not be in standard positions). The choice of ink and paper stock are also factors. I'm not saying the prepress company wouldn't do it, just that I think it would be a completely silly reason for not supplying the target profile. Even if they did not want to provide the final profiles, if they want any chance of supporting a digital colour-managed workflow they would have to accept files tagged with other profiles (e.g. AdobeRGB, sRGB, ProPhotoRGB, various CMYK colour spaces, etc) and do the conversion in-house. One of the labs I deal with has its own intermediate colour space that it gets us to convert to, so internally they can manage the choice of printer/paper/etc for each job and update the target profiles whenever they calibrate the machines (without having to send them out to all the clients). Those intermediate colour spaces should be available to the Gimp (although there _are_ copyright considerations with the profiles). The format of these ICC profiles is defined in a standard, and the lcms library already knows how to deal with them. Cheers __ David ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] filmgimp and gap
sam ende [EMAIL PROTECTED] wrote: cinepaint doesn't seem to have any of the functions gap has ? i fact i haven't been able to discern what functions it does have that gimp doesn't, so i'm not sure why one would want to merge ? I say again: support for 16(48)-bit images! Gimp will read them in but immediately throw away the lower 8 bits. For those of us dealing with 16-bit (actually, often 12-bit but the extra 4 bits are irrelevant in this) film scans and raw files from digital cameras, this is very important. BTW, what's gap? The only GAP I'm aware of is the Gnu Administration Project. __ David B. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: Rotoscoping
Mark Rubin [EMAIL PROTECTED] wrote: For me, the most important feature of filmgimp/cinepaint is the support for greater than 8 bits per color component (16 bit integer and 32 bit floating point). Hear, hear! This is the only reason I have filmgimp on my system - the ability to edit 16-bit files from my cameras prior to doing final 8-bit work in Gimp. I would be very happy if I didn't have to use filmgimp for this, as (has been indirectly pointed out) the interface is rather old-fashioned. The first problem is it doesn't have a drag-n-drop interface similar to that used by gimp-remote (which I use for passing files to the Gimp from my database) and goes on from there. __ David Burren ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Image resolution out of bounds Message
When I open files stored on a Photo CD scanned by a Fuji Frontier, the following GIMP Message appears: Image resolution is out of bounds, using the default resolution instead. I'm new to Gimp, but don't find any reference to this message in my Grokking the Gimp text. I've just picked up 5x7 Frontier prints made from Gimp'd .jpg files and they look fine to my eyes -- in spite of the resolution message. Can anyone point me to what it's about? Resolution is not the number of pixels, but rather the size of the pixels. The usual unit of measurement is dots per inch (dpi). When the Gimp is opening a TIFF or JPEG file it reads the tag inside the file that specifies the resolution. If the value doesn't make enough sense, the Image resolution is out of bounds message is output. In v1.2.3 the following definitions are used: #define GIMP_MIN_RESOLUTION 5e-3 #define GIMP_MAX_RESOLUTION 65536.0 It would be interesting to know what the value was that it didn't like, but in the end it doesn't matter. You're probably going to change the dpi before you print it anyway... The image data is not affected by this condition - if your pictures look ok then they probably are. __ David Burren ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Two Questions...
On Fri, 13 Dec 2002 22:11:26 CDT, Pat Suwalski [EMAIL PROTECTED] wrote: 2) Has anyone ever considered making GIMP into a single-window interface with MDI and children windows? An annoyance of GIMP is how it takes so many windows and shows up in the task list when alt-tabbing. This is where you'd get into religious bunfights if you took away the current interface. If a single-window interface was available, it should be selectable. The multi-window interface is one of the things I love about the Gimp. I already have a window manager running which can take care of them, so why not use it? I'm one of those people who use virtual workspaces (10 of them in fact). I often have Gimp windows clustered in one workspace, but it's useful to have Gimp windows pop up in other workspaces and in fact sometimes I have Gimp windows appearing in multiple workspaces. When you talk about each window show[ing] up in the task list when alt-tabbing, that would be a function of your window manager (or are you running under Windows?). You may be able to configure your WM to be more helpful (e.g. by dropping some window names from the list). BTW, my comments are based on experience with 1.2.x - can't comment on 1.3. Cheers __ DavidB ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] gimp single-instance startup option?
hi, is there any way to start gimp so that if there is already another instance of the gimp running (by current user, or on same display, etc.), gimp just uses the earlier-running (1st) instance, instead of starting up a whole new instance? I would have thought mention of gimp-remote would be in a FAQ. gimp-remote --new is probably what you want. __ David Burren ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] sepia
On Mon, 25 Nov 2002 16:16:17 +0100, Andrew Langdon-Davies [EMAIL PROTECTED]: Anybody know how to imitate a sepia print? On Mon, 25 Nov 2002 11:19:05 MDT, Judy Wilson [EMAIL PROTECTED]: Have you tried (right click on image) Script-Fu/Decor/Old Photo? As with many simple tasks, there are many ways to do this. I must admit I hadn't used that Script-Fu. If you prefer, try this: To tone an image with sepia (or selenium, or whatever colour you want), put a new layer above the image filled with this colour. Set the layer mode to Color and play with the opacity. __ David Burren ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp and CMYK DTP
On Tue, 29 Oct 2002 15:13:55 CDT, Patrick [EMAIL PROTECTED] wrote: Hopefully a solution to the CMYK seperation problem will be forthcoming in a later version of Gimp, because that seems to be it's only weak point at the moment for most professional users. Speak for yourself. For me, Gimp's major shortcomings are lack of proper colourspace management and inability to work on 16-bit (per R,G,B) images (sure you can read 16-bit TIFFs, but the extra data is thrown away). As a working photographer, these things give me the most pain. I'm sure there are other features (or lack thereof) which give other people pain apart from the lack of good CMYK support. Not to say that CMYK doesn't deserve attention, just to note that it's not the Gimp's only weak point. __ David Burren ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
