From a95123eed37d0e0491c5ec1b1d4c5cb93c2ce97f Mon Sep 17 00:00:00 2001
From: "FAZELI SHAHROUDI Sepehr (INTERN)"
<Sepehr.FAZELISHAHROUDI.intern@3ds.com>
Date: Mon, 24 Mar 2025 01:14:16 +0100
Subject: [PATCH] Update: edited the implementation according to comments
---
chapters/3-Implementation.tex | 2 +-
sections/Chapter-3-sections/Image-Conversion.tex | 6 ++++--
sections/Chapter-3-sections/Libraries-Implementation.tex | 2 +-
sections/Chapter-3-sections/Pixel-Iteration.tex | 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/chapters/3-Implementation.tex b/chapters/3-Implementation.tex
index 3d5cf6e..1ae50bc 100644
--- a/chapters/3-Implementation.tex
+++ b/chapters/3-Implementation.tex
@@ -2,7 +2,7 @@
This chapter details the implementation of a comprehensive benchmarking framework to evaluate several image processing libraries, including ImageSharp, OpenCvSharp paired with SkiaSharp, Emgu CV coupled with Structure.Sketching, and Magick.NET integrated with MagicScaler. The objective was to create an endâ€toâ€end system that not only measures execution times for common image operations but also provides insights into memory usage.
-This has been sought to answer key questions regarding the efficiency of image conversion and pixel iteration operations—two fundamental tasks in image processing. The following sections describe the review process, architectural decisions, and technical implementations in the study.extensive study.
+This has been sought to answer key questions regarding the efficiency of image conversion and pixel iteration operations—two fundamental tasks in image processing. The following sections describe the review process, architectural decisions, and technical implementations in the study.
\input{sections/Chapter-3-sections/System-Architecture.tex}
diff --git a/sections/Chapter-3-sections/Image-Conversion.tex b/sections/Chapter-3-sections/Image-Conversion.tex
index f46035d..76a513d 100644
--- a/sections/Chapter-3-sections/Image-Conversion.tex
+++ b/sections/Chapter-3-sections/Image-Conversion.tex
@@ -60,6 +60,8 @@ public class ImageConversionBenchmark
}
\end{lstlisting}
-In the code, the warm-up phase runs for five iterations. Each iteration loads the image, saves it as a PNG, and then accumulates the elapsed time. After the warm-up, the main test performs 100 iterations of the same operation, allowing us to compute an average execution time. The rationale behind this design is to isolate the steady-state performance from any one-time overhead, ensuring that the reported metrics reflect the true operational cost of image conversion.
+In the implementation, the warm-up phase executes for five iterations, during which the image is loaded, converted to PNG format, and the elapsed time is accumulated. Subsequently, the main benchmark conducts 100 iterations of the identical operation, enabling the calculation of a statistically significant average execution time. This methodological approach ensures the isolation of steady-state performance from initialization overhead, providing metrics that accurately reflect the operational cost of image conversion.
-The story behind this implementation is one of iterative refinement. Early tests revealed that the initial iterations were significantly slower, prompting the introduction of the warm-up phase. Over time, it has been refined the benchmarking routine to ensure that every iteration is as isolated as possible, thereby reducing the influence of transient system states.
\ No newline at end of file
+This benchmark design evolved through iterative refinement. Initial experimental observations revealed significantly higher latency during the first iterations, necessitating the introduction of a dedicated warm-up phase. The benchmark methodology has been progressively optimized to ensure maximum isolation between iterations, thereby minimizing the influence of transient system states on measurement accuracy.
+
+While this benchmarking approach is primarily analytical in nature, it's implicit in practical applications as well. For persistent server applications or batch processing systems, the steady-state performance metrics post-warm-up represent the most relevant operational characteristics. Conversely, for interactive applications, command-line utilities, or serverless computing environments, the initial performance represented by the warm-up phase may be more indicative of user-perceived responsiveness, as these contexts typically experience the full initialization cost with each invocation.
\ No newline at end of file
diff --git a/sections/Chapter-3-sections/Libraries-Implementation.tex b/sections/Chapter-3-sections/Libraries-Implementation.tex
index 2b37786..20486a4 100644
--- a/sections/Chapter-3-sections/Libraries-Implementation.tex
+++ b/sections/Chapter-3-sections/Libraries-Implementation.tex
@@ -1,5 +1,5 @@
\section{Libraries Implementation}
-As discussed in the Methodology chapter, a comprehensive evaluation was undertaken to assess the strengths and limitations of various image processing libraries. This analysis informed the decision to implement integrations for frameworks: OpenCvSharp with SkiaSharp, and Emgu CV with Structure.Sketching, and Magick.NET with MagicScaler. The following excerpt presents representative code segments that illustrate the implementation strategies developed for these libraries. These segments not only capture the theoretical rationale behind each implementation approach but also reflect the practical constraints and performance considerations addressed throughout the thesis. This compilation of code serves as a testament to the systematic, experimental, and iterative nature of the research, highlighting the rigorous engineering process that underpinned the development of a robust image processing benchmarking framework.
+As discussed in the Methodology chapter, a comprehensive evaluation was undertaken to assess the strengths and limitations of various image processing libraries. This analysis informed the decision to implement integrations for frameworks: OpenCvSharp with SkiaSharp, and Emgu CV with Structure.Sketching, and Magick.NET with MagicScaler. The following excerpt presents representative code segments that illustrate the implementation strategies developed for these libraries. These segments not only capture the theoretical rationale behind each implementation approach but also reflect the practical constraints and performance considerations addressed throughout the thesis.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
diff --git a/sections/Chapter-3-sections/Pixel-Iteration.tex b/sections/Chapter-3-sections/Pixel-Iteration.tex
index 75155d9..47a6155 100644
--- a/sections/Chapter-3-sections/Pixel-Iteration.tex
+++ b/sections/Chapter-3-sections/Pixel-Iteration.tex
@@ -1,6 +1,6 @@
\subsection{Pixel Iteration Benchmark Implementation}
-The pixel iteration benchmark is equally critical, as it measures the time taken to perform a basic image processing operation—converting an image to grayscale by iterating over each pixel. This benchmark simulates real-world scenarios where complex filters and effects require individual pixel manipulation.
+The pixel iteration benchmark measures the time taken to perform a basic image processing operation—converting an image to grayscale by iterating over each pixel. While modern image processing often employs vectorized operations on entire matrices for efficiency, pixel-by-pixel iteration remains relevant in several scenarios: when implementing custom filters with complex logic, when working with specialized pixel formats, or when memory constraints limit bulk operations. Additionally, this benchmark provides insight into the underlying performance characteristics of image libraries even if vectorized alternatives would be preferred in production environments. By examining the performance of this fundamental operation, we can better understand the efficiency trade-offs in various image processing contexts.
For ImageSharp, the implementation involves loading the image as an array of pixels, processing each pixel to compute its grayscale value, and then updating the image accordingly. The following snippet provides a glimpse into this process:
--
GitLab