# UVtools for Resin Print File Analysis and Conversion

> UVtools is a portable C# application for inspecting, editing, repairing, converting, and calibrating sliced files used by MSLA and DLP printers. It addresses fragmented printer formats, but its maintainer explicitly describes printer-facing functions as experimental.

**sn4k3/UVtools** — MSLA/DLP, file analysis, calibration, repair, conversion and manipulation

- Repository: https://github.com/sn4k3/UVtools
- Stars: 1,640 · Forks: 146
- Language: C#
- License: AGPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/sn4k3-uvtools

## Why UVtools Exists for a Fragmented MSLA File Market

UVtools addresses a format fragmentation problem in resin printing. Different printer firms use different sliced-file containers and property systems, so a model produced by one slicer may not be accepted by another printer. The project was created by an FDM user who wanted to use PrusaSlicer as the preparation tool for resin printers, then convert its SL1 output into the native format required by a selected printer. That workflow is the project's distinguishing purpose: it seeks to retain the slicer experience while handling printer-specific file conversion outside PrusaSlicer.

The target users are MSLA and DLP printer operators, makers who inherit archived print projects, and people who need to recover or inspect the settings embedded in sliced files. UVtools can expose properties and settings, preserve information that might otherwise be lost when moving between formats, and provide tools for analyzing a model before printing. Its scope includes files as well as printer setup. Calibration tests are listed alongside file inspection, repair, and conversion rather than being the sole focus.

The project is not a general mesh editor or a replacement for PrusaSlicer's modeling and slicing environment. Its working object is a sliced printer file, including its layer images, metadata, and embedded settings. The README gives SL1 and SL1S as PrusaSlicer formats and lists many proprietary or semi-open formats from Photon, Creality, Elegoo, Flashforge, Voxeldance, and other printer ecosystems. This breadth makes the application useful as a format boundary, but it also means that accepting many extensions does not guarantee identical behavior on every listed printer.

## Layer, Settings, and Format Architecture of UVtools

The repository layout separates the implementation into a C# solution and several project areas. `UVtools.Core` contains the central application library and is also published as the NuGet package `UVtools.Core`. `UVtools.UI` contains the desktop interface, `UVtools.Cmd` indicates a command-line component, `UVtools.AvaloniaControls` provides UI controls, and `UVtools.WixInstaller` contains Windows installer material. Printer definitions are stored separately under the `PrusaSlicer/printer` directory. This separation supports reuse through NuGet, although the README does not document how to build the complete solution or provide a command-line example.

Within a sliced file, UVtools can view, modify, and extract layers individually. It can also inspect and edit embedded properties and settings, view or extract thumbnails, and export a file into a folder. Layer-oriented operations include mutation and filtering. Analysis checks can identify islands, overhangs, resin traps, suction cups, touching bounds, incorrect print height, and empty layers. Some checks offer repair or removal, while others produce suggestions or automatic corrections.

The correction list includes layer height, bottom-layer count, transition-layer count, model position, and wait periods before or after curing. It also includes separate bottom and regular exposure settings. The PrusaSlicer profile material documents custom notes such as `TransitionLayerCount_xxx`, `BottomWaitTimeBeforeCure_xxx`, and `BottomLightOffDelay_xxx`. These keywords allow slicer profiles to carry UVtools-specific instructions into the conversion workflow. The listed profiles cover layer heights from 0.01 mm to 0.20 mm and Light, Medium, and Heavy support profiles.

UVtools also defines intermediate or normalized representations. The README names OSLA as an open SLA universal binary file, OSF as the Vlare Open File Format, and UVJ as a vendor-neutral format for manual manipulation. The README does not explain every internal conversion path or whether all formats preserve the same metadata, so format support should not be treated as proof of a lossless round trip.

## Installing UVtools and Opening a First File

The README presents UVtools as portable and says that installation is not required. The portable build can be obtained from the latest GitHub release. Windows users can instead request installation through either package manager listed by the project.

For Windows Package Manager, the documented command is:

```bash
winget install -e --id PTRTECH.UVtools
```

This asks Windows Package Manager to install the published `PTRTECH.UVtools` package. The README notes that Winget is included by default in current Windows 10 updates and Windows 11. The command should report successful package installation if the package source and permissions are available. The project does not document noninteractive flags or troubleshooting output.

Chocolatey provides the second documented Windows path:

```bash
choco install -y uvtools
```

This installs the `uvtools` Chocolatey package with confirmation automatically accepted through `-y`. A successful Chocolatey transaction is the expected confirmation. UVtools is also available through GitHub Releases and Chocolatey, as indicated by the README links, but the release artifact names and manual download steps are not documented in the README.

For Linux and macOS, the project gives one installer command:

```bash
bash -c "$(curl -fsSL https://raw.githubusercontent.com/sn4k3/UVtools/master/Scripts/install-uvtools.sh)"
```

This downloads `Scripts/install-uvtools.sh` from the repository's `master` branch and executes it through Bash. An older release can be requested by passing a version after `--`, as documented here:

```bash
bash -c "$(curl -fsSL https://raw.githubusercontent.com/sn4k3/UVtools/master/Scripts/install-uvtools.sh)" -- x.x.x
```

The `x.x.x` placeholder must be replaced with the desired version. This is a downgrade mechanism, not a prerequisite for first installation.

After launch, a first useful workflow is to open an existing sliced file, inspect its layers and embedded properties, review reported issues, and use an available repair or correction function. The README explicitly supports viewing and editing layers, properties, thumbnails, and settings, but it does not provide exact menu labels or step-by-step UI navigation. Those actions are documented capabilities rather than reproducible click paths. Exporting the file to a folder is also documented when an operation needs the resulting layer or thumbnail data as separate output.

## Conversion Scope and Printer-Specific Validation Boundaries

UVtools has unusually broad stated format coverage. The list includes SL1 and SL1S, Photon files, CBDDLP, CTB, PHZ, FDG, PWS variants, JXS, ZCode, ZCodex, CWS variants, MDLP, GR1, CXDLP, GOO, PRZ, LGS variants, SVGX, Anet formats, QDT, OSLA, OSF, VLR, UVJ, Voxeldance formats, generic ZIP forms, NanoDLP, and numerous raster image types.

That list is useful for planning file ingestion, but it should not be read as a compatibility guarantee. The README says UVtools can convert a format to another, yet it does not publish a complete support matrix explaining every source-target pair, preserved property, unsupported field, or tested printer. It also does not document whether a converted file can be sent directly to a printer without modification.

The experimental warning is explicit. The maintainer states that they do not own a resin printer and that all work is virtual and calculated. They ask users to treat experimental functions with care and explain that confirmed functions will eventually be listed. The current README feature list does not provide that confirmation-by-confirmation list. This is the central limitation for production adoption. File inspection and editing are grounded in explicit features, while the physical print result of converted or corrected files remains unverified by the project maintainer.

The open and normalized formats may help comparison workflows, but their presence does not remove the need to inspect outputs. Users should compare layer count, layer images, dimensions, exposure settings, and printer-specific properties after conversion. Those are concrete checks because UVtools itself exposes layers and properties. The README does not state that a successful save event guarantees semantic equivalence between formats.

## Repair Checks That Are Useful, but Not Automatically Authorizing

UVtools offers checks aimed at failures that can affect resin prints. The named categories have different meanings. An island is treated as an isolated layer region. An overhang check addresses areas that lack sufficient support, especially horizontal downward-facing surfaces. Resin traps and suction cups concern cavities or areas that may retain material. Touching bounds and print-height checks concern model boundaries, while empty layers indicate possible file or slicing problems.

The project says it can repair or remove issues where possible. That wording matters. It acknowledges that not every detected condition has a safe automatic correction. UVtools also supplies suggestions and automatic corrections for parameters such as layer height, bottom layers, cure waits, transition layers, and model position. These controls are especially relevant when comparing an archived file against a later profile or preparing output for a different printer.

The feature list does not provide thresholds, algorithms, severity levels, or a list of operations that can undo a correction. It also does not say whether repair changes can be previewed before saving. For that reason, an issue report should be treated as analysis rather than an instruction to print. A user who accepts an automatic correction is accepting a change to printer-facing data without documented confidence information.

Calibration tests are another documented feature, but the README does not identify their test patterns, dimensions, workflow, or acceptance criteria. It would be incorrect to infer a specific calibration procedure from the feature name alone. UVtools is better characterized here as a file and configuration workbench that includes calibration functionality, not as a fully documented calibration standard.

## Release Pace, Upgrades, and AGPL-3.0 Obligations

The repository is not archived. Its last push was on 2026-10-16, and the listed releases include v7.0.3 on 2026-10-09, v7.0.2 on 2026-10-06, and v7.0.1 on 2026-10-02. This release record indicates recent development around the v7 line, although the README does not define an upgrade compatibility policy.

The project provides a specific downgrade mechanism through the Linux and macOS installation script, with the requested version passed after `--`. For upgrades, the README links to the latest release but does not document configuration migration, backup requirements, or whether project files created by one UVtools version are guaranteed to load in the next. That omission matters because UVtools edits sliced files and embedded settings. The repository contains `CHANGELOG.md` and `RELEASE_NOTES.md`, but their contents are not quoted in the README.

UVtools is licensed under `AGPL-3.0`. The core code is also exposed through the `UVtools.Core` NuGet package, so organizations should examine how that license applies to their intended distribution and integration. This is a license-boundary notice, not legal advice. The README does not document commercial exceptions or a separate license for generated and converted files.

For upgrade cost, the clearest documented operational cost is format and configuration review. UVtools supports many printer-specific formats and profile notes, and it can mutate layer and property data. Users moving between v7 releases should therefore compare release notes and preserve the original sliced file before applying edits. The README does not confirm automated migration or rollback of processed files.

## UVtools Compared with Printer-Bundled and Single-Format Tools

The practical alternative is a printer vendor's native slicing or repair application. That approach centers on one printer family and its native file format, while UVtools emphasizes inspection and conversion across a much larger list of resin-printer containers. A bundled application may provide printer-specific assumptions that UVtools cannot document, but UVtools offers a common interface for many formats and the option to work from PrusaSlicer-generated SL1 or SL1S files.

Another relevant alternative is PrusaSlicer by itself. It is the project author's preferred slicer and directly supports SL1 output, but the stated motivation for UVtools is that other resin printers use different formats and properties. PrusaSlicer prepares the model and supports configuration; UVtools is intended to bridge the prepared output toward native files for other printers. UVtools does not replace PrusaSlicer's modeling and slicing role.

The trade-off follows from that design. UVtools can be more useful when files cross vendor boundaries or when an old project needs metadata inspection. A single-format tool may offer a narrower and more predictable path when the printer vendor already supplies everything needed. Because UVtools does not publish a source-target compatibility matrix or physical-printer confirmation for experimental functions, breadth is not equivalent to certified support.

## Conclusion

UVtools suits resin-printer users who need to inspect, modify, repair, or convert sliced files across several printer ecosystems, especially when working from PrusaSlicer output. It is a poor fit for users who require a documented, printer-certified production workflow or who cannot independently validate experimental files. Verify first that the exact source format and target printer are supported, then inspect a converted file before sending it to hardware. The appropriate adoption boundary is experimental conversion after manual file inspection, not unattended production printing.

## FAQ

### Which file formats does UVtools support?

UVtools lists SL1, SL1S, Photon, CBDDLP, CTB, PHZ, numerous PWS variants, CWS variants, CXDLP, OSLA, OSF, UVJ, ZIP forms, and raster image formats. The README does not provide a complete source-to-target conversion matrix.

### Can UVtools convert PrusaSlicer files for another resin printer?

PrusaSlicer files can be converted toward native printer formats when both sides of the conversion are supported. The project maintainer warns that printer-facing experimental functions should be used with care because the work was done without owning a resin printer.

### Does UVtools require installation on Windows, Linux, or macOS?

UVtools is described as portable and says that installation is not required for portable builds. The README also documents Winget, Chocolatey, and a Bash-based installation script for Linux and macOS.

## Sources

- [Issues](https://github.com/sn4k3/UVtools/issues)
- [License: AGPL-3.0](https://github.com/sn4k3/UVtools/blob/master/LICENSE)
- [README](https://github.com/sn4k3/UVtools/blob/master/README.md)
- [Releases](https://github.com/sn4k3/UVtools/releases)
- [sn4k3/UVtools on GitHub](https://github.com/sn4k3/UVtools)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sn4k3-uvtools