diff --git a/doc/tutorials/01-What-is-QSkinny.asciidoc b/doc/tutorials/01-What-is-QSkinny.asciidoc
index f4980c212..97aa62748 100644
--- a/doc/tutorials/01-What-is-QSkinny.asciidoc
+++ b/doc/tutorials/01-What-is-QSkinny.asciidoc
@@ -10,7 +10,7 @@ QSkinny is a UI framework based on the Qt graphic stack and written in
 {cpp}. It allows users to write their UIs in {cpp} and/or QML.
 
 .The Fendt Tractor GUI
-image::https://camo.githubusercontent.com/3eea80daf41ce6a86f08c73353d05000363c4df0/68747470733a2f2f7777772e66656e64742e636f6d2f696e742f67656e6576612d6173736574732f7769646765742f32383239312f6e6577732d332d6c6f772e6a7067[Fendt Tractor GUI]
+image::https://www.fendt.com/de/images/5d19bb4e7b260601c8134e14_1673943667_web_de-DE.jpg[Fendt Tractor GUI]
 
 It is currently being used in the Fendt Tractor GUI project, see the
 picture above. For the Fendt Tractor GUI there is no QML used at all;
@@ -18,4 +18,4 @@ the whole codebase is written in {cpp}. An overview of how QSkinny fits
 into the Qt architecture is depicted below:
 
 .QSkinny sits on top of QtQuick, while QML is optional
-image::../images/architecture-simple.png[QSkinny architecture]
+image::/doc/tutorials/images/architecture-simple.png[QSkinny architecture]
diff --git a/doc/tutorials/03-writing-your-first-application.asciidoc b/doc/tutorials/03-writing-your-first-application.asciidoc
index cd16d9421..4e6db4a0f 100644
--- a/doc/tutorials/03-writing-your-first-application.asciidoc
+++ b/doc/tutorials/03-writing-your-first-application.asciidoc
@@ -157,7 +157,7 @@ int main( int argc, char* argv[] )
 
 Now the app is displaying the two buttons:
 
-image::../images/writing-first-application.png[An app showing two buttons]
+image::/doc/tutorials/images/writing-first-application.png[An app showing two buttons]
 
 That's it; you just created a QSkinny application from scratch.
 
diff --git a/doc/tutorials/04-Layouts.asciidoc b/doc/tutorials/04-Layouts.asciidoc
index 6ecc84fd6..83cfbd166 100644
--- a/doc/tutorials/04-Layouts.asciidoc
+++ b/doc/tutorials/04-Layouts.asciidoc
@@ -27,7 +27,7 @@ text width (which itself depends on the font) and possibly padding and
 margins:
 
 .implicit horizontal size hint of a button
-image::../images/size-hints-calculation.png[implicit horizontal size hint of a button]
+image::/doc/tutorials/images/size-hints-calculation.png[implicit horizontal size hint of a button]
 
 The implicit width of a composited UI element containing a
 graphic on the left and a text on the right would be the sum of the elements’
@@ -75,7 +75,7 @@ label1->setBackgroundColor( Qt::magenta );
 ....
 
 .control without explicit size hint
-image::../images/size-hints-1.png[Image without explicit size hint]
+image::/doc/tutorials/images/size-hints-1.png[Image without explicit size hint]
 
 If we set an explicit size hint of 150x60 pixels ourselves for the
 preferred size, the control will be rendered differently:
@@ -85,7 +85,7 @@ label1->setExplicitSizeHint( Qt::PreferredSize, { 150, 60 } );
 ....
 
 .control with explicit size hint
-image::../images/size-hints-2.png[Image with explicit size hint]
+image::/doc/tutorials/images/size-hints-2.png[Image with explicit size hint]
 
 When dealing with standard controls or layouts, the size hints don’t
 need to be specified explicitly, as it can be deduced from its standard
@@ -185,14 +185,14 @@ By default the width of the buttons is determined by its text plus its
 margins:
 
 .Size policies with preferred size
-image::../images/size-policies-horizontal-minimum-1.png[Fixed vs. Minimum size policy]
+image::/doc/tutorials/images/size-policies-horizontal-minimum-1.png[Fixed vs. Minimum size policy]
 
 After growing the window horizontally, the button with the Fixed
 horizontal size policy keeps its width, while the button with the
 Minimum policy will grow:
 
 .Size policies when increasing window width
-image::../images/size-policies-horizontal-minimum-2.png[Fixed vs. Minimum size policy]
+image::/doc/tutorials/images/size-policies-horizontal-minimum-2.png[Fixed vs. Minimum size policy]
 
 When shrinking the window below its original size, both buttons stay
 with their width: The one on the left because of its `Fixed` size policy,
@@ -200,7 +200,7 @@ and the one on the right because it won’t shrink below its original size
 due to the `Minimum` size policy.
 
 .Size policies when shrinking window width
-image::../images/size-policies-horizontal-minimum-3.png[Fixed vs. Minimum size policy]
+image::/doc/tutorials/images/size-policies-horizontal-minimum-3.png[Fixed vs. Minimum size policy]
 
 If we change the policy of the right button to `Preferred`, it will shrink
 below its original size (even though the text is too wide now):
@@ -211,7 +211,7 @@ label2->setText( "size policy: preferred" );
 ....
 
 .Size policies when changing to preferred size policy
-image::../images/size-policies-horizontal-minimum-4.png[Fixed vs. Minimum size policy]
+image::/doc/tutorials/images/size-policies-horizontal-minimum-4.png[Fixed vs. Minimum size policy]
 
 === Types of layouts
 
@@ -240,7 +240,7 @@ horizontalBox->addItem( label3 );
 ....
 
 .Horizontal layout
-image::../images/layout-horizontal.png[Horizontal layout]
+image::/doc/tutorials/images/layout-horizontal.png[Horizontal layout]
 
 [source]
 ....
@@ -258,7 +258,7 @@ verticalBox->addItem( label3 );
 ....
 
 .Vertical layout
-image::../images/layout-vertical.png[Vertical layout]
+image::/doc/tutorials/images/layout-vertical.png[Vertical layout]
 
 ==== Grid layouts (QskGridBox)
 
@@ -292,7 +292,7 @@ gridBox->addItem( label7, 2, 1, 1, 2 );
 ....
 
 .Grid layout
-image::../images/layout-grid.png[Grid layout]
+image::/doc/tutorials/images/layout-grid.png[Grid layout]
 
 ==== Stack layouts (QskStackBox)
 
@@ -321,7 +321,7 @@ stackBox->setCurrentIndex( 2 );
 ....
 
 .Stack layout (symbolized)
-image::../images/layout-stack.png[Stack layout]
+image::/doc/tutorials/images/layout-stack.png[Stack layout]
 
 In this example, "control 3" is stacked on top of the blue and the
 cyan control. Controls in a stacked layout can be of different sizes.
@@ -366,19 +366,19 @@ When the layout has all the space it needs (but not more), both elements
 are rendered with their preferred size:
 
 .Stretch factors with preferred size
-image::../images/stretch-factors-1.png[Stretch factors preferred size]
+image::/doc/tutorials/images/stretch-factors-1.png[Stretch factors preferred size]
 
 When the layout gets more width, the stretch factors come into play:
 
 .A stretch factor of 1:2
-image::../images/stretch-factors-2.png[Stretch factors increasing width]
+image::/doc/tutorials/images/stretch-factors-2.png[Stretch factors increasing width]
 
 No matter how wide the layout is, the aspect ratio of 1:2 will always be
 kept, meaning that the label on the left will get 33% of the space, and
 the label on the right 67%:
 
 .A stretch factor of 1:2 with different widths
-image::../images/stretch-factors-3.png[Stretch factors even more width]
+image::/doc/tutorials/images/stretch-factors-3.png[Stretch factors even more width]
 
 Stretch factors in QSkinny are the same as in the Qt Graphics View
 Framework, see
@@ -392,7 +392,7 @@ each other. The example below depicts a UI with a top bar and menu items
 on the left:
 
 .A UI with nested layouts
-image::../images/nesting-layouts.png[Nested layouts]
+image::/doc/tutorials/images/nesting-layouts.png[Nested layouts]
 
 The code to produce the above UI could look like this (setting colors
 etc. omitted for brevity):
@@ -428,7 +428,7 @@ with the menu buttons is again a vertical layout.
 The following diagram makes the layouts visible:
 
 .The layout structure of the UI
-image::../images/nesting-layouts-architecture.png[Nested layouts architecture]
+image::/doc/tutorials/images/nesting-layouts-architecture.png[Nested layouts architecture]
 
 === Anchoring in QSkinny
 
diff --git a/doc/tutorials/05-Skins.asciidoc b/doc/tutorials/05-Skins.asciidoc
index acde4d05a..7cba03ead 100644
--- a/doc/tutorials/05-Skins.asciidoc
+++ b/doc/tutorials/05-Skins.asciidoc
@@ -14,7 +14,7 @@ skinlet, and therefore it will read information from both the control
 itself as well as read the skin hints from the skin:
 
 .Skinlets query the control and the skin
-image::../images/skins-1.png[Styling controls]
+image::/doc/tutorials/images/skins-1.png[Styling controls]
 
 For instance, a button skinlet will read the margins from the skin and
 the text to render from the button.
@@ -44,10 +44,10 @@ has a traditional desktop skin, the other is a flat button with a skin
 often found in mobile devices.
 
 .desktop style button
-image::../images/skinlets-button-1.png[desktop style button]
+image::/doc/tutorials/images/skinlets-button-1.png[desktop style button]
 
 .flat button
-image::../images/skinlets-button-2.png[flat button]
+image::/doc/tutorials/images/skinlets-button-2.png[flat button]
 
 === Skin hints
 
@@ -85,7 +85,7 @@ public:
 ....
 
 .A button styled with skin hints
-image::../images/skin-hints.png[Button with skin hints]
+image::/doc/tutorials/images/skin-hints.png[Button with skin hints]
 
 When writing a new skin, a developer needs to know which hints to set
 for which control. This usually depends on the control itself; however,
@@ -154,10 +154,10 @@ public:
 ....
 
 .button in normal state
-image::../images/skin-hints-states-1.png[button in normal state]
+image::/doc/tutorials/images/skin-hints-states-1.png[button in normal state]
 
 .button in hovered state
-image::../images/skin-hints-states-2.png[button in hovered state]
+image::/doc/tutorials/images/skin-hints-states-2.png[button in hovered state]
 
 ==== Local skin hints
 
@@ -181,7 +181,7 @@ Taking animations and local skin hints into account, the architecture
 diagram now looks like this:
 
 .Skinlets can also read from local skinlets and animators
-image::../images/skins-2.png[Animators and local skin hints]
+image::/doc/tutorials/images/skins-2.png[Animators and local skin hints]
 
 === Skinlets
 
@@ -214,7 +214,7 @@ different skinlets, so a more complete version of the architecture
 diagram looks like this:
 
 .There is one skinlet for each atomic control
-image::../images/skins-3.png[Animators and local skin hints]
+image::/doc/tutorials/images/skins-3.png[Animators and local skin hints]
 
 === Skin factories and switching between skins
 
@@ -298,8 +298,8 @@ Switching between skins will change the look of `QskPushButton`
 instances:
 
 .button in `MySkin` (as above)
-image::../images/skin-hints-states-1.png[button in normal state]
+image::/doc/tutorials/images/skin-hints-states-1.png[button in normal state]
 
 .button in `OtherSkin`
-image::../images/skin-factory.png[Styling controls]
+image::/doc/tutorials/images/skin-factory.png[Styling controls]
 
diff --git a/doc/tutorials/06-scalable-graphics.asciidoc b/doc/tutorials/06-scalable-graphics.asciidoc
index 2975d83b6..c0297aa48 100644
--- a/doc/tutorials/06-scalable-graphics.asciidoc
+++ b/doc/tutorials/06-scalable-graphics.asciidoc
@@ -33,16 +33,16 @@ label2->setSizePolicy( QskSizePolicy::ConstrainedPreferred, QskSizePolicy::Expan
 ....
 
 .graphics with preferred size
-image::../images/scalable-graphics-1.png[Scalable graphics default]
+image::/doc/tutorials/images/scalable-graphics-1.png[Scalable graphics default]
 
 When resizing the window, the graphics will scale according to the size
 available in the layout:
 
 .graphics bounded by width
-image::../images/scalable-graphics-2.png[Scalable graphics bounded by width]
+image::/doc/tutorials/images/scalable-graphics-2.png[Scalable graphics bounded by width]
 
 .graphics bounded by height
-image::../images/scalable-graphics-3.png[Scalable graphics bounded by height]
+image::/doc/tutorials/images/scalable-graphics-3.png[Scalable graphics bounded by height]
 
 Since we set the horizontal size policy of the graphics to
 `ConstrainedPreferred`, the scaling is done through QskGraphic’s
diff --git a/doc/tutorials/07-parents-and-parent-items.asciidoc b/doc/tutorials/07-parents-and-parent-items.asciidoc
index 9b074116a..61d3e7d0d 100644
--- a/doc/tutorials/07-parents-and-parent-items.asciidoc
+++ b/doc/tutorials/07-parents-and-parent-items.asciidoc
@@ -41,7 +41,7 @@ Let’s look at the "Nesting layouts" example from the
 link:Layouts.html[layouts documentation]. The UI looks like this:
 
 .UI with nested layouts
-image::../images/nesting-layouts.png[Nested layouts]
+image::/doc/tutorials/images/nesting-layouts.png[Nested layouts]
 
 The code for this UI is below:
 
@@ -92,7 +92,7 @@ on. For information on how to obtain this tree, see
 https://doc.qt.io/qt-5/qobject.html#dumpObjectTree[QObject::dumpObjectTree()].
 
 .QObject tree (and item tree) of the nested layouts UI
-image::../images/object-hierarchy.png[QObject hierarchy]
+image::/doc/tutorials/images/object-hierarchy.png[QObject hierarchy]
 
 ==== Item tree
 
@@ -136,7 +136,7 @@ topBar->setOpacity( 0.2 );
 ....
 
 .Changing opacity of an item will affect all its child items
-image::../images/nesting-layouts-item-tree-1.png[Changing the item tree]
+image::/doc/tutorials/images/nesting-layouts-item-tree-1.png[Changing the item tree]
 
 ==== Difference in object trees and item trees
 
@@ -151,7 +151,7 @@ topLabel1->setParentItem( bottomBar );
 ....
 
 .Moving a label from the top bar to the bottom bar
-image::../images/nesting-layouts-item-tree-2.png[Moving a label to the bottom bar]
+image::/doc/tutorials/images/nesting-layouts-item-tree-2.png[Moving a label to the bottom bar]
 
 Now we decide to get rid of our top bar altogether:
 
@@ -163,7 +163,7 @@ topBar->deleteLater();
 This will also delete our label from the bottom bar:
 
 .Deleting the top bar will delete all its children
-image::../images/nesting-layouts-item-tree-3.png[Deleting the top bar]
+image::/doc/tutorials/images/nesting-layouts-item-tree-3.png[Deleting the top bar]
 
 The reason why the label from the bottom bar was also deleted is that
 with the call to `setParentItem()` above we set a new parent item; the
@@ -188,4 +188,4 @@ topBar->deleteLater();
 ....
 
 .Reparenting the label will keep it alive when deleting the top bar
-image::../images/nesting-layouts-item-tree-4.png[Reparenting the item]
+image::/doc/tutorials/images/nesting-layouts-item-tree-4.png[Reparenting the item]
diff --git a/doc/tutorials/08-qskinny-and-qml.asciidoc b/doc/tutorials/08-qskinny-and-qml.asciidoc
index 9af57645e..577d94ab2 100644
--- a/doc/tutorials/08-qskinny-and-qml.asciidoc
+++ b/doc/tutorials/08-qskinny-and-qml.asciidoc
@@ -56,7 +56,7 @@ Qsk.LinearBox
 The full Buttons example is depicted below.
 
 .The buttons example shows how to mix QSkinny and QML
-image::../images/buttons-example.png[Buttons example]
+image::/doc/tutorials/images/buttons-example.png[Buttons example]
 
 For more information on using C++ classes from QML, see the article about exposing attributes of {cpp} types to QML in the
 https://doc.qt.io/qt-5/qtqml-cppintegration-exposecppattributes.html[Qt documentation].
diff --git a/doc/tutorials/09-writing-own-controls.asciidoc b/doc/tutorials/09-writing-own-controls.asciidoc
index ea20bb5d9..94f65c0b5 100644
--- a/doc/tutorials/09-writing-own-controls.asciidoc
+++ b/doc/tutorials/09-writing-own-controls.asciidoc
@@ -36,7 +36,7 @@ public:
 ....
 
 .A subclassed control with local skin hints
-image::../images/subclassing-existing-controls.png[Subclassing existing controls]
+image::/doc/tutorials/images/subclassing-existing-controls.png[Subclassing existing controls]
 
 Then there is no need to set the margins and background color for every
 instance of the custom text label.
@@ -94,7 +94,7 @@ public:
 ....
 
 .A subclassed control with skin hints defined in the skin
-image::../images/subclassing-existing-controls.png[Subclassing existing controls]
+image::/doc/tutorials/images/subclassing-existing-controls.png[Subclassing existing controls]
 
 The styling described above has the same effect as in the simpler
 example, but now the `TextLabel` control can be given a different style
@@ -150,7 +150,7 @@ auto* textAndGraphic = new TextAndGraphic( "Text", "cloud" );
 ....
 
 .A composited control
-image::../images/compositing-controls.png[Compositing controls]
+image::/doc/tutorials/images/compositing-controls.png[Compositing controls]
 
 === Writing controls with a skinlet
 
@@ -311,4 +311,4 @@ changes properly. A simpler version with hardcoded values for margins,
 colors etc. can be written with less code.
 
 .A class with an own skinlet
-image::../images/control-with-skinlet.png[Control with skinlet]
+image::/doc/tutorials/images/control-with-skinlet.png[Control with skinlet]
diff --git a/doc/tutorials/10-scene-graph.asciidoc b/doc/tutorials/10-scene-graph.asciidoc
index 964bacec2..75f6b7d38 100644
--- a/doc/tutorials/10-scene-graph.asciidoc
+++ b/doc/tutorials/10-scene-graph.asciidoc
@@ -27,7 +27,7 @@ window.show();
 For this example, the scene graph will contain the following nodes:
 
 .Scene graph representation of a button
-image::../images/skins-sg-1.png[Scene graph nodes for a button]
+image::/doc/tutorials/images/skins-sg-1.png[Scene graph nodes for a button]
 
 The top two nodes (root and Quick root item) are created for every
 QtQuick application. The button itself consists of 5 nodes in our case:
@@ -60,7 +60,7 @@ window.show();
 Then the scene graph has the following structure:
 
 .Scene graph representation of a button inside a box
-image::../images/skins-sg-2.png[Scene graph nodes for a button in a box]
+image::/doc/tutorials/images/skins-sg-2.png[Scene graph nodes for a button in a box]
 
 Here we can see that since the box is a parent of the button, the `box
 node` is also a parent of the `button node` in the scene graph. Also, the
diff --git a/doc/tutorials/11-How-to-build-for-Wasm.asciidoc b/doc/tutorials/11-How-to-build-for-Wasm.asciidoc
index 6c8d7f872..63fa298f5 100644
--- a/doc/tutorials/11-How-to-build-for-Wasm.asciidoc
+++ b/doc/tutorials/11-How-to-build-for-Wasm.asciidoc
@@ -48,4 +48,4 @@ Qt creates the HTML wrappers automatically, so there is not much to do except le
 ....
 
 .The IOT dashboard example in a browser
-image::../images/iotdashboard-wasm.png[The IOT dashboard example in a browser]
+image::/doc/tutorials/images/iotdashboard-wasm.png[The IOT dashboard example in a browser]