Skip to content

LUPittore: software che impara da solo a dipingere come un umano, prima versione, verrà accelerato l'apprendimento

Sep 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

# LUPittore[cite: 2] ## Description[cite: 2] LUPittore is an autonomous, standalone Python desktop application for Windows 10 and Windows 11 combining raster canvas manipulation, multilayer digital compositing, procedural brush engines, and autonomous stroke-based rendering (SBR)[cite: 2]. The software is implemented exclusively in Python 3.10+ and relies on PySide6 for the desktop interface, NumPy and Numba for raster operations, Pillow and OpenCV-compatible image processing, and ONNX Runtime with the DirectML execution provider for optional hardware-accelerated inference[cite: 2]. It requires no C++, MSVC, KDE, or external third-party digital painting suite installation[cite: 2]. LUPittore provides a practical Paint-style workflow: new documents, image import, PNG export, freehand brush, eraser, eyedropper, flood fill, tablet pressure, color selection, multilayer compositing, layer opacity, and bounded undo/redo history[cite: 2]. The autonomous rendering agent executes within a dedicated Qt worker thread isolated from the main interface[cite: 2]. For each iteration it evaluates an ensemble of inferential, inductive, abductive, deductive, and intervention-based Do-Calculus signals at the same time[cite: 2]. Candidate actions are fused into a bounded cubic Bézier stroke[cite: 2]. When `models/stroke_policy.onnx` is available, ONNX Runtime attempts DirectML first and falls back to CPU execution[cite: 2]. The included policy generator creates a compact, valid ONNX starter model; it is an initialization model and is not presented as pre-trained[cite: 2]. ## Dual-Layer Graph Persistence 1. **System Ontological Hypergraph (`sbr_hypergraph.ndjson`)**: A machine-readable, Linked Data schema conforming to W3C PROV-O and schema.org that formally specifies all computational entities, action spaces, execution pipelines, and loss formulations attributed to Luigi Usai (ORCID: https://orcid.org/0009-0003-3001-717X)[cite: 1].2. **Episodic Learning Memory (`ipergrafo.ndjsonld`)**: An append-only transactional log where all autonomous observations are stored as independent JSON-LD records in NDJSON format[cite: 2]. The episodic graph records reference targets, stroke parameters, reasoning confidences, loss observations, 30-stroke reference comparisons, adaptive brush parameters, step counters, and ensemble weights[cite: 2]. At application startup the graph is loaded into memory, restoring the learned state and allowing a new session to continue from the previous stroke count, weights, and brush parameters[cite: 2]. The composite raster canvas remains in volatile system memory (RAM) until manually exported via PNG, whereas episodic records are persisted with flush and fsync[cite: 2]. Corrupted individual records are skipped during recovery so that the remaining learning history remains usable[cite: 2]. Every 30 strokes the current composite is compared with the initial reference using MAE, MSE, PSNR, and normalized similarity[cite: 2]. The painter adapts brush width, stroke length, opacity, pressure, and color mixing from these measurements[cite: 2]. A discovery checkpoint is persisted at least every 30 seconds and again when the session finishes[cite: 2]. The curriculum periodically alternates 60 exploratory strokes and 60 reference-guided strokes[cite: 2]. Exploration visibly tests 1 px, 2 px, 3 px, and 4 px brush tips, multiple colors, and line, circle, triangle, rectangle, and arc primitives[cite: 2]. Geometry type and path are persisted as linked-data action fields[cite: 2]. ## Scientific scope[cite: 2] The five reasoning labels describe computational strategies used to select and weight painting actions[cite: 2]. The current Do-Calculus component performs a counterfactual intervention heuristic based on predicted color error[cite: 2]. It is not a general causal identification engine and does not claim causal conclusions without an explicit causal graph and suitable observational/interventional data[cite: 2]. ## Reproducibility[cite: 2] The source distribution includes the application modules, the ONNX policy generator, the NDJSON-LD persistence layer, and the complete technical specification in `specifiche.md`[cite: 2]. Local virtual environments (`.venv`) and bytecode caches (`__pycache__`) are excluded. Install dependencies and run with:[cite: 2] ```powershellpython -m venv .venv.\.venv\Scripts\activatepython -m pip install -r requirements.txtpython generate_policy.pypython main.py``` ## Author[cite: 2] Luigi Usai[cite: 2] ORCID: https://orcid.org/0009-0003-3001-717X[cite: 2] ## Keywords[cite: 2] Python, PySide6, digital painting, autonomous painting, stroke-based rendering, Bézier strokes, reinforcement learning, ONNX, DirectML, NDJSON-LD, linked data, causal reasoning, Do-Calculus, computer graphics, Windows[cite: 2]. # LUPittore - Specifiche tecniche[cite: 3] ## Obiettivo[cite: 3] LUPittore e un'applicazione desktop standalone per Windows 10/11, scritta in Python 3.10+, per pittura raster multilivello e generazione autonoma di stroke[cite: 3]. Non richiede C++, MSVC o KDE[cite: 3]. ## Dipendenze[cite: 3] Le dipendenze sono in `requirements.txt`: PySide6, NumPy, Numba, Pillow, OpenCV, ONNX e ONNX Runtime DirectML[cite: 3]. L'ambiente virtuale (`.venv`) e la cache di bytecode (`__pycache__`) sono rigorosamente esclusi dal repository di distribuzione. ## Avvio[cite: 3] ```powershellpython -m venv .venv.\.venv\Scripts\activatepython -m pip install -r requirements.txtpython generate_policy.pypython main.py``` `generate_policy.py` crea `models/stroke_policy.onnx`, una policy starter compatibile con ONNX Runtime e DirectML[cite: 3]. Il modello e un'inizializzazione eseguibile, non un modello pre-addestrato[cite: 3]. ## Architettura[cite: 3] * `main.py`: bootstrap QApplication[cite: 3].* `main_window.py`: QMainWindow, menu, toolbar, canvas, livelli e dialog About[cite: 3].* `canvas_engine.py`: layer stack, buffer RGBA contigui float32, compositing source-over, undo/redo bounded[cite: 3].* `brush_engine.py`: Bézier cubica, campionamento adattivo, stamp circolare soft-edge, pressione, contagocce e flood fill[cite: 3].* `ai_worker.py`: QThread, acquisizione target, inferenza ONNX/DirectML, ensemble cognitivo concorrente e loop autonomo[cite: 3].* `learning_graph.py`: memoria append-only NDJSON-LD e ripristino dello stato[cite: 3].* `generate_policy.py`: esportazione del modello ONNX starter[cite: 3].* `sbr_hypergraph.ndjson`: specifica ontologica del sistema in standard Linked Data (W3C PROV-O) attribuita a Luigi Usai[cite: 1]. ## Canvas e livelli[cite: 3] Ogni layer e `Layer(name, pixels, opacity, visible)`, con `pixels.shape == (height, width, 4)` e dtype `float32`[cite: 3]. Il compositing applica Porter-Duff Source Over:[cite: 3] `A_out = A_top + A_base * (1 - A_top)`[cite: 3] `C_out = (C_top*A_top + C_base*A_base*(1-A_top)) / A_out`[cite: 3] Sono supportati aggiunta, rimozione, selezione, opacita, visibilita, riordinamento tramite API engine e cronologia limitata a 50 snapshot[cite: 3]. I dati della tela risiedono nella memoria volatile (RAM) fino al salvataggio manuale PNG. ## Pennello[cite: 3] La traiettoria parametrica e:[cite: 3] `B(u)=(1-u)^3 P0 + 3(1-u)^2 u P1 + 3(1-u)u^2 P2 + u^3 P3`[cite: 3] Il campionamento usa la lunghezza della polilinea dei punti di controllo e una tolleranza proporzionale alla dimensione del pennello[cite: 3]. Gli stamp sono RGBA soft-edge con pressione e opacita[cite: 3]. Mouse e tavoletta Qt (`QTabletEvent`) usano la stessa pipeline[cite: 3]. ## Strumenti Paint[cite: 3] La UI espone Nuovo, Apri, Salva PNG, Pennello, Gomma, Contagocce, Riempimento, Colore, livelli, Undo e Redo[cite: 3]. Il viewport mantiene il canvas proporzionato; l'immagine aperta viene convertita a RGBA e ridimensionata alla dimensione del documento[cite: 3]. ## Menu[cite: 3] * `File`: nuovo, salvataggio PNG, apertura riferimento, uscita[cite: 3].* `Modifica`: Undo e Redo[cite: 3].* `Visualizza`: visibilita del dock livelli[cite: 3].* `Aiuto`: About LUPittore[cite: 3].* `Apprendi`: avvio, pausa/ripresa, arresto e selezione del contesto cognitivo[cite: 3]. About: Autore Luigi Usai[cite: 3]. ORCID cliccabile: https://orcid.org/0009-0003-3001-717X[cite: 3]. ## Ciclo autonomo[cite: 3] `AutonomousPainterWorker` e un `QThread`; non modifica direttamente la UI[cite: 3]. Emette `stroke_ready`, ricevuto dal thread Qt principale[cite: 3]. Il ciclo:[cite: 3] 1. carica il target RGB;[cite: 3]2. copia il canvas corrente;[cite: 3]3. ridimensiona il target al canvas;[cite: 3]4. calcola cinque candidati in parallelo;[cite: 3]5. fonde coordinate con confidenze e pesi persistenti;[cite: 3]6. emette uno stroke Bézier;[cite: 3]7. registra l'osservazione nell'ipergrafo;[cite: 3]8. aggiorna i pesi dell'ensemble e continua dal contatore salvato[cite: 3]. Il worker salva un `sbr:DiscoveryCheckpoint` almeno ogni 30 secondi e sempre alla fine della sessione[cite: 3]. Il checkpoint contiene parametri del pennello, pesi delle strategie e metriche dell'ultimo confronto[cite: 3]. Il curriculum ricomincia periodicamente ogni 120 stroke: i primi 60 sono esplorativi e provano in modo visibile punte da 1, 2, 3 e 4 px, cinque colori e linee, cerchi, triangoli, rettangoli e archi; i successivi 60 sono dedicati alla correzione guidata dal riferimento[cite: 3]. Il contatore e globale e viene ripristinato dall'ipergrafo, senza doppio incremento[cite: 3]. ## Ragionamento simultaneo[cite: 3] Le strategie sono sempre valutate nella stessa iterazione:[cite: 3] * Inferenza: errore pixel oppure output della policy ONNX[cite: 3].* Induzione: errore pesato dalla statistica cromatica globale[cite: 3].* Abduzione: errore pesato dalla forza dell'ipotesi, stimata dalla varianza cromatica[cite: 3].* Deduzione: errore pesato da una regola di confidenza cromatica[cite: 3].* Do-Calculus: stima controfattuale dell'errore dopo un intervento sul colore medio[cite: 3]. La fusione e:[cite: 3] `p = sum_i (w_i*c_i*p_i) / s

View source

Similar papers

#computer vision Review Sep 2017

Agile Software Development Methods: Review and Analysis

Agile - denoting "the quality of being agile, readiness for motion, nimbleness, activity, dexterity in motion" - software development methods are attempting to offer an answer to the eager business community asking for lighter weight along with faster and nimbler software development processes. This is especially the case with the rapidly growing and volatile Internet software industry as well as for the emerging mobile application environment. The new agile methods have evoked substantial amount of literature and debates. However, academic research on the subject is still scarce, as most of existing publications are written by practitioners or consultants. The aim of this publication is to begin filling this gap by systematically reviewing the existing literature on agile software development methodologies. This publication has three purposes. First, it proposes a definition and a classification of agile software development approaches. Second, it analyses ten software development methods that can be characterized as being "agile" against the defined criterion. Third, it compares these methods and highlights their similarities and differences. Based on this analysis, future research needs are identified and discussed.

P. Abrahamsson, O. Salo, Jussi Ronkainen et al. · 728 citations · ⚡54
#machine learning Review Open access Oct 2014

Software development in startup companies: A systematic mapping study

Context: Software startups are newly created companies with no operating history and fast in producing cutting-edge technologies. These companies develop software under highly uncertain conditions, tackling fast-growing markets under severe lack of resources. Therefore, software startups present a unique combination of characteristics which pose several challenges to software development activities. Objective: This study aims to structure and analyze the literature on software development in startup companies, determining thereby the potential for technology transfer and identifying software development work practices reported by practitioners and researchers. Method: We conducted a systematic mapping study, developing a classification schema, ranking the selected primary studies according their rigor and relevance, and analyzing reported software development work practices in startups. Results: A total of 43 primary studies were identified and mapped, synthesizing the available evidence on software development in startups. Only 16 studies are entirely dedicated to software development in startups, of which 10 result in a weak contribution (advice and implications (6); lesson learned (3); tool (1)). Nineteen studies focus on managerial and organizational factors. Moreover, only 9 studies exhibit high scientific rigor and relevance. From the reviewed primary studies, 213 software engineering work practices were extracted, categorized and analyzed. Conclusion: This mapping study provides the first systematic exploration of the state-of-art on software startup research. The existing body of knowledge is limited to a few high quality studies. Furthermore, the results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Nicolò Paternoster, Carmine Giardino, M. Unterkalmsteiner et al. · 394 citations · ⚡54
#computer vision Open access Jul 2017

What happens when software developers are (un)happy

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components -- positive and negative emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and unhappy while developing software. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.

D. Graziotin, Fabian Fagerholm, Xiaofeng Wang et al. · 236 citations · ⚡13
#computer vision Open access Oct 2004

Mobile-D: an agile approach for mobile application development

Mobile phones have been closed environments until recent years. The change brought by open platform technologies such as the Symbian operating system and Java technologies has opened up a significant business opportunity for anyone to develop application software such as games for mobile terminals. However, developing mobile applications is currently a challenging task due to the specific demands and technical constraints of mobile development. Furthermore, at the moment very little is known about the suitability of the different development processes for mobile application development. Due to these issues, we have developed an agile development approach called Mobile-D. The Mobile-D approach is briefly outlined here and the experiences gained from four case studies are discussed.

P. Abrahamsson, Antti Hanhineva, H. Hulkko et al. · 225 citations · ⚡18

Related blog posts

MIT News · Artificial Intelligence Aug 27, 2026

Looking beyond natural sequences

A new machine-learning framework aims to improve the success rate of computational protein design while moving away from results that reproduce sequences found in nature.