[Bug] pm7 files sometimes layer image decoded is not correct

[ipa64]

System

UVtools v5.0.2 X64
Operative system: Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56 PDT 2023; root:xnu-8796.141.3~6/RELEASE_X86_64 X64
Processor: Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
Processor cores: 8
Memory RAM: 8.69 / 15.56 GB
Runtime: osx-x64
Framework: .NET 9.0.0
AvaloniaUI: 11.2.3
OpenCV: 4.9.0

Sreens, resolution, working area, usable area:
1: 1440 x 900 @ 100% (Primary) (On this)
    WA: 1440 x 875    UA: 1440 x 875

Path:       /Applications/UVtools.app/Contents/MacOS/
Executable: /Applications/UVtools.app/Contents/MacOS/UVtools

Printer and Slicer

• Printer: Anycubic Photon Mono 7 (pm7 file extension)
• Slicer: Anycubic Workshop 3.5

Description of the bug

Sometimes wrong decoded image layer.
Original layer image

Layer image decoded by uvtools

How to reproduce

Open the unziped attached file Layer_202.pm7
goto layer 202

Files

Layer_202.pm7.zip

[github-actions]

This is your first time submitting an issue with UVtools 🥳Please review your issue and ensure that the submit template was followed, the information is complete, and not related to any other open issue. It will be reviewed shortly. Debugging is very important and make the program better. Thanks for contributing and making the software better! 🙌

[sn4k3]

The file you have attached shows exactly like UVtools if you open on Anycubic, try yourself and report back.
It might be a bug on slicer and not UVtools

EDIT: Sorry I misread, I will take a look

[ipa64]

I think it’s always empty closed surfaces sometimes seen as full.

[sn4k3]

I know the problem, solution however is out of my ideia yet.

This is what AC produces, and there are overlaping lines which makes hard to determine the fill

[ipa64]

If you need, I have a file with more layers concerned, with both error Island and Overhang caused by same issue.

[sn4k3]

The issue is hard to solve, I debug by showing depth level / parent, and all that shares the same parent because they have overlap lines, inner square touch outer contour which make them the same contour, when it should be at level 2/3...

It makes hard to know which one is negative and positive since they are in same depth.

Can you try to print the original object and observe that layer in printer in a dry print? To make sure printer raster it correctly or maybe dont? Cut the object in slicer to make it faster to reach the layer.

[ipa64]

and observe that layer in printer in a dry print?

Do you mean have a look directly to the UV screen during the dry print process ?

Cut the object in slicer to make it faster to reach the layer

I cannot do that, I tried but there is an interaction with supports, if I generate new supports I get different result !

Please have a look to the attached file:

• until layer 99 we can see supports growing correctly, in white color.
• layer 100 is the first layer of the model, and now supports are considerate as empty surface (black color), so uvtools give an island warning.

Hand_L_cut.pm7.zip

[sn4k3]

Do you mean have a look directly to the UV screen during the dry print process ?

Yes, with a white paper on the LCD.

I cannot do that, I tried but there is an interaction with supports, if I generate new supports I get different result !

Ok, try to replicate that somehow with other model.

Please have a look to the attached file

Ok, now that's an impossible task... Because that layer is well defined but inner lines are defining areas, a white area inside white area doesn't make any sense, the contours are render in fill/void/fill/void pattern. We have no way to know if that area should be a fill or a void. What a mess...

As this file is shorter, you can try to slice with 0.2mm layer height, and use smaller supports height to model, this way will reach the desired layer faster and you can observe if printer will print as expected or if print as UVtools shows.

[ipa64]

you can observe if printer will print as expected

But for that I will need to get out the platform build, and because this printer has an autolevelling feature, I think I will get an error, if I understood correctly how autolevelling works ?

[sn4k3]

yes you need to take out the platform head. I have no clue how the printer works. Maybe you can fool the sensor, IDK...

[ipa64]

Did it,
layer 19

layer 20

Layer_20_totest.pm7.zip

[ipa64]

layer 20 in uvtools

[sn4k3]

Ok, so printer know those are white areas, somehow...

Try and test this file and post the dry print picture, layer 1 is all I need
Hex.zip

[ipa64]

Ok, so printer know those are white areas, somehow...

Try and test this file and post the dry print picture, layer 1 is all I need Hex.zip

That is weird, I can open it in Anycubic Workshop, but printer failed to read it

[sn4k3]

Here the stl, you can slice yourself and print: (No supports)
Hex (2).zip

[ipa64]

[sn4k3]

It does it correctly. I have no clue how inner contours are differentiated in this way. IMO a white contour inside a white countour should never exists.
Meanwhile if you want to use the older format, you can set AntiAliasing to 8 and it will output pw0 instead which will not have this issue.

[ipa64]

Humm interesting, what is this pw0 ?
What about other values for antialiasing?
Thank you

[sn4k3]

PW0 is the image RLE anycubic uses in the previous format. Because PWSZ can't have antialiasing if you use a high value they must use PW0 instead which full support all AA values.

What about other values for antialiasing?

< 8 produces PWSZ
>= 8 produces PW0