Gamma Correction VHDL Core

[Martin Sauer]

Hi,

I'm looking for a gamma correction vhdl code. Do anything know about
such cores?

thank you for your answer

bye

martin sauer

 

[KJ]

On Jun 30, 9:33 am, Martin Sauer <m...@displaign.de> wrote:

Hi,

I'm looking for a gamma correction vhdl code. Do anything know about
such cores?

thank you for your answer

bye

martin sauer

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

 

[KJ]

On Jun 30, 3:43 pm, "Maarten" <no_one@nowhere> 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 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