The current display related options:

+-d     display
+-th    dither  (Same settings used for file output)
         dither_method (strings as below)
         display_gamma (srgb|bt709|bt2020|value)
-y, --preview
+-p     pause_when_done
+-ep    preview_end_size
+-sp    preview_start_size

become:

+-d     display                    =on|off
+-da    display_alpha              =on|off            NEW
+-dbpc  display_bits_per_channel   integer value only NEW
+-dd    display_dither             on|off             NEW
+-ddm_  display_dither_method      string  value only NEW
           (b2|b3|b4|bn|bnx|at|bk|d1|d2|fs|jn|s2|s3|st)
+-dgc_  display_gamma_curve        string  value only NEW
           (srgb|bt709|bt2020|linear|power)
+-dgv   display_gamma_value        float   value only NEW
+-dgm_  display_gry_method         string  value only NEW
           (ci111,ci240,ci601,ci709,ci2020)
+-dgs   display_gry_scale          on|off             NEW
+-dm_   display_method             string  value only NEW
           (x11,sdl,text)
+-dp    display_pause              on|off             NEW
+-dpes  display_preview_end_size   integer on|off Value NEW
+-dpss  display_preview_start_size integer on|off Value NEW
+-ds    display_stdout             on|off               NEW PLAY

Initially I'll be mapping the above options back to existing 
functionality. Setting up here for the longer term.

Aims / thinking :

- The alpha setting should show in the preview window too, but it's not 
happening today. (Change here likely tangled in how partial image 
renders are handled too with respect to image parts outside the partial)

- Setting up for a much more independent preview display module.

- Align the 'module' options reasonably well with an output (punch) 
module option set.

- The gamma / dither options are relatively costly, especially, where 
the frame renders are quick.

- Dithering for a preview display might well be different than that used 
for file output headed to a printer.

- Setting up more generally for other additional correction curves (wide 
gamut) with more value inputs.

- The preview display module/work could more easily use available gpus. 
Other open source software is doing this.

- We have stdout (pipe out) capability today with the overloaded +o- 
syntax, but thinking an implementation less tangled is better.

- The preview start and end stuff is really used only by the radiosity 
code today. With modern computers there isn't much need for this sort of 
mosaic preview. Capturing mosaic previews, however, is probably useful. 
No options for this are defined as yet - though I have some ideas.

- The different grey conversions are configurable as build options today 
in the yuqk code base. Plus, yuqk in using rgb channel intensities from 
bt709 as the default configuration differs from the channel intensities 
used by official POV-Ray which are near CCIR Recommendation 601-1, but 
different. There are too wide gamut flavors out there, but not yet in 
any POV-Ray version of which I'm aware.

- Thinking some about options for setting initial preview sizes 
differing from the image size. Maybe window positioning too. Early 
versions of POV-Ray had support for these as X11 based options.

- Thinking about a -into <window id> X11 capability. (About multiple 
intos from multiple cameras truth be told... Using POV-Ray for cheap and 
easy GUIs, but dreaming or having nightmares - not sure)


Code wise the parsing is mostly there, but nothing is wired up.

Bill P.

Post a reply to this message