This document describes the LaserBase image-processing model. The goal is to understand how it works: which representations exist, in what order the pipeline runs, and how the program gets from the RAW image to G-code.
This is not a developer specification. The focus is a usable, technically accurate mental model.
LaserBase is not built around binary dithering alone.
The system supports several processing strategies:
For that reason, the central question is not only which dither algorithm to choose, but what image representation the chosen mode produces and what kind of G-code follows from it.
RAW is the loaded source image.
It is tied to:
Crop is not defined on the already processed image, but in RAW space.
This is the image already:
BASE is mode-dependent.
It is not correct to teach it as always binary.
In depth mode, the system keeps two processed rasters:
The preview can switch between them, and export is built from two passes.
The user provides:
The program does not draw a raster from this directly. It computes a real raster aligned to what the machine can step.
If lines on the step axis can only be placed at specific step intervals, the actual pitch and effective DPI are adjusted to that allowed geometry.
Effective DPI is:
effective DPI = 25.4 / real_pitch_mm
It can differ from the requested DPI.
Before processing, the system decides:
If the required number of lines or columns is greater than what the source image can provide directly, the decision becomes REPAIR. Otherwise it is BASE.
rotate_90 is a real geometric transform.
It is not a preview trick. It changes the orientation of the source image. Because of that, the following steps work on the rotated RAW image:
Preview rotate back is a separate display layer.
It transforms only the view. It does not modify:
The two rotations therefore stay separate:
rotate_90 = processing geometryCrop is defined on the source image so that the cutout happens as early as possible.
This means:
With circle crop, the geometry must stay square. This is enforced at UI level as well.
The processing mode is the central choice in the system.
It defines what representation BASE takes, what the preview means, and how G-code turns raster data into power and motion.
In this mode the raster remains grayscale. The G-code generator maps pixel tone to PWM values.
This is not on/off engraving, but a more continuous power profile.
The error-diffusion and ordered modes belong here:
Here the final result is binary. At G-code level, a pixel either receives full burn or none.
Hybrid is not a classic dither mode.
It starts from a grayscale image and adds a tone-dependent pattern correction. It is stronger in the midtones and weaker at the extremes.
Its role is:
In practical terms, Hybrid bridges the gap between overly smooth grayscale and overly harsh binary dither. It is useful when tone retention matters but fully smooth grayscale does not provide enough structure.
Depth keeps two separate branches:
Each branch can store its own control state. Preview switches between them, and export generates two passes.
Depth is useful when tone and dot structure should not be carried by the same raster. Compared with plain grayscale, it gives separate working space to those two roles.
In the pipeline, negative runs early.
This means the later brightness, contrast, gamma and sharpening steps already work on the inverted tone space.
Both operate on the grayscale working image.
Gamma is a nonlinear correction in tone space. The system clamps the entered value to an allowed range and applies it through a LUT.
Sharpening is unsharp-mask based.
Mirror operations belong to image transforms and run after the tone modification steps.
Threshold is not a universal slider.
It affects only the threshold used by binary error-diffusion modes. In Bayer, halftone clustered, grayscale and hybrid, its meaning is different or not materially relevant.
This is not a separate dither algorithm, but an alternation of error propagation direction from row to row.
Its role:
This is a cleanup stage that runs on binary raster output.
It is not a general image filter. Its purpose is to remove isolated single pixels that stick out from their surroundings.
The logical order is:
rotate_90negativecontrast + brightnessgammaradius + amount)mirror_x / mirror_yone_pixel_offThe main consequences are:
rotate_90 is applied before cropnegative is not after ditheringThis order matters because control behavior follows from it. The same setting produces different results depending on where it enters the pipeline.
The right-hand preview is built from _right_view_mode and the active
processed branch.
That preview is not always a direct 1:1 image of the final engraving. In binary dither and depth mode, it shows processing structure and raster character more than final material response.
In practice this means:
This changes only display interpolation. It does not modify the processed image.
Fullscreen uses the same active preview branch as the normal right-side view, but at a larger and more inspectable scale.
The inputs are:
The recommender aggregates records from the database.
Auto is not only a “power-proportional speed” formula.
The logic combines two kinds of recommendation:
The final output can blend both.
Fallback is not arbitrary hierarchical climbing.
The system:
This defines the limits of fallback behavior.
In Auto mode, recommended Speed and Max power are tied to a baseline. If the user edits one, the other changes around that baseline.
The recommendation is strongest when it comes from an exact hit. With safe-stop fallback, it remains a more protected starting point, but is less direct for the given material.
The recommender relies on the records stored in the database. Those records are not limited to predefined data: the user can add custom entries.
Stored data can be exported and loaded back in another environment. Imported key files update the centrally prepared database set.
The overscan formula is:
overscan ≈ 1.15 × v² / (2a)
where:
v is scan speed in mm/sa is the acceleration of the active axis in mm/s²The factor 1.15 acts as a safety margin.
From export point of view there are three states:
In manual mode, the entered value overrides the automatic calculation.
Here the G-code generator maps pixel values to continuous power:
power = s_min + (s_max - s_min) × tone
For that reason, min_power acts as the lower bound of tone mapping.
In binary modes, black pixels receive the upper power level and white pixels receive zero.
In this case, min_power is not the main control element of binary
evaluation.
In depth mode, the program:
The second pass also inherits certain export-state values from the first, so these are not two fully independent exports.
Frame export is more than a simple checkbox.
When frame is active:
With circle crop, the frame path is circular; otherwise it is rectangular.
Saves the currently active processed image.
In depth mode this means the saved output is not an abstract “BASE”, but the branch that is active at that moment.
The save action stores sidecar-based workspace state as well.
Typical content:
Reload reconstructs the workspace and then runs processing again.
For that reason, save/reload is session-like, not only record-like.
Sender is not only raw streaming.
Relevant functions are:
At workshop level this matters because frame handling and positioning are multi-state processes in Sender as well.
In short:
rotate_90 is a real geometric operationThis is a usable and correct picture of how LaserBase works.