hi,
> This is "dynamic range" vs. "absolute number of colours". The human
> perception varies a lot accoridng to the environment, and, while the human
> eye has difficulties with a large number of different colours, it is very
> sensible to banding, and different media (film) must support a very
hi,
> this is linux specific, and wrong. It is very sensible of the kernel to
> swap out data that is likely not to be used for other apps like gimp.
'top' - thats a command featured in almost all un*x-style OS's
> Any non-obsolete linux kernel version can be expected to swap out 6-10mb
> even
>> thats odd. that size should be fine. i work in film
>> res all the time (4kx3k) at 32bpp (yes, i know film
>> should be done at 48 or 64 bpp to prevent banding, i
>> only work this res for testing)
>can I see some references for these values? Seems that number
>is just climbing all the time. ca
On Tue, Jun 06, 2000 at 09:50:08AM +0100, Alan Buxey <[EMAIL PROTECTED]> wrote:
> > BTW, Unix "trashing" is rare to find, or at least to heard. When it moves
> > data to disk it does not sound like Windows Machine Gun Swap Routine (TM),
>
> ;-)
>
> easiest way to see when you're swapping is to g
On Tue, Jun 06, 2000 at 09:55:50AM +0100, Alan Buxey <[EMAIL PROTECTED]> wrote:
> can I see some references for these values? Seems that number
> is just climbing all the time. can the human eye distinguish
> more than 26-bit? Even at 4kx3k, you've only got 12million pixels
> that can be of differ
Hello all,
Yesturday I requested that our friend send me a copy of his image so that
I could try the test on my computer at work. (PIII 400 128MB, Matrox G400,
WinNT)
I chose to test with levels because I adjust levels or curves on almost
every image I edit.
In Photoshop (v5.0) the redraw afte
hi,
> thats odd. that size should be fine. i work in film
> res all the time (4kx3k) at 32bpp (yes, i know film
> should be done at 48 or 64 bpp to prevent banding, i
> only work this res for testing)
can I see some references for these values? Seems that number
is just climbing all the time. ca
hi,
> BTW, Unix "trashing" is rare to find, or at least to heard. When it moves
> data to disk it does not sound like Windows Machine Gun Swap Routine (TM),
;-)
easiest way to see when you're swapping is to go to a shell and type
'free' - you shouldnt see the swap number used at all if you want
On Mon, 5 Jun 2000, pixel fairy wrote:
>> The images I edit are usually around the 3500x2800
>> or so mark at 30 bits
>> depth. I've recently tried Gimp on such images and
>> have found it to be
>> lacking to put it mildly.
>
> thats odd. that size should be fine. i work in film
> res all the t
> The images I edit are usually around the 3500x2800
> or so mark at 30 bits
> depth. I've recently tried Gimp on such images and
> have found it to be
> lacking to put it mildly.
thats odd. that size should be fine. i work in film
res all the time (4kx3k) at 32bpp (yes, i know film
should be do
>It's set to either 15 megs or 10 megs. However the disc is not being
Too low, enough to edit a logo, but not for big images. 3500 * 2800 * 3
bytes = 29.4E6 bytes, as you see it is a lot more than 15MB (near two
times), so Gimp moves data to disk as soon as you load the image.
I have used Gimp
It's set to either 15 megs or 10 megs. However the disc is not being
thrashed, throughout the redraw all the CPU time is being eaten by gimp,
i.e. it's processor-bound, not I/O bound, if it was a cache issue then I'd
expect large amounts of disc I/O but I'm not seeing that.
Thanks for your help.
What have you set your tile cache size to in gimp perfs? Sounds like a
simple misconfiguration.
--
Jon Winters http://www.obscurasite.com/
"Everybody loves the GIMP!"
http://www.gimp.org/
13 matches
Mail list logo
