Hi,
You're right: implementing constants somewhere in a circuit is very
unwise,
but then: that's not what I meant to propose ...
Since gamma correction is a tricky function from signal processing point
of
view (non-linear, therefore generating spectral horror), and furthermore -
and this is the actual rationale- you surely would like to tune this
transfer function to see what performance improvement a tiny little gamma
change could bring.
To create that flexibility I suggested (I admit: not explicitely) to
implement a programmable structure, in which you only input the steepness
of
the subsequent sections of a piecewise linear function in hardware. Excel
only helps to get a quick impression of the range of gain factors for each
section that would be fine.
This function is really easy to implement, and offers a lot of
flexibility.
Note that the gain factors for each section can in a later stage also be
fixed in a lookup table.
The main difference between the solution you proposed and what I
suggested,
is the amount of points that define the transfer funtion: a full look-up
table or a limited table with gain factors in between which linear
interpolation is done by hardware.
Your solution has one more advantage over mine: Suppose the initial poster
wants to process RGB signals, then one table can serve all three channels.
cheers,
Maarten
"KJ" <kkjennings@[EMAIL PROTECTED]
> schreef in bericht
news:76741322-2bdb-463d-9e2f-cdf4df6de0b1@[EMAIL PROTECTED]
Jun 30, 3:43 pm, "Maarten" <no_one@[EMAIL PROTECTED]
> wrote:
> Hi,
> Alternatively you could consider to program a piece-wise-linear transfer
> function; By limiting the numberof gain factors (i.e. degreeof freedom
in
> choice for steepness) to a set say {4*,2*, 1* , 1.125*, 1.25*, 1.5*} you
> can replace multipliers by a number of ****ft-and-add functions, which
> results in a compact and fast (since its most probably video, you should
I think you're missing my point that all of the calculation stuff can
be done in a function that produces a constant. That constant is a
lookup table array. No multipliers, log/exp functions, etc. would be
synthesized.
Functionally, and from a synthesis perspective, it's absolutely no
different than if you were to use Excel to compute the lookup table
values and copy/paste them into your code. The difference is in the
maintainability of the design.
If you go the copy/paste route though your HDL design contains an
array of 'magic' numbers for the lookup table entries that (hopefully)
have some reference back to the Excel spreadsheet that generated
them...and hopefully nobody accidentally changes any of the values
when doing a search/replace operation.
If you go the route of having your HDL compute the lookup table
entries directly then the HDL has a fairly short, easy to read
function that (should) look very close to the true source equations
that define the mapping.
Functions to compute constants are not shackled with the same
constraints that apply to signals.
Kevin Jennings
|
