Gamma Correction VHDL Core
Martin Sauer
I'm looking for a gamma correction vhdl code. Do anything know about
such cores?
thank you for your answer
bye
martin sauer
KJ
I'd suggest the following:
1. Go to Wikipedia for the fundamental equations for gamma correction
(unless you know them already).
2. Realize that to implement such a function you only need a lookup
table for whatever your input data width is (i.e. 8 bit video = 256
entry table).
3. Write a simple VHDL function to compute the above mentioned table.
In order to do this for gamma correction, you'll see that you need log
and powers and real number computations. While you can't syntheize
type real for 'signals' you can use type real to compute 'constants'
which is what you're trying to do here. For a related example that
demonstrates this see the link below or Google for "Sample code to
compute an sRGB->RGB conversion lookup table" in which case you should
run across the posting that I did that shows this.
http://groups.google.com/group/comp.lang.vhdl/browse_frm/thread/b2e4be6480069641?hl=en#
Kevin Jennings
Maarten
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 shift-and-add functions, which
results in a compact and fast (since its most probably video, you should
appreciate that) solution.
I'd suggest youtry and play in Excel first to find a proper compromise
between accuracy and complexity, then step to an HDL implementation.
Cheers,
Maarten
"KJ" <kkjen...@sbcglobal.net> schreef in bericht
news:8c05a7c1-e730-4ee0...@d77g2000hsb.googlegroups.com...
KJ
> 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 shift-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
Maarten
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" <kkjen...@sbcglobal.net> schreef in bericht
news:76741322-2bdb-463d...@m36g2000hse.googlegroups.com...