[Gimp-user] Error no disk
Ya, why do I have to always click continue on the no disk dialog every time I save or open an image in gimp. Also when using plug ins. Is it because my hard disk is labeled H and not C??? Help its annoying. -- friesenlyle (via gimpusers.com) ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp's rendering speeds
This is good to hear. Rendering speed is important, especially if Gimp wants to be a viable competitor to the mainstream counterparts, where man-sized canvasses are concerned. On 03/02/2011 03:18, Joao S. O. Bueno wrote: On Wed, Feb 2, 2011 at 3:20 PM, Martin Nordholts wrote: On 02/02/2011 02:32 PM, Jeremy Nell wrote: Will the next release of Gimp be a bit quicker? I'm afraid not; the next release of GIMP, GIMP 2.8, will not be quicker in this regard. The release after that, GIMP 3.0, will focus on running on GTK 3.0 and bringing high bit depths into the picture. 3.2 will focus on non-destructiveness Maybe in 3.4 we'll have time to solve this in a proper way. Actually, this may well be solved for GIMP 3.0 - as it will them most depend on GEGL improvements. Pippin has detailed the improvements that could be done on GEGL with regards to speed rendering in a document he posted on Tuesday (I don't remember if it was to this list): mostly improvements that would allow the image viewport to be real time rendered, while the real rendering would happen in background. js -><- / Martin -- My GIMP Blog: http://www.chromecode.com/ "Nightly GIMP, GEGL, babl tarball builds" ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp's rendering speeds
On Wed, Feb 2, 2011 at 3:20 PM, Martin Nordholts wrote: > On 02/02/2011 02:32 PM, Jeremy Nell wrote: >> Will the next release of Gimp be a bit quicker? > > I'm afraid not; the next release of GIMP, GIMP 2.8, will not be quicker > in this regard. > > The release after that, GIMP 3.0, will focus on running on GTK 3.0 and > bringing high bit depths into the picture. > > 3.2 will focus on non-destructiveness > > Maybe in 3.4 we'll have time to solve this in a proper way. Actually, this may well be solved for GIMP 3.0 - as it will them most depend on GEGL improvements. Pippin has detailed the improvements that could be done on GEGL with regards to speed rendering in a document he posted on Tuesday (I don't remember if it was to this list): mostly improvements that would allow the image viewport to be real time rendered, while the real rendering would happen in background. js -><- > / Martin > > > -- > > My GIMP Blog: > http://www.chromecode.com/ > "Nightly GIMP, GEGL, babl tarball builds" > ___ > Gimp-user mailing list > Gimp-user@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user > ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] opening binary flat files
mintakax wrote: > Sorry mistype-- the rev is 2.2.13 ... is this an old rev ? Yes. Latest version is 2.6.11 ns ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] opening binary flat files
>>Hi, >>phorg...@yahoo.com (2011-02-01 at 1834.43 -0800): >>> On 02/01/2011 01:24 PM, GSR - FR wrote: >>> > ... elision by patrick ... >>> > Ooops, right... yet another reminder of why I hate interfaces that >>> > hide and forget you opened the "|>". I just noticed the selector now, >>> > different than the filtering one. >>> If the data has an extension of .data on the file name is it >>> automatically detected? >>The hidden list shows no extension(s) for raw and ".data" files are >>not shown when the other selector is set to "All images", so I >>doubt. You will probably have to open the dialog, change the filter to >>show all files as well as pick RAW from the other list, then select >>the file. Yes, it sounds repetitive and the forced format option seems >>to be always closed and forgotten (tried it with PNGs). I also tried >>drag and drop with random file named "foo.data", it caused an error. >>GSR >Thanks for all the replies ! When I pick All Files and then activate the >Select File Type, the drop down list does not contain a "RAW".. the list is >alphabetical and PostScript document is followed by Scalable Graphic IRIS >image ? >The GIMP we have installed is 2.2.33 is this an old rev ? >And to answer a previous question, the results of the file command for these >files I am trying to open is: data Sorry mistype-- the rev is 2.2.13 -- mintakax (via gimpusers.com) ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] opening binary flat files
>Hi, >phorg...@yahoo.com (2011-02-01 at 1834.43 -0800): >> On 02/01/2011 01:24 PM, GSR - FR wrote: >> > ... elision by patrick ... >> > Ooops, right... yet another reminder of why I hate interfaces that >> > hide and forget you opened the "|>". I just noticed the selector now, >> > different than the filtering one. >> If the data has an extension of .data on the file name is it >> automatically detected? >The hidden list shows no extension(s) for raw and ".data" files are >not shown when the other selector is set to "All images", so I >doubt. You will probably have to open the dialog, change the filter to >show all files as well as pick RAW from the other list, then select >the file. Yes, it sounds repetitive and the forced format option seems >to be always closed and forgotten (tried it with PNGs). I also tried >drag and drop with random file named "foo.data", it caused an error. >GSR Thanks for all the replies ! When I pick All Files and then activate the Select File Type, the drop down list does not contain a "RAW".. the list is alphabetical and PostScript document is followed by Scalable Graphic IRIS image ? The GIMP we have installed is 2.2.33 is this an old rev ? And to answer a previous question, the results of the file command for these files I am trying to open is: data -- mintakax (via gimpusers.com) ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp's rendering speeds
On 02/02/2011 02:32 PM, Jeremy Nell wrote: > Will the next release of Gimp be a bit quicker? I'm afraid not; the next release of GIMP, GIMP 2.8, will not be quicker in this regard. The release after that, GIMP 3.0, will focus on running on GTK 3.0 and bringing high bit depths into the picture. 3.2 will focus on non-destructiveness Maybe in 3.4 we'll have time to solve this in a proper way. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Nightly GIMP, GEGL, babl tarball builds" ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp's rendering speeds
On 02/02/2011 03:32 PM, Jeremy Nell wrote: > I've asked this before, with no answers. My aim, as a happy Gimp user, > is not to slate the software, but to improve it. I am not a developer, > but rather a digital artist who uses Gimp extensively. > > Working on large canvases, I see that Gimp slows down, where rendering > is concerned. For example, if I have a complex artwork and I want to > hide certain layers, then a simple click on the eye icon in the layer > takes a lot longer than it should. As much as developers hate > comparisons, this simple task is generally quicker in Photoshop. > > Another obvious "problem" is that, again, on a large canvas (A4 and up, > 300DPI), the brushes - when increased in scale - lag behind the mouse / > stylus. This indicates to me that Gimp's rendering engine could be > quicker. Again, I've compared the exact same task in Photoshop (CS3) > and it is considerably quicker (even with less RAM) allocated to it. > > Speaking of which, I am using an i7 PC with 3 gigs of RAM allocated to > Gimp alone, so I'm not sure how to make Gimp's response time any quicker. > > Will the next release of Gimp be a bit quicker? And what tips can > anyone give? Same here, I would like some advice on this too :) Regards, Petar ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Gimp's rendering speeds
I've asked this before, with no answers. My aim, as a happy Gimp user, is not to slate the software, but to improve it. I am not a developer, but rather a digital artist who uses Gimp extensively. Working on large canvases, I see that Gimp slows down, where rendering is concerned. For example, if I have a complex artwork and I want to hide certain layers, then a simple click on the eye icon in the layer takes a lot longer than it should. As much as developers hate comparisons, this simple task is generally quicker in Photoshop. Another obvious "problem" is that, again, on a large canvas (A4 and up, 300DPI), the brushes - when increased in scale - lag behind the mouse / stylus. This indicates to me that Gimp's rendering engine could be quicker. Again, I've compared the exact same task in Photoshop (CS3) and it is considerably quicker (even with less RAM) allocated to it. Speaking of which, I am using an i7 PC with 3 gigs of RAM allocated to Gimp alone, so I'm not sure how to make Gimp's response time any quicker. Will the next release of Gimp be a bit quicker? And what tips can anyone give? ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user