Does anyone else think it would be a good idea to have an option to produce 
dithered output?  If your scene consists of colour gradients between two 
close colours, or two greys, even in 24bpp format you can often still see 
"banding".  Using some sort of dithering scheme in the output would vastly 
improve images like this, and would be quite simple to implement.  I just 
wonder how the dithering would be handled across block borders between 
different threads, maybe the thread stores float/double precision pixels and 
then the final "block assembler/file writer" code will perform the dithering 
on the whole image?

Just an idea.

Post a reply to this message

scott wrote:
> Does anyone else think it would be a good idea to have an option to 
> produce dithered output?  If your scene consists of colour gradients 
> between two close colours, or two greys, even in 24bpp format you can 
> often still see "banding".  Using some sort of dithering scheme in the 
> output would vastly improve images like this, and would be quite simple 
> to implement.  I just wonder how the dithering would be handled across 
> block borders between different threads, maybe the thread stores 
> float/double precision pixels and then the final "block assembler/file 
> writer" code will perform the dithering on the whole image?
> 
> Just an idea.
> 
> 

I think crand can accomplish this, although it isn't applied scene-wide, but to
specific textures.

Post a reply to this message

This sounds like something you could write with a generic post-processing
script (which future versions of POV-Ray should and will most probably
support).

-- 
                                                          - Warp

Post a reply to this message

scott wrote:
> Does anyone else think it would be a good idea to have an option to 
> produce dithered output?  If your scene consists of colour gradients 
> between two close colours, or two greys, even in 24bpp format you can 
> often still see "banding".  Using some sort of dithering scheme in the 
> output would vastly improve images like this, and would be quite simple 
> to implement.  I just wonder how the dithering would be handled across 
> block borders between different threads, maybe the thread stores 
> float/double precision pixels and then the final "block assembler/file 
> writer" code will perform the dithering on the whole image?
> 
> Just an idea.
> 
> 

I think crand can accomplish this, although it isn't applied scene-wide, but to
specific textures.

Post a reply to this message

Warp wrote:
>   This sounds like something you could write with a generic post-processing
> script (which future versions of POV-Ray should and will most probably
> support).
> 

I thought dithering had to know the exact value of a color so, for constant color, it
could cycle between discretized colors with a weighting depending on how close the
actual color is to each.  (for graded colors, it's slightly more complicated).  This
can't be done post-processing, by which point the precision has already been lost.

Dan

Post a reply to this message

Dan Connelly <djc### [at] yahoocom> wrote:
> Warp wrote:
> >   This sounds like something you could write with a generic post-processing
> > script (which future versions of POV-Ray should and will most probably
> > support).
> > 

> I thought dithering had to know the exact value of a color so, for constant color,
it could cycle between discretized colors with a weighting depending on how close the
actual color is to each.  (for graded colors, it's slightly more complicated).  This
can't be done post-processing, by which point the precision has already been lost.

  The floating point values of each color component of each pixel will,
obviously, be available to the post-processing filter.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   The floating point values of each color component of each pixel will,
> obviously, be available to the post-processing filter.

Ahh!  Apologies.  I thought you meant "post-processing" as in Gimp or ImageMagick.

Post a reply to this message

>>   The floating point values of each color component of each pixel will,
>> obviously, be available to the post-processing filter.
>
> Ahh!  Apologies.  I thought you meant "post-processing" as in Gimp or 
> ImageMagick.

OOC, does the current HDR output format contain the full precision pixels? 
If so, I could just write a program to generate a dithered 24bit bitmap from 
the HDR file?

Post a reply to this message

Dan Connelly <djc### [at] yahoocom> wrote:
> Warp wrote:
> >   The floating point values of each color component of each pixel will,
> > obviously, be available to the post-processing filter.

> Ahh!  Apologies.  I thought you meant "post-processing" as in Gimp or ImageMagick.

  I meant post-processing. Just because the post-processing filter has more
than the 8 bits-per-channel information to handle doesn't make it an less
post-processing.

-- 
                                                          - Warp

Post a reply to this message

Dan Connelly wrote:
> I thought dithering had to know the exact value of a color so, for
> constant color, it could cycle between discretized colors with a weighting
> depending on how close the actual color is to each.  (for graded colors,
> it's slightly more complicated).  This can't be done post-processing, by
> which point the precision has already been lost.

POV-Ray can already create 48-bit PNG images. You could post-process that to
generate a dithered 24-bit image.

Post a reply to this message