Hi,

David Gómez writes:

I've scanned some jpeg images with a 24bit depth. Some of them are old photographies in black&white that show 'bands' when are displayed on a 16 bit depth display. After digging in the menus i noticed that the image could be transformed to a indexed pallete, with a Floyd-Steinberg dithering, but that did not solve nothing, the maximum number of colors cannot be set to more that 256 :-/. Is there another way to dither an image in gimp? Programs like gqview, an image viewer, use the dither algorithms bundled with gdx_pixbuf in gtk2, and they work perfectly with the same images. Why cannot the gimp do the same quality dithering if it's using the same library?

The GIMP display canvas uses the dithering routines from GdkRGB which is probably what you are refering to. Of course this does only affect the display, not the image data. I am not sure but I think I remember a plug-in that could apply dithering to RGB images w/o converting to Indexed colors.

Sven

Hi David,

David Gómez wrote:

I've scanned some jpeg images with a 24bit depth. Some of them are old photographies in black&white that show 'bands' when are displayed on a 16 bit depth display.

This is a normal phenomenon when moving to higher bitdepths. Unless you're talking about 16 bits in total, and not 16 bits per channel, in which case I'd be a bit mystified...

After digging in the menus i noticed that the image could be transformed to a indexed pallete, with a Floyd-Steinberg dithering, but that did not solve nothing, the maximum number of colors cannot be set to more that 256 :-/.

Floyd-Steinberg dithering is basically a way to approximate more colors with a smaller palette... it does not actually do anything like what you are expecting (as you have noticed).

Is there another way to dither an image in gimp?

Have you tried blurring the image with a radius of 0.5 or 1.5 pixels? This sometimes works quite well.

Programs like gqview, an image viewer, use the dither algorithms bundled with gdx_pixbuf in gtk2, and they work perfectly with the same images. Why cannot the gimp do the same quality dithering if it's using the same library?

Oh, I see what you mean, I think - you're talking about the rendering of the data, you don't actually want to change the underlying data, you want it to look better. Is that right?

If that's the case, then I'm afraid the answer is that I don't know. I thought we used a GdkPixbuf, so if we don't I'm stumped :)

Cheers,
Dave.

On Wed, Jan 07, 2004 at 09:43:09PM +0100, Sven Neumann wrote:

Hi,

David G??mez writes:

I've scanned some jpeg images with a 24bit depth. Some of them are old photographies in black&white that show 'bands' when are displayed on a 16 bit depth display. After digging in the menus i noticed that the image could be transformed to a indexed pallete, with a Floyd-Steinberg dithering, but that did not solve nothing, the maximum number of colors cannot be set to more that 256 :-/. Is there another way to dither an image in gimp? Programs like gqview, an image viewer, use the dither algorithms bundled with gdx_pixbuf in gtk2, and they work perfectly with the same images. Why cannot the gimp do the same quality dithering if it's using the same library?

The GIMP display canvas uses the dithering routines from GdkRGB which is probably what you are refering to. Of course this does only affect the display, not the image data. I am not sure but I think I remember a plug-in that could apply dithering to RGB images w/o converting to Indexed colors.

Actually, gqview defaults to GDK_RGB_DITHER_NORMAL whereas gimp uses GDK_RGB_DITHER_MAX always, which should theoretically do a better job. Maybe you could put up a sample image somewhere so we can see what exactly the problem is?

-Yosh

That's because the screen display code doesn't smooth the image when it scales it, for speed reasons. Dedicated viewing programs can afford to do a better job showing the image because they won't be re-drawing it quite so often (imaging panning around the image while editing it - you'd like that to be fast, right?)

Austin

-----Original Message-----
From: gimp-developer-bounces@lists.xcf.berkeley.edu [mailto:gimp- developer-bounces@lists.xcf.berkeley.edu] On Behalf Of David Gómez Sent: 07 January 2004 22:04
To: Sven Neumann
Cc: Gimp-devel
Subject: Re: [Gimp-developer] Dithering

Hi Sven ;),

The GIMP display canvas uses the dithering routines from GdkRGB which is probably what you are refering to.

Yes i was referring to GdkRGB dithering, but it seems that was not the cause of the problem, as i said in my previous mail, and i was wrong thinking that was caused by gimp dithering implementation.

Thanks,

-- David Gómez

"The question of whether computers can think is just like the question of whether submarines can swim." -- Edsger W. Dijkstra

Hi,

"Austin Donnelly" writes:

That's because the screen display code doesn't smooth the image when it scales it, for speed reasons. Dedicated viewing programs can afford to do a better job showing the image because they won't be re-drawing it quite so often (imaging panning around the image while editing it - you'd like that to be fast, right?)

Well, actually we'd like to add interpolation to the GIMP canvas as well. At least optionally. Modern computer hardware seems fast enough to do this, especially when one takes advantages of CPU acceleration features (MMX, SSE, ...). Perhaps someone wants to tackle this task for GIMP-2.2?

Sven

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Jan 20, 2004, at 5:48 pm, Sven Neumann wrote:

Well, actually we'd like to add interpolation to the GIMP canvas as well. At least optionally. Modern computer hardware seems fast enough to do this, especially when one takes advantages of CPU acceleration features (MMX, SSE, ...). Perhaps someone wants to tackle this task for GIMP-2.2?

In OSX many applications tend to provide a quick redraw for pannings but start a timer which will refine the display once it was static for a while.

- - --
Servus,
Daniel
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQA46CTBkNMiD99JrAQIGRQf/UWfxv7S9lxgybUrvm1U2CTUAGvSQLC2w uK6iUhZqirtQaBuzDTH23BEz5L/tzCoCf+7vJl11j1vZOpRZqE6H7kK8wmAb1i8T HKUthgScPGASocRHPevpF+u5cD3xBcbT2C6F6OXg/BEOOAFEm06gVIjaF7AOvEW3 x1L/zksyCxfZsAf2CYX845OnUAvXZZOZABaeXsUEqkQRJ7aXFQlcyMznMEx0w3U8 thp6VWtA2SlgcJmKk4nbTd06UHyoJY1XxSGR+OyRnICxS6grWC9UoBx2gXxMUmOG 9ib4yHKwD1EIUzNl4Cq18MQPUgh7UZ9/t1rWDcuVOBBeYtOGYamFTw== =KwxL
- -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQA7OnzBkNMiD99JrAQKWyAgAouLPJ0cYHWBEySFPkRrnyXxVeVvJJsU1 kSe+WmD9d1a6aZyMZbqo2XkQb3+SP4aTYwBBv1oX9ZrKT02EkzRvGoxX1wvGmYBG Tp+l36e4YdVht3369Xl9qWrOvIvrX+3GcL0jXpY4M7B93FSwaeQr95Qy16k3g/mv 065AxzmR+d6d+rZQvmb271/JNFxDuc3GptuILgPueDsq3oakovq2cPkZBYcf+qcq bn92bkJiPgTVsT7TGBljP2+Zra586f57+i/96A0n1MntGUHkGfvs3IfvDNhz7Gua /nf2u2xlBNMaTynccIsvFI73C2rrDAsk/YeMEbgV/+adTPL+Y0Fmzg== =hOY/
-----END PGP SIGNATURE-----

Daniel Egger wrote:

On Jan 20, 2004, at 5:48 pm, Sven Neumann wrote:

Well, actually we'd like to add interpolation to the GIMP canvas as well. At least optionally. Modern computer hardware seems fast enough to do this, especially when one takes advantages of CPU acceleration features (MMX, SSE, ...). Perhaps someone wants to tackle this task for GIMP-2.2?

In OSX many applications tend to provide a quick redraw for pannings but start a timer which will refine the display once it was static for a while.

Hee hee... it's interesting how things can come full-circle. GIMP 0.5[34] did something very similar to provide a quick-render for interactive operations, re-rendering the results more nicely on the idle thread (undithered vs. dithered rather than aliased vs. interpolated, but for the same reasons).

--Adam

Am Mit, den 21.01.2004 schrieb Adam D. Moss um 20:28:

In OSX many applications tend to provide a quick redraw for pannings but start a timer which will refine the display once it was static for a while.

Hee hee... it's interesting how things can come full-circle. GIMP 0.5[34] did something very similar to provide a quick-render for interactive operations, re-rendering the results more nicely on the idle thread (undithered vs. dithered rather than aliased vs. interpolated, but for the same reasons).

This would be my favourite solution rather than hope that the CPU is fast enough and someone wrote optimized code just to render a view that a human eye won't be able to trace in real-time anyway.