Finally, actually reading a PGM file in VHDL

And so, finally, [after all that setup](/node/65), some code [to read PGM files](/node/66/) and [how to make use of it](/node/67/). Next stage will be writing some files!

As always, the code can be [found on github](http://github.com/martinjthompson/image_processing_examples/hdl)

Reading image files with VHDL part 3

[Having written a function](/node/66/) to read a PGM image, how do we use it?

Well, the testbench at the bottom of the pgm vhdl file has an example:
[vhdl]
variable i : pixel_array_ptr;
— Without the transpose function, we would have to present the initialisation data in a non-intuitive way.
constant testdata : pixel_array(0 to 7, 0 to 3) := transpose(pixel_array'(
(000, 027, 062, 095, 130, 163, 198, 232),
(000, 000, 000, 000, 000, 000, 000, 000),
(255, 255, 255, 255, 255, 255, 255, 255),

Reading image files with VHDL part 2

Having [set up a library](/node/65/) for reading images, let’s now go on to read an image in!

pgm_read
========

Recall, we have a function:
[vhdl]
impure function pgm_read (filename : string)
return pixel_array_ptr;
[/vhdl]

So, some declarations – fairly self-explanatory:
[vhdl]
file pgmfile : text;
variable width, height : coordinate; — storage for image dimensions
variable l : line; — buffer for a line of text
variable s : string(1 to 2); — to check the P2 header

Reading image files with VHDL part 1 (again)

Data storage
============
One things VHDL can do ([contrary to popular belief :)](/node/60/)) is 2-D arrays. So reading images into a 2-D array is a very natural way to store the data.

We’ll create a package called `pgm` to keep all our image reading and writing code together:

[vhdl]
package pgm is
subtype coordinate : natural;
subtype pixel is integer range 0 to 255;
type pixel_array is array (coordinate range <>, coordinate range <>) of pixel;
type pixel_array_ptr is access pixel_array;
— Function: transpose

libv – assert_equal, str, etc.

The `assert_equal` functions are part of my library of useful things (maybe this could be a start towards [VHDL’s jQuery](http://www.tekphile.com/2010/12/where-is-vhdls-jquery/) :) `libv`. Why not just use `assert` as is? Well, it’s useful to report all assert results in the same fashion, particularly to include the values that you expected and what you tested, along with the difference between them – often this is useful debugging information.

Here’s an example….

Oops

It’s been very kindly pointed out to me via email (by Tricky) that I was talking complete rubbish saying that [VHDL is rubbish at 2d arrays](/node/60/).

What I should’ve said was “VHDL is rubbish at arrays of other arrays”, which is a subtle but critical difference! Arrays of other arrays are very useful (for example in register files), and the fact that the dimensions of one of the arrays must be known at compile time can make some things tricky to impossible. For example, a generic mux with a variable number of inputs can’t easily also have a generic number of bits on each input.

Reading image files in VHDL

Next up in the image processing series – [reading image files in VHDL](/node/60). This allows our testbenches to operate on real image data. After this we can create a camera model which will produce the pixels and synchronisation signals like a real camera so that we can do complete image tests of a processing pipeline.

Reading image files with VHDL part 1


Please note that this page talks rubbish – [here’s why](/node/62), and [here’s a better version](/node/65).

If we’re going to do some image processing in VHDL, we’re going to need to be able to read images in to our simulations. VHDL’s file handling is pretty poor to say the least, so we’ll keep things simple by only handling a very simple file format – namely [Portable Greymap (PGM)](http://netpbm.sourceforge.net/doc/pgm.html). And for even more simplicity we’ll handle on one variant with 8-bit pixels (P2 format with Maxval<256).