|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The +Fpg / +Fng switch should result in a 16 bit grey scale image. It only
renders to 8 bit.
Adding +Fp16 / Fn16 does nothing as stated in the docs.
When rendering a gradien I only get 254 colors, instead of the 256 that
shoud be there for 8-bit.
3.8 beta on win10.
Cheers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/16/21 1:47 PM, ingo wrote:
> The +Fpg / +Fng switch should result in a 16 bit grey scale image. It only
> renders to 8 bit.
> Adding +Fp16 / Fn16 does nothing as stated in the docs.
>
> When rendering a gradien I only get 254 colors, instead of the 256 that
> shoud be there for 8-bit.
>
> 3.8 beta on win10.
>
> Cheers.
>
The bits per color change in v3.8 made it so the default greyscale depth
is 8. The documentation should indicate this up where Bits_Per_Color=n
gets documented at least.
The documentation does have:
"Previously, specifying a bit-depth for grayscale file output was simply
ignored and the bit-depth was forced to 16 bits per channel. A Change in
version 3.8 now allows for a bit-depth setting."
I'm on Ubuntu working of the v3.8 master commit and the channel depth
options work for me in both color and grey scale(1) with both png and
ppm outputs.
Could you run a quite experiment? The ppm format supports an ascii
output. Grab a simple scene file. Run:
povray scn.pov +w80 +h80 +fpg8 File_gamma=1.0 Compression=0 +ofpg8
and
povray scn.pov +w80 +h80 +fpg16 File_gamma=1.0 Compression=0 +ofpg16
then:
Edit both files in a text editor. The difference in encoding should be
obvious.
--- Bug
(1) - What doesn't appear to be working is the intended and documented
change for ppm (aka pgm) greyscale output. In my testing the output is
still always linear (color output is using bt709). Basically the
following documented change isn't working:
"Previously, the grayscale PPM (technically PGM) output file format
always used linear output. A Change in v3.8 will match that of the
regular non-grayscale PPM format. That is File_Gamma will be honored if
specified, otherwise the ITU-R BT.709 gamma transfer function will be
applied."
In fact, I cannot override the greyscale File_Gamma... It should be
working as does the .png grey scale output, but with the bt709 transfer
function, unless the output File_Gamma is set to 1.0 (linear).
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:6051fb4b$1@news.povray.org William F Pokorny wrote:
> bits per color
Sorry, don't kow what I did wrong. Brain glitch? Seems to work fine.
You seem to be right on the gamma problem.
The wrong file extension is a minor nitpick.
Thanks,
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/17/21 8:51 AM, William F Pokorny wrote:
> On 3/16/21 1:47 PM, ingo wrote:
...
>
> --- Bug
...
>
Summary. Three issues found as a side effect of checking the v3.8 bit
depth feature.
A link to a more detailed thread given the web forums/news interface is
restored:
http://news.povray.org/povray.beta-test/thread/%3C60563168%241%40news.povray.org%3E/
---
1) In v3.8. Greyscale ppm/pgm output not respecting the File_Gamma
setting. Not a feature of v3.7.
2) In v3.8. The png sRGB chunk is not output unless the File_Gamma is
set to srgb though the default output uses srgb. Default png write and
immediate read won't match exactly. Release v3.7 looks OK to quick tests.
3) In v3.7 and v3.8. Incorrect greyscale png file input where bit
storage depth <= 8 and input is non-linear (gamma!=1). In v3.8 this the
default png greyscale write and read.
Aside: On the web view I currently see a mistaken, partial
povray.beta-test news post with the suffix part 1, which I immediately
deleted from Thunderbird. Please ignore it for the more recent and
complete thread.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |