diff --git a/website/raw/docs/compile.mkdown b/website/raw/docs/compile.mkdown
index f26c10c04e8af008026a10d7e3aa13599c441a2a..56fe8da3b9d7d7524e065f67eb1f17120bd568f4 100644
--- a/website/raw/docs/compile.mkdown
+++ b/website/raw/docs/compile.mkdown
@@ -15,7 +15,7 @@ OpenStructure uses a bunch of OpenSource libraries. If you haven't already insta
* [Python](http://python.org)
* [Qt](http://qt.nokia.com/)
-When you enable IPLT support, you will need:
+When you enable support for image processing, you will need:
* [FFTW3](http://fftw.org). By default, OpenStructure is compiled with single precision and thus also requires FFTW to be compiled with single precision. Most platforms offer this as a second package. If you are compiling manually, use the `--enable-single` option.
@@ -75,7 +75,7 @@ By default, [CMake] searches the standard directories for dependencies. However,
### Flags that control the build
* `ENABLE_UI` controls whether to build the graphical user interface module. By default it is set to true.
- * `ENABLE_IPLT` controls whether to build the image processing module. This will enable support for density maps, and general image processing in 1, 2 an 3 dimensions. By default it is set to true.
+ * `ENABLE_IMG` controls whether to build the image processing module. This will enable support for density maps, and general image processing in 1, 2 an 3 dimensions. By default it is set to true.
* `ENABLE_GFX` controls whether to build the graphics module. By default, this is set to true. If set to none, this implies `ENABLE_UI=NO`.
* Shader support is controlled with `USE_SHADER`. By default, no shaders are used.
* If `OPTIMIZE` is set to 1, an optimized version of OpenStructure is built.
diff --git a/website/raw/docs/tut/giplt1.jpg b/website/raw/docs/tut/dv1.jpg
similarity index 100%
rename from website/raw/docs/tut/giplt1.jpg
rename to website/raw/docs/tut/dv1.jpg
diff --git a/website/raw/docs/tut/giplt2.jpg b/website/raw/docs/tut/dv2.jpg
similarity index 100%
rename from website/raw/docs/tut/giplt2.jpg
rename to website/raw/docs/tut/dv2.jpg
diff --git a/website/raw/docs/tut/giplt3.jpg b/website/raw/docs/tut/dv3.jpg
similarity index 100%
rename from website/raw/docs/tut/giplt3.jpg
rename to website/raw/docs/tut/dv3.jpg
diff --git a/website/raw/docs/tut/ipltalg.mkdown b/website/raw/docs/tut/imgalg.mkdown
similarity index 70%
rename from website/raw/docs/tut/ipltalg.mkdown
rename to website/raw/docs/tut/imgalg.mkdown
index 1ad6a4694b574119a85b8e18a65c8f0f33cb5f41..82918fcfda12511546d2625d351e39b23eb2c096 100644
--- a/website/raw/docs/tut/ipltalg.mkdown
+++ b/website/raw/docs/tut/imgalg.mkdown
@@ -11,9 +11,9 @@ To allow various image manipulation routines that are decoupled from the actual
image implementations, an extensive set of algorithm base classes is provided to facilitate
the implementation of novel algorithms.
-The 'iplt' module is using the concept of algorithm objects: In order to apply an algorithm
+The 'img' module is using the concept of algorithm objects: In order to apply an algorithm
to an image, an instance of that particular algorithm class must be created, which
-is then passed to one of the various Apply methods of the dox[ost::iplt::ImageHandle|ImageHandle]
+is then passed to one of the various Apply methods of the dox[ost::img::ImageHandle|ImageHandle]
interface. This extends the possibilities of algorithms beyond what is possible with simple
function calls.
@@ -23,36 +23,36 @@ Five different types of algorithms can be identified:
### NonMod
An algorithm that will not modify the values in the image, but rather gather
-some data. Example: a histogram. Implemented as dox[ost::iplt::NonModAlgorithm|NonModAlgorithm].
+some data. Example: a histogram. Implemented as dox[ost::img::NonModAlgorithm|NonModAlgorithm].
### ModIP
An algorithm that will modify the image values directly in place; in addition,
it may choose to write to its internal state during application of the algorithm.
-Implemented as dox[ost::iplt::ModIPAlgorithm|ModIPAlgorithm].
+Implemented as dox[ost::img::ModIPAlgorithm|ModIPAlgorithm].
### ConstModIP
Similar to ModIP, this algorithm will modify the values directly in place.
However, it does not need to store information itself beyond the application of the algorithm
itself. Example: setting all image values to zero. Implemented as
-dox[ost::iplt::ConstModIPAlgorithm|ConstModIPAlgorithm].
+dox[ost::img::ConstModIPAlgorithm|ConstModIPAlgorithm].
### ModOP
An algorithm that will return a new, modified version of the image, while
leaving the original untouched. Again, the algorithm can store information to be available
-after it has been applied. Implemented as dox[ost::iplt::ModOPAlgorithm|ModOPAlgorithm].
+after it has been applied. Implemented as dox[ost::img::ModOPAlgorithm|ModOPAlgorithm].
### ConstModOP
Similar to ModOP, except that no information can be stored beyond the
application of the algorithm itself. Example: rotation around an arbitrary angle. Implemented
-as dox[ost::iplt::ConstModOPAlgorithm|ConstModOPAlgorithm].
+as dox[ost::img::ConstModOPAlgorithm|ConstModOPAlgorithm].
## Custom Algorithms
-Writing custom algorithms for the 'iplt' module is fairly straightforward, in view of the fact that the final
+Writing custom algorithms for the 'img' module is fairly straightforward, in view of the fact that the final
algorithm will integrate seamlessly into the build environment, both at the C++ and Python runtime
levels. Information on how to write custom algorithms can be found at the
-[Algorithm Tutorial page](docs/tut/ipltalgdata.html).
+[Algorithm Tutorial page](docs/tut/imgalgdata.html).
There are two fundamental types of algorithms, those that operate on high level
-ImageHandle instances, [Data Algorithms](docs/tut/ipltalgdata.html), and those that
-operate on the low level ImageState instances, [ImageState Algorithms](docs/tut/ipltalgdistate.html).
+ImageHandle instances, [Data Algorithms](docs/tut/imgalgdata.html), and those that
+operate on the low level ImageState instances, [ImageState Algorithms](docs/tut/imgalgdistate.html).
diff --git a/website/raw/docs/tut/ipltalgdata.mkdown b/website/raw/docs/tut/imgalgdata.mkdown
similarity index 93%
rename from website/raw/docs/tut/ipltalgdata.mkdown
rename to website/raw/docs/tut/imgalgdata.mkdown
index f67f68a363a827e21e7cb6b1c2d782e656ff53c5..23b0bb130eb97169f375b7c7a0ba8bd6038cdeec 100644
--- a/website/raw/docs/tut/ipltalgdata.mkdown
+++ b/website/raw/docs/tut/imgalgdata.mkdown
@@ -4,7 +4,7 @@ title: Data Algorithms - An Algorithm Tutorial
# Data Algorithms - An Algorithm Tutorial
-This tutorial shows how to create custom high level dox[ost::iplt::ImageHandle|ImageHandle] algorithms and
+This tutorial shows how to create custom high level dox[ost::img::ImageHandle|ImageHandle] algorithms and
embed them into the OpenStructure build system. As an example, two very simple algorithm will be written:
The first will count all values in an image or function that are larger than a certain threshold. Since this
algorithm only needs to read values, it will be implemented by deriving it from ConstAlgorithm. The second algorithm
@@ -102,14 +102,14 @@ algorithm needs to be included from its header. These are the two 'include'
statements we want to add, along with the 'namespace' code:
:::cpp
- #include <ost/iplt/image.hh>
+ #include <ost/img/image.hh>
#include <ost/thres/thres_count.hh>
- using namespace ost::iplt;
+ using namespace ost::img;
using namespace ost::thres;
-The first 'include' line and the 'ost::iplt' 'namespace' directive are needed
+The first 'include' line and the 'ost::img' 'namespace' directive are needed
for creating and handling an ImageHandle. They use elements which are part of
the standard OpensStructure distribution. The others lines are required for our
particular algorithm class.
@@ -126,7 +126,7 @@ to be created, with which the functionality of the algorithm can be tested:
ImageHandle ih = CreateImage(Extent((Size(4,4))));
The factory method CreateImage() from the standard OpenStructure
-distribution takes care of this. The dox[ost::iplt::ImageHandle|ImageHandle]
+distribution takes care of this. The dox[ost::img::ImageHandle|ImageHandle]
'ih' now referes to a 4x4 real, spatial image, with all values set to zero. To
populate the image with values, the following code is used:
@@ -146,7 +146,7 @@ Note
threshold, and it makes only sense that this threshold is given upon instantiation;
we will need to remember this once we implement the constructor.
As the next step, the algorithm is applied to the image, using the appropriate
-method from dox[ost::iplt::ImageHandle|ImageHandle]:
+method from dox[ost::img::ImageHandle|ImageHandle]:
:::cpp
ih.Apply(a);
@@ -170,9 +170,9 @@ Here is the finished file 'test\_thres\_count.cc'.
:::cpp
#include "test_thres_count.hh"
- #include <ost/iplt/image.hh>
+ #include <ost/img/image.hh>
#include <ost/thres_count.hh>
- using namespace ost::iplt;
+ using namespace ost::img;
using namespace ost::thres;
namespace test_thres_count {
@@ -238,9 +238,9 @@ Here is the final test file 'test\_thres\_set'.cc:
:::cpp
#include "test_thres_set.hh"
- #include <ost/iplt/image.hh>
+ #include <ost/img/image.hh>
#include <ost/thres/thres_set.hh>
- using namespace ost::iplt;
+ using namespace ost::img;
using namespace ost::thres;
namespace test_thres_set {
@@ -277,7 +277,7 @@ Here is the final test file 'test\_thres\_set'.cc:
Obviously, all files need to be added to the 'CMakeLists.txt' file in 'thres/tests.'
Also, all the module dependencies must be added. In our example the dependencies are
-the 'ost\_iplt' and 'ost\_iplt\_alg' module, plus the 'ost\_thres' moudle itself.
+the 'ost\_img' and 'ost\_img\_alg' module, plus the 'ost\_thres' moudle itself.
## Coding Algorithm
@@ -293,7 +293,7 @@ Here is 'thres\_count.hh:
#ifndef OST_TRES_THRES_COUNT_H
#define OST_TRES_THRES_COUNT_H
- #include <ost/iplt/algorithm.hh>
+ #include <ost/img/algorithm.hh>
namespace ost { namespace thres {
@@ -326,7 +326,7 @@ And here is 'thres\_count.cc':
:::cpp
#include "thres_count.hh"
- using namespace ost::iplt;
+ using namespace ost::img;
using namespace ost::thres;
ThresCount::ThresCount(Real thres):
@@ -363,7 +363,7 @@ And here is 'thres\_count.cc':
}
Note
-: The polymorphic separation into 'dox[ost::iplt::ConstImageHandle|ConstImageHandle]' and
+: The polymorphic separation into 'dox[ost::img::ConstImageHandle|ConstImageHandle]' and
'Function' is not utilized in this example, since both 'Visit()' methods just call
'VisitData()' to perform the actual calculation. The method body of 'VisitData()'
is the actual algorithm implementation, using the private member variables 'thres\_'
@@ -375,7 +375,7 @@ Here is the 'thres\_set.hh' file:
#ifndef OST_THRES_THRES_SET_H
#define OST_THRES_THRES_SET_H
- #include <ost/iplt/algorithm.hh>
+ #include <ost/img/algorithm.hh>
namespace ost { namespace thres {
@@ -401,7 +401,7 @@ And here is 'thres_set.cc':
:::cpp
#include "thres_set.hh"
- using namespace ost::iplt;
+ using namespace ost::img;
using namespace ost::thres;
ThresSet::ThresSet(Real thres):
@@ -420,8 +420,8 @@ And here is 'thres_set.cc':
Once again, all the files must be added to the 'CMakeLists.txt' file, this time in
'thres/src'. This will make sure that all the headers and the newly created shared libraries
-are staged correctly. The 'DEPENDS ON' directive in the file should include the 'iplt'
-and 'iplt_alg' modules, since those are the modules 'thres' depends on.
+are staged correctly. The 'DEPENDS ON' directive in the file should include the 'img'
+and 'img_alg' modules, since those are the modules 'thres' depends on.
## Python Wrapper
@@ -435,7 +435,7 @@ the 'thres' module. Let's put the following 'wrap\_thres.cc' file in the 'src/py
#include <ost/thres/thres_count.hh>
#include <ost/thres/thres_set.hh>
- using namespace ost::iplt;
+ using namespace ost::img;
using namespace ost::thres;
BOOST_PYTHON_MODULE(_tres)
diff --git a/website/raw/docs/tut/ipltalgdistate.mkdown b/website/raw/docs/tut/imgalgdistate.mkdown
similarity index 95%
rename from website/raw/docs/tut/ipltalgdistate.mkdown
rename to website/raw/docs/tut/imgalgdistate.mkdown
index 47579c869f8e20a35a724212fc9d2b68ed29ab00..1b544b8c3ac001c6f98c50a931f0e6e83bf882c9 100644
--- a/website/raw/docs/tut/ipltalgdistate.mkdown
+++ b/website/raw/docs/tut/imgalgdistate.mkdown
@@ -39,7 +39,7 @@ This is an example of a NonMod algorithm
// entry point for image state visitor
template<typename T, class D>
- void VisitState(const iplt::image_state::ImageStateImpl<T,D>& isi);
+ void VisitState(const img::image_state::ImageStateImpl<T,D>& isi);
// entry point for function visitor
void VisitFunction(const Funcion& f);
diff --git a/website/raw/docs/tut/ipltdataviewer.mkdown b/website/raw/docs/tut/imgdataviewer.mkdown
similarity index 98%
rename from website/raw/docs/tut/ipltdataviewer.mkdown
rename to website/raw/docs/tut/imgdataviewer.mkdown
index 5149f31f876277c20c12ac80188d8c48666eaec5..4dc6bf879c0c5f4bb66f1eff7f25e2a08c87221a 100644
--- a/website/raw/docs/tut/ipltdataviewer.mkdown
+++ b/website/raw/docs/tut/imgdataviewer.mkdown
@@ -9,7 +9,7 @@ title: Data Viewer
The Data Viewer can display a single real or reciprocal space image with adjustable
contrast. Phases in reciprocal space images can be visualized using the phase color mode.
The data viewer can be created and also be controlled via the Python/C++ interface.
-Extension of the data viewer is possible using additional [overlays](docs/tut/ipltoverlays.html).
+Extension of the data viewer is possible using additional [overlays](docs/tut/imgoverlays.html).
The DataViewer shows several panels. In each several actions can be performed using
the keyboard and mouse interface, as described below. A status bar is also present in
@@ -114,7 +114,7 @@ Following python code loads an image and creates a new viewer for it.
im=io.LoadImage("...")
v=gui.GostyApp.Instance().CreateDataViewer(im)
-The viewer instance v provides following methods. See the dox[ost::iplt::gui::DataViewer|DataViewer]
+The viewer instance v provides following methods. See the dox[ost::img::gui::DataViewer|DataViewer]
class documentation.
diff --git a/website/raw/docs/tut/ipltintro.mkdown b/website/raw/docs/tut/imgintro.mkdown
similarity index 87%
rename from website/raw/docs/tut/ipltintro.mkdown
rename to website/raw/docs/tut/imgintro.mkdown
index 9c21f07434a8f3b34ce1fd946de6afa410ff6b74..4b27d37208674c46511708aa72240b7c0ecc65ff 100644
--- a/website/raw/docs/tut/ipltintro.mkdown
+++ b/website/raw/docs/tut/imgintro.mkdown
@@ -7,8 +7,8 @@ title: Images / Density Maps - An Introduction
## Introduction : The ImageHandle
OpenStructure offers extensive processing capabilities for planar 2d images and
-3d maps using the iplt module. Images are manipulated through the use of
-dox[ost::iplt::ImageHandle|ImageHandles].
+3d maps using the img module. Images are manipulated through the use of
+dox[ost::img::ImageHandle|ImageHandles].
ImageHandles provide a clean and efficient interface to interact
with images and maps. An ImageHandle can store an image in either real
@@ -35,7 +35,7 @@ to 0.
As a first step, enter the following lines in the OpenStructure python console:
:::python
- im=iplt.CreateImage(iplt.Size(200,200))
+ im=img.CreateImage(img.Size(200,200))
This will create an empty, 2D image, with a height and width of 200 pixels, whose
@@ -52,7 +52,7 @@ The inner area of the white frame is the image, which is empty.
Let us fill the image with random values.
:::python
- rand_alg = iplt.alg.Randomize() # create algorithm object
+ rand_alg = img.alg.Randomize() # create algorithm object
im.ApplyIP( rand_alg ) # apply algorithm object in-place
As you can see, applying an algorithm is conceptually a two-step process. First,
@@ -66,7 +66,7 @@ Now that we have some (noisy) data present, let us run another algorithm, this t
a Gaussian filter with a sigma of 4 pixel.
:::python
- im.ApplyIP( iplt.alg.GaussianFilter(4.0) ) # apply temporary algorithm object in-place
+ im.ApplyIP( img.alg.GaussianFilter(4.0) ) # apply temporary algorithm object in-place
As you can see, it is not always necessary to create an independent algorithm instance first,
in many cases a temporary object will suffice (this applies to the randomization
@@ -76,7 +76,7 @@ is applied. This can be important if the algorithm stores some values that need
recovered later. For example:
:::python
- stat=iplt.alg.Stat()
+ stat=img.alg.Stat()
im.ApplyIP(stat)
mean=stat.GetMean()
@@ -89,17 +89,17 @@ information would be lost.
## Applying a Fourier Transform
-An image is Fourier-transformed using the 'iplt.alg.FFT()' algorithm object:
+An image is Fourier-transformed using the 'img.alg.FFT()' algorithm object:
:::python
im=io.LoadImage("imagename.tif") # load the image
# create an instance of the fft algorithm object
- fft=iplt.alg.FFT()
+ fft=img.alg.FFT()
# do the actual Fourier transformation
im_ft=im.Apply(fft)
# back-transform
im2 = im_ft.Apply(fft)
- # if this is run from within giplt, open viewers to look at the images
+ # if this is run from within the dng graphical frontend, open viewers to look at the images
gui.CreateDataViewer(im)
gui.CreateDataViewer(im_ft)
gui.CreateDataViewer(im2)
@@ -128,9 +128,9 @@ An image can be extracted and pasted into another image using the 'Extract()' an
# load the image
im=io.LoadImage("imagename.tif")
# generate a subimage from the region going from (10,10) to (30,30)
- im2=im.Extract(iplt.Extent(iplt.Point(10,10),iplt.Point(30,30)))
+ im2=im.Extract(img.Extent(img.Point(10,10),img.Point(30,30)))
# generate an empty image with the same size as the original image
- im3=iplt.CreateImage(im.GetExtent())
+ im3=img.CreateImage(im.GetExtent())
# paste the subimage into the empty image
im3.Paste(im2)
@@ -142,7 +142,7 @@ region where the pasted-to and the pasted-in image overlap will be affected.
| | | |
|:-------------------------------------------------:|:-------------------------------------------------------------------:|:------------------------------------------------------------------------:|
-|![Empty Image] (docs/tut/giplt1.jpg "Empty Image") | ![After Randomization] (docs/tut/giplt2.jpg "After Randomization") | ![After Gaussian Filtering] (docs/tut/giplt3.jpg "After Randomization") |
+|![Empty Image] (docs/tut/dv1.jpg "Empty Image") | ![After Randomization] (docs/tut/dv2.jpg "After Randomization") | ![After Gaussian Filtering] (docs/tut/dv3.jpg "After Randomization") |
|Empty Image | After Randomization | After Gaussian Filtering |
diff --git a/website/raw/docs/tut/ipltoverlays.mkdown b/website/raw/docs/tut/imgoverlays.mkdown
similarity index 88%
rename from website/raw/docs/tut/ipltoverlays.mkdown
rename to website/raw/docs/tut/imgoverlays.mkdown
index 279da45a5762e789a0b7aff6057da51d943bc4b4..f84b883fb3c05a8183647c369ce1587e515f9bed 100644
--- a/website/raw/docs/tut/ipltoverlays.mkdown
+++ b/website/raw/docs/tut/imgoverlays.mkdown
@@ -3,7 +3,7 @@
# Overlays
The DataViewer may be extended by an arbitrary amount overlays. These are
-classes derived from 'ost::iplt::gui::Overlay', either directly in Python or
+classes derived from 'ost::img::gui::Overlay', either directly in Python or
written in C++ and then exported to Python. They are added dynamically to each
viewer by means of the DataViewer::AddOverlay method.
@@ -15,7 +15,7 @@ is given below, and can also be found in `modules/gui/src/data_viewer/null_overl
:::cpp
#include <ost/gui/data_viewer/overlay_base.hh>
- class NullOverlay: public ost::iplt::gui::Overlay
+ class NullOverlay: public ost::img::gui::Overlay
{
public:
// the ctor must initialize the Overlay base class with a name
@@ -31,7 +31,7 @@ is given below, and can also be found in `modules/gui/src/data_viewer/null_overl
// This method is called for each redraw of the image viewer, after the image itself
// has been rendered in the view widget. The device context as well as the data viewer
// panel are passed
- virtual void OnDraw(wxDC& dc, const iplt::gui::DataViewerPanel* dvp, bool is_active)
+ virtual void OnDraw(wxDC& dc, const img::gui::DataViewerPanel* dvp, bool is_active)
{
}
diff --git a/website/raw/docs/tut/tut02.mkdown b/website/raw/docs/tut/tut02.mkdown
index c2f1004fbdddd867762615441efaffcad0c32dad..55417178aec476597af4e6811953ff07feca2ae7 100644
--- a/website/raw/docs/tut/tut02.mkdown
+++ b/website/raw/docs/tut/tut02.mkdown
@@ -96,7 +96,7 @@ The use XCSEditor and ICSEditor are mutually exlusive. This means that whenever
In this exercise you will learn how to do basic processing of density map data. For the exercise you will use real experimental data coming from a single particle reconstruction of the YscC protein from Yersinia entercolitica.
-The first step to the processing of density data in OpenStructure is the loading of the ‘iplt’ and ‘iplt.alg’ module.
+The first step to the processing of density data in OpenStructure is the loading of the ‘img’ and ‘img.alg’ module.
Go ahead and load the module in the OpenStructure python shell.
The second step consists in loading the density data into memory. OpenStructure provides a LoadMap function in the ‘io’ module that can be used, not surprisingly, to load a density map.
@@ -122,15 +122,15 @@ You will notice that the GetSpatialSampling method shows that the map has a pixe
The map is way too large to be manipulated and visualized comfortably. Since the data have low resolution anyway, we will shrink the map using the DiscreteShrink algorithm.
-First, go ahead and import the `iplt.alg` module.
+First, go ahead and import the `img.alg` module.
Then let’s create an instance of the DiscreteShrink algorithm. Let’s pass it a size parameter of 4x4x4. The map will be shrunk by a factor of 4 in all directions.
Let’s now apply the algorithm to the map. We apply it in place, because we want to overwrite the original data
map.ApplyIP(shrink_alg)Now go ahead and try to recover the information about the spatial sampling from the map. Verify that the pixel sampling has been adjusted to reflect the shrinking.
-shrink_alg=iplt.alg.DiscreteShrink(iplt.Size(4,4,4))
+shrink_alg=img.alg.DiscreteShrink(img.Size(4,4,4))
Now, let’s use another algorithm to normalize the density values of the map between the 0 and 1
-norm=iplt.alg.CreateLinearRangeNormalizer(map,0.0,1.0)When you create an instance of this algorithm, you need to pass it information about the map it will be applied to (map) and the lowest and highest value of the normalization range(0.0 and 1.0)
+norm=img.alg.CreateLinearRangeNormalizer(map,0.0,1.0)When you create an instance of this algorithm, you need to pass it information about the map it will be applied to (map) and the lowest and highest value of the normalization range(0.0 and 1.0)
The algorithm can then be applied to the map. Go ahead and apply it in place, overwriting the original data.
@@ -146,7 +146,7 @@ print map_go.GetLevel()
Finally, let’s create a low-pass-filtered version of the map and display it on the screen.
We use the LowPassFilter algorithm:
-filter=iplt.alg.LowPassFilter(4.0*Units.nm)
+filter=img.alg.LowPassFilter(4.0*Units.nm)
We pass to the algorithm the resolution threshold for the filtering. Please notice that we pass it in nanometers, because we have been working with electron tomography in the past, so it comes easier to us to think in terms of nanometers as opposed to Angstrom. OpenStructure does the necessary conversion internally.
diff --git a/website/raw/docs/tutorials.mkdown b/website/raw/docs/tutorials.mkdown
index 7326bfd42629367f94babd0ae8c6222f6be8c9a4..7cde7f8bbe41345a2d6bc86a52d7e2b7829e67bd 100644
--- a/website/raw/docs/tutorials.mkdown
+++ b/website/raw/docs/tutorials.mkdown
@@ -17,9 +17,9 @@ title: Tutorials
* [Storing Custom Data in an Entity](docs/tut/genericprop.html)
### Images and Density Maps
- * [Images / Density Maps - An Introduction](docs/tut/ipltintro.html)
- * [Algorithms for Images and Density Maps](docs/tut/ipltalg.html)
- * [The Data Viewer](docs/tut/ipltdataviewer.html)
+ * [Images / Density Maps - An Introduction](docs/tut/imgintro.html)
+ * [Algorithms for Images and Density Maps](docs/tut/imgalg.html)
+ * [The Data Viewer](docs/tut/imgdataviewer.html)
## For Developers