The current render related options:

+-rp render_pattern
+-rs render_block_step
+-bs render_block_size
+-c  continue_trace
+-cc create_continue_trace_log
+-ec end_column    (pct and integer specs)
+-er end_row       (pct and integer specs)
+-sc start_column  (pct and integer specs)
+-sr start_row     (pct and integer specs)
      (Single, hard coded color conversion to gry)

become:

+-r     render                 on|off               NEW
+-rp    render_pattern         integer value only
+-rbstp render_block_step      integer value only
+-rbsz  render_block_size      integer value only
+-rc    render_continue        on|off
+-rcl   render_continue_log    on|off
+-rec   render_end_column      integer on|off plus value
+-rer   render_end_row         integer on|off plus value
+-rsc   render_start_column    integer on|off plus value
+-rsr   render_start_row       integer on|off plus value
+-rgm_  render_gry_method      string  value only  NEW
           (ci111,ci240,ci601,ci709,ci2020)

Aims / thinking :

- Mostly renaming.

- Adding flag indicating whether or not to run the render stage/module.

- Removing the percentage specifications for the start/end/col/row 
options. I "think" the yuqk fork fixed the last of the bugs due trying 
to accommodate the percentages and numbers on the same flag, but the 
code remains ugly. If it's decided later this feature essential, another 
set of flags which specifically supports it should be added.

- Biggest planned change is making the render/tracing color conversions 
to grey select-able at render time. Including here perhaps a development 
mode hard coding a dummy value - or, maybe, using the green channel 
directly. Maybe look too, at something better than our current grey 
weighted 'conserve_energy', for example.

- Off on the horizon is perhaps moving away from / extending or changing 
the render block mechanism. Thinking about optimizations for the 
'locality of references' and maybe a mode which skips blocks if they 
exceeds some multiple of all the average time used to render blocks thus 
far. I have in mind too multiple camera driven over-sampling methods 
which won't work with the current render blocks mechanism. Dreaming...

Code wise, the parsing code itself for these is only partly done.

Bill P.

Post a reply to this message