Fix links starting with "/libs"

That was the path on the ImageJ wiki, but this site does not use it.

imglib1/index.md

@@ -4,7 +4,7 @@ artifact: sc.fiji:legacy-imglib1
 sidebar: true
 ---
 
-{% include warning/deprecated old="ImgLib1" new="[ImgLib2](/libs/imglib2)" %}
+{% include warning/deprecated old="ImgLib1" new="[ImgLib2](/imglib2)" %}
 
 # Citation
 

imglib1/iterating-through-pixel-data.md

@@ -3,9 +3,9 @@ title: "ImgLib1: Iterating through pixel data"
 sidebar: true
 ---
 
-{% include warning/deprecated old="[ImgLib1](/libs/imglib1)" new="[ImgLib2](/libs/imglib2)" %}
+{% include warning/deprecated old="[ImgLib1](/imglib1)" new="[ImgLib2](/imglib2)" %}
 
-The architecture of [Imglib](/libs/imglib1) aims at completely separating the image - which can be seen as a data container - from the concrete basic data type it encapsulates. In practice, this means that you can write "blind" algorithms, which can safely ignore whether they operate on a `uint8` image, a RGB image or a `uint16` stack of 15 slices.
+The architecture of [Imglib](/imglib1) aims at completely separating the image - which can be seen as a data container - from the concrete basic data type it encapsulates. In practice, this means that you can write "blind" algorithms, which can safely ignore whether they operate on a `uint8` image, a RGB image or a `uint16` stack of 15 slices.
 
 This in turn imposes a certain gymnastic when accessing the underlying data is involved. Here, we will make a brief introduction on how to do this with Imglib. We assume you want to use Imglib in a Java plugin, and that you are already familiar with Java itself.
 

imglib1/using-in-a-plugin.md

@@ -3,9 +3,9 @@ title: Using ImgLib1 in an ImageJ plugin
 sidebar: true
 ---
 
-{% include warning/deprecated old="[ImgLib1](/libs/imglib1)" new="[ImgLib2](/libs/imglib2)" %}
+{% include warning/deprecated old="[ImgLib1](/imglib1)" new="[ImgLib2](/imglib2)" %}
 
-The [Imglib](/libs/imglib1) library makes extensive use of {% include wikipedia title='Generics in Java' text='Java generics'%}. Generics appeared in Java from version 1.5, and they introduce new semantic items that can be puzzling if you never used them before. The programming techniques associated are quite new to the ImageJ world, and using Imglib inside your plugins will change their typical layout.
+The [Imglib](/imglib1) library makes extensive use of {% include wikipedia title='Generics in Java' text='Java generics'%}. Generics appeared in Java from version 1.5, and they introduce new semantic items that can be puzzling if you never used them before. The programming techniques associated are quite new to the ImageJ world, and using Imglib inside your plugins will change their typical layout.
 
 This short page does not aim at being an introduction on generics, but rather is a quick and dirty introduction on how to tune your java files to use Imglib. The deep meaning of semantics is skipped, and we will try to provide a quick template to start with. However, we will attempt to be quite pedestrian when ImageJ itself is involved, and try to display the code and the commands needed to generate a plugin from scratch.
 
@@ -113,7 +113,7 @@ Here, we want to access the *real* pixel value (note that *complex* values are m
 
 ## Making something out of it
 
-Now that we vanquished the semantics, we would like to wrap up this tutorial by doing something with the plugin. In Imglib, we iterate over the data within an image using <b>Cursors</b>. They are the subject of [another tutorial](/libs/imglib1/iterating-through-pixel-data), we will not present them thoroughly. But briefly:
+Now that we vanquished the semantics, we would like to wrap up this tutorial by doing something with the plugin. In Imglib, we iterate over the data within an image using <b>Cursors</b>. They are the subject of [another tutorial](/imglib1/iterating-through-pixel-data), we will not present them thoroughly. But briefly:
 
 -   A plain cursor can be generated by the `createCursor()` method of an `Image`<T> instance. It will have the same type variable as that of the `Image` object it originates from.
 

imglib1/workshop.md

@@ -3,7 +3,7 @@ title: Into ImgLib - Generic Image Processing in Java
 sidebar: true
 ---
 
-{% include warning/deprecated old="[ImgLib1](/libs/imglib1)" new="[ImgLib2](/libs/imglib2)" %}
+{% include warning/deprecated old="[ImgLib1](/imglib1)" new="[ImgLib2](/imglib2)" %}
 
  The purpose of ImgLib, a Generic Java Image Processing Library, is to provide an abstract framework enabling Java developers to design and implement data processing algorithms without having to consider dimensionality, type of data (e.g. byte, float, complex float), or strategies for data access (e.g. linear arrays, cells, paged cells).
 
@@ -27,6 +27,6 @@ As a consequence of its generic aims, the library allows and requires a differen
 
 1.  [ImageJ Conference 2010](http://imagejconf.tudor.lu/program/doku.php?id=:program:workshops:preibisch:start) programme entry
 2.  [Fiji-devel mailing list](mailto:[email protected]) discusses imglib development and questions
-3.  [More about ImgLib on the Fiji wiki](/libs/imglib1)
+3.  [More about ImgLib on the Fiji wiki](/imglib1)
 
 

imglib2/accessibles.md

@@ -6,7 +6,7 @@ sidebar: true
 
  In ImgLib2, images are represented by *Accessibles*. *Image* here refers to any (partial) function from coordinates to values.
 
-In the [ previous section](/libs/imglib2/accessors) we have seen how pixel values can be manipulated using [ Accessors](/libs/imglib2/accessors). Accessors are obtained from *Accessibles*. For example we have used:
+In the [ previous section](/imglib2/accessors) we have seen how pixel values can be manipulated using [ Accessors](/imglib2/accessors). Accessors are obtained from *Accessibles*. For example we have used:
 ```
 final Cursor< UnsignedByteType > cursor = img.localizingCursor();
 ```
@@ -20,7 +20,7 @@ The UML diagram below shows the integer part of the *Accessible* interface hiera
 
 [RandomAccessible](http://javadoc.scijava.org/ImgLib2/net/imglib2/RandomAccessible.html) and [RandomAccessibleInterval](http://javadoc.scijava.org/ImgLib2/net/imglib2/RandomAccessibleInterval.html) represent images that are random-accessible at integer coordinates. (Remember: an image is a - possibly partial - function from coordinates to values.) You can obtain a RandomAccess on the data using the `randomAccess()` or `randomAccess(Interval)` methods.
 
-All ImgLib2 classes representing pixel images are [RandomAccessibles](http://javadoc.scijava.org/ImgLib2/net/imglib2/RandomAccessible.html). We already used this in [ a previous example](/libs/imglib2/accessors#randomaccess) to obtain a `RandomAccess` on an `ArrayImg`.
+All ImgLib2 classes representing pixel images are [RandomAccessibles](http://javadoc.scijava.org/ImgLib2/net/imglib2/RandomAccessible.html). We already used this in [ a previous example](/imglib2/accessors#randomaccess) to obtain a `RandomAccess` on an `ArrayImg`.
 ```
 final RandomAccess< UnsignedByteType > r = img.randomAccess();
 ```

imglib2/accessors.md

@@ -13,7 +13,7 @@ In ImgLib2, images are manipulated using *Accessors*. For pixel images, you can
 
 The accessors provided by ImgLib2 typically implement `Cursor` or `RandomAccess`. `Cursor` and `RandomAccess` are aggregations of interfaces covering the above three points. A simplified UML diagram for the interface hierarchy is shown below. (The simplification is with respect to real-coordinate interfaces for continuous images that are left out for now.)
 
-!["imglib2-accessors-simplified-integer"](media/libs/imglib2/imglib2-accessors-simplified-integer.png)
+!["imglib2-accessors-simplified-integer"](media/imglib2/imglib2-accessors-simplified-integer.png)
 
 ImgLib2 supports two basic access patterns:
 
@@ -456,7 +456,7 @@ Lines *028-031* show how to use `findmax` and get the maximum value and coordina
 
 ### Notes
 
--   The iteration order is subject to implementation, specialized for each memory layout to minimize access time. For example, an [ArrayImg](http://javadoc.scijava.org/ImgLib2/net/imglib2/img/array/ArrayImg.html) has a different iteration order from a [CellImg](http://javadoc.scijava.org/ImgLib2/net/imglib2/img/cell/CellImg.html). This is nicely illustrated in [ ImgLib2 Example 2b - Duplicating an Img using a different ImgFactory ](/libs/imglib2/examples#example-2b---duplicating-an-img-using-a-different-imgfactory).
+-   The iteration order is subject to implementation, specialized for each memory layout to minimize access time. For example, an [ArrayImg](http://javadoc.scijava.org/ImgLib2/net/imglib2/img/array/ArrayImg.html) has a different iteration order from a [CellImg](http://javadoc.scijava.org/ImgLib2/net/imglib2/img/cell/CellImg.html). This is nicely illustrated in [ ImgLib2 Example 2b - Duplicating an Img using a different ImgFactory ](/imglib2/examples#example-2b---duplicating-an-img-using-a-different-imgfactory).
 -   Typically, there are two variants of Cursors available. One that calculates its location per each iteration and one that calculates it only per localization request. The former is more efficient when localization occurs frequently, the latter otherwise. In the *maximum-finding* example, we use the latter because localization is only required once after the maximum has been found. The former one could be obtained using `localizingCursor()` instead of `cursor()` (see [IterableInterval](http://javadoc.scijava.org/ImgLib2/net/imglib2/IterableInterval.html) API doc.)
 -   `copyCursor()` is a work-around to circumvent a *javac* bug with covariant return type overriding (see [bug report](http://bugs.sun.com/view_bug.do?bug_id=6656332)). In the future (with JDK7) every `Sampler` can be copied using `copy()` instead of having specialised `copyCursor()`, `copyRandomAccess()`, ... methods.
 
@@ -470,7 +470,7 @@ ImgLib2 is not restricted to rasterized images and integer coordinates It also s
 
 The following image shows the UML diagram for the ImgLib2 accessor interface hierarchy. The real-coordinate counterparts that were missing in the simplified version [ above](accessors.md) are highlighted.
 
-![UML for ImgLib2 accessor interfaces](media/libs/imglib2/imglib2-accessors-real.png)
+![UML for ImgLib2 accessor interfaces](media/imglib2/imglib2-accessors-real.png)
 
 Real equivalents of the `Positionable` and `Localizable` interfaces have been added by which real-valued coordinates can be accessed.
 
@@ -625,7 +625,7 @@ cursor.get().set( mb.get() );
 `cursor.get()` gives the `UnsignedByteType` reference to the value under the cursor. `mb.get()` gives the `UnsignedByteType` reference to the value computed by the `MandelbrotRealRandomAccess`. Then we `set()` the value of the former to the value of the latter.
 
 When you run the code you will see this: 
-![mandelbrot-1](media/libs/imglib2/mandelbrot-1.png){style="width: 300px" caption="Mandelbrot fractal"} 
+![mandelbrot-1](media/imglib2/mandelbrot-1.png){style="width: 300px" caption="Mandelbrot fractal"} 
 
 Because we have a `RealRandomAccess` you can zoom in indefinitely (until you hit the `double` precision limit). If you like, you can play around with the scale and offset values. Here is another example obtained with
 
@@ -635,7 +635,7 @@ final double[] offset = new double[] { -1.3875, 0.045 };
 ```
 
 
-![](media/libs/imglib2/mandelbrot-2.png){style="width: 300px" caption="Mandelbrot fractal"}
+![](media/imglib2/mandelbrot-2.png){style="width: 300px" caption="Mandelbrot fractal"}
 
 ### Notes
 

imglib2/benchmarks.md

@@ -10,7 +10,7 @@ include-in-header:
 
 {% include notice icon="info" content='This page was last updated 2016 May 3.' %}
 
-This page compares the time performance of image processing operations using raw byte arrays, [ImageJ](https://imagej.net/software/imagej/) and [ImgLib2](/libs/imglib2). The benchmark tests these various methods for a "cheap" per-pixel operation (inverting an 8-bit image) as well as an "expensive" operation (some calls to `java.util.Math`) at several image resolutions.
+This page compares the time performance of image processing operations using raw byte arrays, [ImageJ](https://imagej.net/software/imagej/) and [ImgLib2](/imglib2). The benchmark tests these various methods for a "cheap" per-pixel operation (inverting an 8-bit image) as well as an "expensive" operation (some calls to `java.util.Math`) at several image resolutions.
 
 Some of the charts plot results at several iterations, meaning the test was performed repeatedly in a loop. This is important because the just-in-time compiler (JIT) is able to optimize performance increasingly well as the same code is executed more than once. Hence, we show results after both a single iteration, as well as ten iterations.
 
@@ -29,7 +29,7 @@ The data below cover the following scenarios:
 
 ## Hardware and software specifications
 
--   [ImgLib2](/libs/imglib2) version 2.9.0
+-   [ImgLib2](/imglib2) version 2.9.0
 -   [ImageJ](/software/imagej) version 1.50i
 -   Mid 2015 MacBook Pro
 -   Mac OS X 10.11.4

imglib2/changes-from-imglib1.md

@@ -19,12 +19,12 @@ At the [Madison hackathon](/events/2011-hackathon-in-madison), quite a lot has b
 
 ## Where is the Image?
 
-![Fig. 1](media/libs/imglib2/imglib2-data.png  "Title: **Fig1** ")
+![Fig. 1](media/imglib2/imglib2-data.png  "Title: **Fig1** ")
 ImgLib2 interfaces for data collections in *n*-dimensional Euclidean space. The key feature is distinction between random access vs. iteration and real vs. integer coordinate access.'%} 
 
 In *ImgLib*, the *Image* class was a wrapper for a limited subset of possible meta-data and a *Container* that provided access to the actual pixels. The overwhelming majority of methods in both *Image* and *Container* were almost identical. Furthermore, implementing algorithms for *Image* limited their portability to situations where different meta-data or less meta-data was required or different strategies for pixel access were appropriate.} 
 
-[Fig]]media/libs/imglib2/imglib2-data.png' title='**Fig. 1** ImgLib2 interfaces for data collections in *n*-dimensional Euclidean space. The key feature is distinction between random access vs. iteration and real vs. integer coordinate access.'%} In *ImgLib*, the *Image* class was a wrapper for a limited subset of possible meta-data and a *Container* that provided access to the actual pixels. The overwhelming majority of methods in both *Image* and *Container* were almost identical. Furthermore, implementing algorithms for *Image* limited their portability to situations where different meta-data or less meta-data was required or different strategies for pixel access were appropriate.
+[Fig]]media/imglib2/imglib2-data.png' title='**Fig. 1** ImgLib2 interfaces for data collections in *n*-dimensional Euclidean space. The key feature is distinction between random access vs. iteration and real vs. integer coordinate access.'%} In *ImgLib*, the *Image* class was a wrapper for a limited subset of possible meta-data and a *Container* that provided access to the actual pixels. The overwhelming majority of methods in both *Image* and *Container* were almost identical. Furthermore, implementing algorithms for *Image* limited their portability to situations where different meta-data or less meta-data was required or different strategies for pixel access were appropriate.
 
 In ImgLib2, the Image class has been abandoned. Instead, there is a set of interfaces that describe how data elements (pixels) can be accessed. Fig. 2 shows a UML-diagram visualizing the interface inheritance graph. The most important interfaces are
 
@@ -37,7 +37,7 @@ Opposed to the intuitive shortcut that you would just replace *Image* by *Img* t
 
 ## Where is the LocalizableCursor?
 
-{% include thumbnail src='/media/libs/imglib2/imglib2-access.png' title='**Fig. 2** ImgLib2 interfaces for access to sample data and to real and integer coordinates in *n*-dimensional Euclidean space.'%} Iteration in ImgLib2 (as in ImgLib) implies constant and thus repeatable order. Therefore a *Cursor* can always localize itself, either by going the hard way and reasoning the position from it's iteration index or by tracking the position per move. There is no extra interface required to distinguish this behavior but you can choose which *Cursor* to acquire by *Iterable(Real)Interval.cursor()* and *Iterable(Real)Interval.localizingCursor()*. Fig. 2 shows a UML-diagram visualizing the interface inheritance graph.
+{% include thumbnail src='/media/imglib2/imglib2-access.png' title='**Fig. 2** ImgLib2 interfaces for access to sample data and to real and integer coordinates in *n*-dimensional Euclidean space.'%} Iteration in ImgLib2 (as in ImgLib) implies constant and thus repeatable order. Therefore a *Cursor* can always localize itself, either by going the hard way and reasoning the position from it's iteration index or by tracking the position per move. There is no extra interface required to distinguish this behavior but you can choose which *Cursor* to acquire by *Iterable(Real)Interval.cursor()* and *Iterable(Real)Interval.localizingCursor()*. Fig. 2 shows a UML-diagram visualizing the interface inheritance graph.
 
 {% include clear%}
 

imglib2/developing.md

@@ -5,7 +5,7 @@ sidebar: true
 
 ## Introduction
 
-The [ImgLib2](/libs/imglib2) library uses [Maven](/develop/maven) to manage project dependencies. One advantage of this approach is nice integration with various development environments ([IDEs](/develop/ides)).
+The [ImgLib2](/imglib2) library uses [Maven](/develop/maven) to manage project dependencies. One advantage of this approach is nice integration with various development environments ([IDEs](/develop/ides)).
 
 Because people tend to have differing IDE configurations, we do not put project metadata files (e.g., `.classpath`, `.project` and `.settings` for Eclipse) into the git repository. Instead, the IDE can use Maven's `pom.xml` file directly to manage your dependencies in a better way.