Ez a dokumentum a LaserBase képfeldolgozásának modelljét írja le. A cél a működés megértése: milyen reprezentációk vannak, milyen sorrendben fut a pipeline, és hogyan jutunk el a RAW képtől a G-code-ig.
Nem fejlesztői specifikáció. A hangsúly a használható, technikailag pontos mentális modellen van.
A LaserBase nem kizárólag bináris ditheringre épül.
A rendszer többféle feldolgozási stratégiát támogat:
Ezért a központi kérdés nem az, hogy „melyik dither algoritmust használjuk”, hanem az, hogy a választott mód milyen képreprezentációt ad, és abból milyen G-code készül.
A RAW a betöltött forráskép.
Ehhez kapcsolódik:
A crop nem a már feldolgozott képre vonatkozik, hanem a RAW térre.
Ez az a kép, amely már:
A BASE fogalma módfüggő.
Nem helyes úgy tanítani, hogy a BASE mindig bináris.
Depth módban a rendszer két feldolgozott rasztert tart:
A preview ezek között válthat, az export pedig két passzból épül fel.
A felhasználó megad:
A program ebből nem közvetlenül rajzol rasztert, hanem a gép léptethetőségéhez illesztett valós rasztert számol.
Ha a step-tengelyen a sorok csak meghatározott lépésközökkel vihetők fel, akkor a tényleges pitch és az effektív DPI a gép által megengedett értékhez igazodik.
Az effektív DPI:
effektív DPI = 25,4 / real_pitch_mm
Ez lehet eltérő a kért DPI-től.
A feldolgozás előtt a rendszer eldönti:
Ha a szükséges sor- vagy oszlopszám nagyobb, mint ami a forrásképből közvetlenül kijön, a döntés REPAIR lesz. Ellenkező esetben BASE.
A rotate_90 valódi geometriai transzformáció.
Nem preview trükk, hanem a forráskép orientációját módosítja. Emiatt a következő lépések már az elforgatott RAW képpel dolgoznak:
A preview-visszaforgatás külön megjelenítési réteg.
Ez csak a nézetet transzformálja. Nem módosítja:
Ezért a két forgatást szét kell választani:
rotate_90 = feldolgozási geometriaA crop a forrásképen értelmezett, mert így a kivágás a lehető legkorábban történik.
Ennek következménye:
Kör cropnál a geometriának négyzetesnek kell lennie. Ez UI oldalon is ellenőrzött feltétel.
A feldolgozási mód a rendszer központi választása.
Ez határozza meg, hogy a BASE milyen reprezentáció lesz, a preview mit jelent, és a G-code hogyan képezi át a rasztert teljesítménnyé és mozgássá.
Ebben a módban a raszter szürkeárnyalatos marad. A G-code generátor a pixel tónusát PWM értékre képezi le.
Ez nem be/ki alapú gravírozás, hanem folytonosabb teljesítményprofil.
Az error-diffusion és ordered módok ebbe a csoportba tartoznak:
Itt a végeredmény bináris. A G-code szinten a pixel vagy kap teljes égetést, vagy nem kap.
A Hybrid nem klasszikus dither.
Szürkeárnyalatos képből indul, és egy tónusfüggő mintázati korrekciót ad hozzá. A középtónusokban erősebb, a szélső tartományokban gyengébb.
Ennek szerepe:
Gyakorlati értelemben a Hybrid a túl sima grayscale és a túl durva bináris dither közti rést hidalja át. Akkor hasznos, amikor a tónusmező megtartása fontos, de a teljesen sima szürkeleképezés nem ad elég struktúrát.
A Depth két külön branch-et tart fenn:
Mindkettő saját kontrollállapotot tárolhat. A preview a két ág között vált, az export pedig két passzt generál.
A Depth akkor indokolt, amikor a tónus és a pontszerkezet nem ugyanazzal az egyetlen raszterrel kezelhető jól. A sima grayscale-hez képest külön munkateret ad a két szerepnek.
A pipeline-ban a negative korán fut.
Ez azt jelenti, hogy a későbbi brightness, contrast, gamma és sharpening már az invertált tónustérre dolgozik.
Ez azt jelenti, hogy a későbbi műveletek már az invertált tónustéren dolgoznak.
Mindkettő a szürkeárnyalatos munkaképen fut.
Nemlineáris korrekció a tónustéren. A rendszer a megadott gamma értéket korlátok közé szorítja, és LUT alapon alkalmazza.
Az élesítés unsharp mask jellegű.
A tükörműveletek a képi transzformáció részei, és a implementációban a tónusmódosítások után futnak.
A threshold nem univerzális csúszka.
Csak az error-diffusion jellegű bináris dither módok küszöbére hat. Bayer, halftone clustered, grayscale és hybrid esetén más az értelme vagy nincs érdemi szerepe.
Ez nem külön dither algoritmus, hanem a hibaterjesztés irányának váltogatása soronként.
Jelenlegi szerepe:
Ez utólagos, bináris raszteren futó tisztítás.
Nem általános képszűrő. A cél az izolált, környezetéből kilógó egyedi pixelek eltüntetése.
A logikai sorrend:
rotate_90negativecontrast + brightnessgammaradius + amount)mirror_x / mirror_yone_pixel_offA sorrend fő pontjai:
rotate_90 még a crop előtt érvényesnegative nem a dithering után vanEz a sorrend azért fontos, mert a kontrollok hatása ebből következik. Ugyanaz a beállítás más eredményt ad attól függően, hogy a pipeline melyik pontján lép be.
A jobb oldali preview a _right_view_mode és az aktív feldolgozott ág
szerint épül fel.
Ez a preview nem minden esetben a végső gravírozás közvetlen 1:1 képe. Bináris dither és depth mód esetén inkább a feldolgozási szerkezetet és a raszter jellegét mutatja meg.
Gyakorlati jelentése:
Ez csak a megjelenítés interpolációját változtatja. A feldolgozott képet nem módosítja.
A fullscreen ugyanabból az aktív preview-ágából dolgozik, mint a normál jobb oldali nézet, csak nagyobb és részletesebb ellenőrzésre alkalmas.
Az ajánlás bemenete:
Az ajánló az adatbázisból származó rekordokat aggregálja.
Az Auto nem csak egy „power arányos speed” képlet.
A logika két jellegű ajánlást kombinál:
A kettőből végső kevert ajánlás készülhet.
A fallback nem tetszőleges hierarchikus felmászás.
A rendszer:
Ez meghatározza a fallback határait.
Auto módban az ajánlott Speed és Max power egy bázisértékhez kötött. Ha a felhasználó az egyiket átírja, a másik ehhez igazodva módosul.
Az ajánlás akkor tekinthető a legerősebbnek, ha exact találatból származik. Safe-stop fallback esetén védettebb kiindulást ad, de kevésbé közvetlenül az adott anyagra vonatkozik.
Az ajánló az adatbázisban szereplő rekordokra támaszkodik. Ezek a rekordok nem csak előre definiáltak: a felhasználó saját adatokat is hozzáadhat.
A rögzített adatok exportálhatók, és más környezetben visszatölthetők. Az importált kulcsfájlok a központilag előkészített adatbázist frissítik.
Az overscan képlete:
overscan ≈ 1,15 × v² / (2a)
ahol:
v a scan sebesség mm/s-bana az adott tengely gyorsulása mm/s²-banAz 1,15 szorzó egy biztonsági tartalék.
Az export szempontjából három állapot van:
Manual esetén a felhasználó által megadott érték írja felül az automatikus számítást.
Itt a G-code generátor a pixelértéket folytonos teljesítményre képezi:
power = s_min + (s_max - s_min) × tone
Ezért a min_power ténylegesen a tónusleképezés alsó határa.
Bináris módoknál a fekete pixel fixen a felső teljesítményszintet kapja, a fehér pixel nullát.
Ilyenkor a min_power nem a bináris kiértékelés fő vezérlőeleme.
Depth módban a program:
A második passz átveszi az első passz végállapotának bizonyos export paramétereit is, ezért ez nem két teljesen független külön export.
A frame export nem csak egy kapcsoló.
Ha a keret aktív:
Kör cropnál a frame körív alapú körpálya, egyébként téglalap.
Az aktuálisan aktív feldolgozott képet menti.
Depth módban ez azt jelenti, hogy nem elvont „BASE” kerül mentésre, hanem az a branch, amely éppen aktív.
A mentés sidecar alapú workspace-állapotot is eltárol.
Tipikusan bekerül:
A visszatöltés ténylegesen rekonstruálja a workspace-t, majd újrafuttatja a feldolgozást.
Ezért a mentés-visszatöltés modellje munkamenet-jellegű, nem csak adatbázisrekord-jellegű.
A Sender szerepe nem csak a nyers streamelés.
Releváns mai funkciók:
Ez a user szinthez képest annyiban fontos, hogy a frame és a pozicionálás a Senderben is többállapotú folyamat.
Röviden:
rotate_90 valódi geometriai műveletEz a LaserBase működésének használható, helyes képe.