Creality Halot One - Error with Height and Width of the screen (incorrect ratio)

[CoralieMango3D]

System

UVtools v3.15.1 X64
Operative system: Microsoft Windows 10.0.22621 X64
Processor: AMD Ryzen 7 6800H with Radeon Graphics         
Processor cores: 16
Memory RAM: 8.85 / 15.25 GB
Runtime: win10-x64
Framework: .NET 6.0.18
AvaloniaUI: 0.10.21
OpenCV: 4.7.0

Sreens, resolution, working area, usable area:
1: 1920 x 1080 @ 125% (Primary) (On this)
    WA: 1920 x 1020    UA: 1536 x 816
2: 1920 x 1080 @ 100%
    WA: 1920 x 1032    UA: 1920 x 1032

Path:       C:\Program Files\UVtools\
Executable: C:\Program Files\UVtools\UVtools.exe
Loaded file: base_V3 (1).cxdlp [Version: 3] [Class: CXDLPFile]

Printer and Slicer

• Printer: Creality Halot One
• Slicer: Lychee Slicer
  

Description of the bug

When our Lychee Slicer user dumps the files into UVTOOLS (to check for errors) it says there is an error with the Height and Width of the screen (incorrect ratio)

These values are correctly configured in Lychee Slicer but the files in UVTOOLS have the sizes of the scree

n inverted.

How to reproduce

1. Open file sliced with Lychee Slicer for Creality Halot One
2. Error message pops-up

Files

Halot one ratio error.zip

[sn4k3]

That's a old problem in lychee, found this issue over some printers. The resolution is correctly set, but display meta info is swap. Check file metadata and you will notice the longest part of LCD match the shortest resolution...

Lychee produces:
Pixels / mm
x: 1620 -> 128
y: 2560 -> 81
(Wrong ratio, longest pixel axis is matching the short axis mm)

What should be:

[mpirio]

I have the same popup.

So we have to modify Lychee Halot One configuration to set "Width (X axis)" to "81"? I have already corrected numerous .cxdlp files with UVTools and displaying this message and I have never had any printing problems 🤔.

[sn4k3]

So we have to modify Lychee Halot One configuration to set "Width (X axis)" to "81"?

No, that must be fixed on software by lychee. On the UI they have swap the values of X with Y and when writing to file they swap them again, so X value goes to Y and vice-versa, with exception of the LCD values. I don't understand the logic they are using (Incorrect values on UI and then fixing on file write but forgot to swap the LCD values) there is a mess there.

I have never had any printing problems

Because LCD information (metric size) on file is irrelevant to the printer, Printer only validates the resolution (pixel size) info which is absolute, and so the lcd metadata can be set to whatever you want and it will still print (Printer trust the file is sliced with correct pixel ratio).
UVtools otherwise rely on correct LCD size to do some calculations and generate pixels given metric sizes. For UVtools is important but still not required as soon you don't use any tool that rely on that lcd info, that's why it warns and allow you to ignore. Anyway this is a fail-safe check that should not be ignored like all other warnings that it may popup. If something is not correct it should be fixed.

See the following 3 slicers configurations for Halot One, you will notice only Lychee does it differently (But again they swap them to be correct on file write but forget to swap LCD):

You can look into Creality Slicer (Halot Box) to confirm the correct values:

I believe all Lychee need to do is also swap the LCD values when writing the file (If they want to keep the inverted logic on the UI)

The values to swap on file are with the Yellow marker