 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167
Primary feature of this update is the addition of blue noise dithering.
Blue noise dithering is a comparatively new ordered dithering algorithm,
using a tiling pattern to vary the quantization threshold. However,
unlike the extremely regular pattern used in the otherwise similar Bayer
dithering, the pattern used in blue noise dithering is constructed to be
extremely irregular at small scales, while at the same time being
extremely regular at large scales. In other words, it has a lot of
high-frequency noise, while at the same time having very little
low-frequency noise.
The pattern used by POV-Ray is a hard-coded 64x64 pattern, generated
using a so-called void-and-cluster approach (utilizing a public domain
Python script by - as it happens - fellow "Rheinlandian", 3D enthusiast
and namesake Christoph Peters).
Due to its high quality and ease of use, blue noise dithering is now the
default algorithm, and is also used in the preview window, replacing the
inferior Bayer dithering there.
The blue noise dithering comes in two variants: Aside from a
straightforward implementation (`+THbn`) where the threshold of all
channels is varied according to the same pattern, an experimental
implementation is available (`+THbnx`) in which the threshold for the
red and blue channels is varied according to the inverse of the pattern,
to reduce the noise in the brightness domain (at the cost of more noise
in the chromaticity domain).
In the wake of this, ...
- A couple more error diffusion dithering filters have been added
(primarily for giggles and because we can). See
povray.documentation.inbuilt, recent thread "Some stuff related to
output file formats" for details.
- The lower limit for the bit depth (previously 5) has been dropped;
anything between 1 and 16 is fair game now (affects PNG and PPM/PGM
only; again, mostly for giggles, to better demonstrate dithering, but
maybe some of you folks may want to experiment with it).
- Greyscale output no longer forces bit depth to 16 (also primarily for
dithering demonstration purposes).
- Greyscale file output now also switches the preview window to greyscale.
- The `+F` option can now be used to specify both greyscale (`g` suffix)
and non-default bit depth (numeric suffix) simultaneously. (The `g` must
come first.)
- Gamma handling in PGM (greyscale "PPM") files has been changed to be
consistent with colour PPM.
- Gamma handling in dithering has been improved.
I /think/ that's all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-09-30 à 23:48, clipka a écrit :
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167
>
>
> Primary feature of this update is the addition of blue noise dithering.
>
> Blue noise dithering is a comparatively new ordered dithering algorithm,
> using a tiling pattern to vary the quantization threshold. However,
> unlike the extremely regular pattern used in the otherwise similar Bayer
> dithering, the pattern used in blue noise dithering is constructed to be
> extremely irregular at small scales, while at the same time being
> extremely regular at large scales. In other words, it has a lot of
> high-frequency noise, while at the same time having very little
> low-frequency noise.
>
> The pattern used by POV-Ray is a hard-coded 64x64 pattern, generated
> using a so-called void-and-cluster approach (utilizing a public domain
> Python script by - as it happens - fellow "Rheinlandian", 3D enthusiast
> and namesake Christoph Peters).
>
> Due to its high quality and ease of use, blue noise dithering is now the
> default algorithm, and is also used in the preview window, replacing the
> inferior Bayer dithering there.
>
>
> The blue noise dithering comes in two variants: Aside from a
> straightforward implementation (`+THbn`) where the threshold of all
> channels is varied according to the same pattern, an experimental
> implementation is available (`+THbnx`) in which the threshold for the
> red and blue channels is varied according to the inverse of the pattern,
> to reduce the noise in the brightness domain (at the cost of more noise
> in the chromaticity domain).
>
>
> In the wake of this, ...
>
> - A couple more error diffusion dithering filters have been added
> (primarily for giggles and because we can). See
> povray.documentation.inbuilt, recent thread "Some stuff related to
> output file formats" for details.
>
> - The lower limit for the bit depth (previously 5) has been dropped;
> anything between 1 and 16 is fair game now (affects PNG and PPM/PGM
> only; again, mostly for giggles, to better demonstrate dithering, but
> maybe some of you folks may want to experiment with it).
>
> - Greyscale output no longer forces bit depth to 16 (also primarily for
> dithering demonstration purposes).
>
> - Greyscale file output now also switches the preview window to greyscale.
>
> - The `+F` option can now be used to specify both greyscale (`g` suffix)
> and non-default bit depth (numeric suffix) simultaneously. (The `g` must
> come first.)
>
> - Gamma handling in PGM (greyscale "PPM") files has been changed to be
> consistent with colour PPM.
>
> - Gamma handling in dithering has been improved.
>
>
> I /think/ that's all.
>
I no longer see the post render info when using isosurfaces with
improper max_gradient.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 04.10.2018 um 17:53 schrieb Alain:
> I no longer see the post render info when using isosurfaces with
> improper max_gradient.
Can you provide a sample scene, and what exactly you'd expect?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18-10-05 à 11:08, clipka a écrit :
> Am 04.10.2018 um 17:53 schrieb Alain:
>> I no longer see the post render info when using isosurfaces with
>> improper max_gradient.
>
> Can you provide a sample scene, and what exactly you'd expect?
>
#version 3.8;
global_settings{assumed_gamma 1}
#declare tip = function(Vert) { sqrt(6.25 - pow(Vert,2)) - 1.5 }
#declare rad = function(H) {(H*H+1) / max(H,1e-6) / 2}
#declare hgt = function(x,R,H) { sqrt(pow(R,2) - pow(x,2)) + H - R }
#declare hght= function(x,H) { hgt(x, rad(H), H) }
#declare height=function(x,y) { hght(x, tip(y+1)) }
#declare OBJ=isosurface {
function { z * (z - hght(x, tip(y+1))) }
threshold 0
//max_gradient 9 // the original
max_gradient 1 // for this test
contained_by {box {<-1,-1,0>, <1,1,1>}}
}
object{OBJ pigment{rgb <1,0.5,0.3>}}
camera{location -7*z look_at 0}
light_source{<25,25,-25> rgb 1}
I expected some message about the max_gradient found to be around 9 but
set at 1.0.
The resulting image show obvious holes.
But, I don't get any message after the render is complete.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.10.2018 um 20:33 schrieb Alain:
> I expected some message about the max_gradient found to be around 9 but
> set at 1.0.
> The resulting image show obvious holes.
>
> But, I don't get any message after the render is complete.
Can't reproduce:
- I only see an (almost perfect) clay-brown slab, even with the
max_gradient 1 setting. No holes for me.
- Previous versions (tested with v3.7) do not produce a max_gradient
warning for this scene either. [*]
- When I set max_gradient even lower (0.1), I do get holes, but I also
do get a warning with alpha.9861167. [*]
- The reported maximum gradient found is 0.990, not around 9.
[* Fun side note: At a max_gradient setting of 0.1, it is POV-Ray v3.7
that fails to issue a warning.]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5-10-2018 20:33, Alain wrote:
> Le 18-10-05 à 11:08, clipka a écrit :
>> Am 04.10.2018 um 17:53 schrieb Alain:
>>> I no longer see the post render info when using isosurfaces with
>>> improper max_gradient.
>>
>> Can you provide a sample scene, and what exactly you'd expect?
>>
>
> #version 3.8;
> global_settings{assumed_gamma 1}
> #declare tip = function(Vert) { sqrt(6.25 - pow(Vert,2)) - 1.5 }
> #declare rad = function(H) {(H*H+1) / max(H,1e-6) / 2}
> #declare hgt = function(x,R,H) { sqrt(pow(R,2) - pow(x,2)) + H - R }
> #declare hght= function(x,H) { hgt(x, rad(H), H) }
> #declare height=function(x,y) { hght(x, tip(y+1)) }
>
> #declare OBJ=isosurface {
> function { z * (z - hght(x, tip(y+1))) }
> threshold 0
> //max_gradient 9 // the original
> max_gradient 1 // for this test
> contained_by {box {<-1,-1,0>, <1,1,1>}}
> }
>
> object{OBJ pigment{rgb <1,0.5,0.3>}}
> camera{location -7*z look_at 0}
> light_source{<25,25,-25> rgb 1}
>
> I expected some message about the max_gradient found to be around 9 but
> set at 1.0.
> The resulting image show obvious holes.
>
> But, I don't get any message after the render is complete.
>
>
> Alain
Isn't this the typical "naked" isosurface syndrome? i.e. a #declared
isosurface do /not/ show warning messages, simply provide the isosurface
as-is, does instead.
Try instead, without the #declare:
isosurface {
function { z * (z - hght(x, tip(y+1))) }
threshold 0
//max_gradient 9 // the original
max_gradient 1 // for this test
contained_by {box {<-1,-1,0>, <1,1,1>}}
pigment{rgb <1,0.5,0.3>}
}
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/05/2018 03:04 PM, clipka wrote:
> Am 05.10.2018 um 20:33 schrieb Alain:
>
>> I expected some message about the max_gradient found to be around 9 but
>> set at 1.0.
>> The resulting image show obvious holes.
>>
>> But, I don't get any message after the render is complete.
>
> Can't reproduce:
>
> - I only see an (almost perfect) clay-brown slab, even with the
> max_gradient 1 setting. No holes for me.
>
> - Previous versions (tested with v3.7) do not produce a max_gradient
> warning for this scene either. [*]
>
> - When I set max_gradient even lower (0.1), I do get holes, but I also
> do get a warning with alpha.9861167. [*]
>
> - The reported maximum gradient found is 0.990, not around 9.
>
>
> [* Fun side note: At a max_gradient setting of 0.1, it is POV-Ray v3.7
> that fails to issue a warning.]
>
I do see a few apparent holes (no AA) in the upper let corner for
example, but otherwise agree with Christoph.
I think the bounding is off with z low being zero:
contained_by {box {<-1,-1,0>, <1,1,1>}}
In other words, I think the function is mostly being clipped so we are
seeing a slice of the function's "inside" and which on that slice is
noisy at the edges. Change that zlow bounding 0 to -1, for example, and
you'll get gradient warnings for the max gradient of 1.
Aside 1: Another way to clean up the edges in the clipped (zlow=0) case
is to crank the accuracy way up so the clipped inside resolves more
cleanly at the edges. Say maybe 0.00005 or less.
Aside 2: IIRC there is still a thread collision in the current
implementation (which Thomas, in 3.8 no longer needs to be "naked"
thanks to Christoph's updates) - meaning you are not guaranteed to see
the very worst found gradient. In practice it's close. Practical
implication is you need to bump any reported max a little for the
setting not so much for result, but to be sure some later render doesn't
report a slightly larger gradient just due the internal ordering of
stuff.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6-10-2018 13:14, William F Pokorny wrote:
> Aside 2: IIRC there is still a thread collision in the current
> implementation (which Thomas, in 3.8 no longer needs to be "naked"
> thanks to Christoph's updates) - meaning you are not guaranteed to see
> the very worst found gradient. In practice it's close. Practical
> implication is you need to bump any reported max a little for the
> setting not so much for result, but to be sure some later render doesn't
> report a slightly larger gradient just due the internal ordering of stuff.
>
Good! Progress passing me by :-)
Thanks for the info.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymous org> wrote:
> https://github.com/POV-Ray/povray/releases/tag/v3.8.0-alpha.9861167
playing around with some code, I get:
File 'tstlq.pov' line 40: Parse Error: Tried to free undefined symbol
Fatal error in parser: Cannot parse input.
the problem is, the file ends at line 39. :-) line 38 contains an
'#undef' which destroys a variable '#declare'd in same file.
archive with scene to same email?
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.10.2018 um 16:16 schrieb jr:
> File 'tstlq.pov' line 40: Parse Error: Tried to free undefined symbol
> Fatal error in parser: Cannot parse input.
>
> the problem is, the file ends at line 39. :-) line 38 contains an
> '#undef' which destroys a variable '#declare'd in same file.
>
> archive with scene to same email?
>
> regards, jr.
The usual procedure, yes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
