Anycubic Photon Mono M7 Pro format

[SirKliv]

Hello!
Is there any possibility to add new format support for Anycubic Photon Mono M7 Pro?
Sliced file suffix: pwsz
Zip image format: pwszImg
This format is supported in the Anycubic Photon Workshop slicer since v3.3.2
Thanks in advance!

[sn4k3]

No ETA to support that.
Also discussed here: https://www.facebook.com/groups/uvtools/posts/1115738076202361/

[kozross]

@sn4k3 - what information would you need in order to support this format?

[sn4k3]

The layer image compression / encryption

[nalimcos]

Hello @sn4k3 ! I just bought one of these, and happen to be a developer (no experience with file formats though).

I have taken a look at a file sliced by Chitubox 2.2 (which I have already used to successfully print with this machine) and here is what I found:

Overall container: .pwsz -> as expected, it's just a zip file

Layer images:
layer_xx.pw0Img
Screen resolution is 13312*5120, so I'd expect 68 157 440 bytes for a raw image at 1 byte per pixel
The files sizes vary around half of that though, so there is some compression there. Some form of RLE?

File beginning:

Transition from '0f ff' repetition (looks suspiciously like RLE4EncodingLimit in your code, but I haven't checked whether that's relevant) to what seems to represent the tiny test object in the center of the build plate:

File ending:

Here is the entire pwsz file (.zip added so github would let me attach it):
test.pwsz.zip

How much development time do you think it would take you to get the file format added (basic support at least), along with PrusaSlicer integration? I'd be glad to either contribute financially to move this up the priority list (my budget would probably not cover outright hiring you to get it done 😆 ), or to do it myself if you can guide me to some extent as I'm unfamiliar with the project.

[rncwind]

Not an M7 pro but a standard M7 owner here.
File format seems to mostly be the same after slicing in lychee, except with a pm7 extension instead of pwsz.

Basically the same zip file contents listing after renaming pm7 to zip

Layer images are also .pw0Img files.

Makes sense since they're pretty much the same machine internals wise.
Hopefully this can be of some little help!

[nalimcos]

Quite a bit of the necessary work has actually already been done, uvtools can read some Photon M7 files when the debug flag is set, and it didn't take much fiddling around to read M7 Pro files. (It looks like non-square pixels aren't really handled by the preview at the moment though!)

Apparently, layer images can be either .pwszImg or .pw0Img. Also, my chitubox input file had key_image_format pwszImg in anycubic_photon_resins.pwsp while the layers were .pw0Img, so the extension should be checked against the contents of the folder, not the metadata.

Export to M7 Pro was not a great success: layer_images was entirely missing, haven't searched for the reason yet.

There seems to be some work needed on the settings (anycubic_photon_resins.pwsp), not sure whether it is serviceable as is, but the heated vat is not supported yet any rate; not sure about the rest.

[kozross]

@nalimcos - what WINE setup do you use for running Photon Workshop? I've tried it a few times, and it never worked for me.

[sn4k3]

@nalimcos - what WINE setup do you use for running Photon Workshop? I've tried it a few times, and it never worked for me.

For testing purposes you can mount a window VM, much more reliable than wine

[tslater2006]

@sn4k3 I just wanted to provide these files. These are made from Photon Workshop 3.4.2 and are files for the M7 Max and M7 Pro. Notably, while they are the AnycubicZipFile format, and anycubic_photon_resins.pwsp states "key_image_format": "pwszImg", if you look in the layer_images directory this files are annoyingly suffixed with .pw0Img

Cone_Files.zip

[tslater2006]

Also, those *.pw0Img files correctly decode with the DecodeLayerRLE method. For testing I just replaced
entry = inputFile.GetEntry($"layer_images/layer_{layerIndex}.pwszImg"); with entry = inputFile.GetEntry($"layer_images/layer_{layerIndex}.pw0Img"); locally to see if it would load them and it does. (i had to change the pm7m extension of course for that one)

Also not quite on topic but adjacent: Is my reading of the current state correct in that going from some other file format (like VDT) to AnycubicZipFile is not currently supported? It seems to be missing a way to encode the images to RLE and save them to the ZIP. Is this something you would be interested in a PR for?

[sn4k3]

These are made from Photon Workshop 3.4.2 and are files for the M7 Max and M7 Pro.

With same version I only get pw0 images with M7 Max, the two others generate pwsz images.

Also, those *.pw0Img files correctly decode with the DecodeLayerRLE method

Yes, those pw0 will decode and encode correctly with pw0 methods as they are the same enconding.

Is my reading of the current state correct in that going from some other file format (like VDT) to AnycubicZipFile is not currently supported? It seems to be missing a way to encode the images to RLE and save them to the ZIP.

The format is not completed, it was created in debug mode only for development, it's not available into release.
For now, the pwsz image is what is missing...

[ejongejans]

For what it's worth, I've been looking at the pwszImg format binary now for some minutes. It seems to me that:

• it could be some kind of vector format. When exporting a simple cube, there is way to little data to be an RLE scheme. Because on this high screen resolution you would have many similar rows with black-white-black. At least a 100 or so. Not seeing that.

• i first thought maybe they index every row again, so similar row's (black-white (cube)-black) get repeated. But then I tried a diamond shape. (many different rows) And the size of the binary files is only a little bigger..

• there are some patterns with {== and [-- which seem somewhat human readable

• i scanned it a couple of times for float's, there are a lot of them. But i can't make sense of the values yet.. so it could be coincidence.. It doesn't seem direct coordinates of my mesh. Perhaps still encrypted somehow..

• saving 2x the same file yields the same. So no random keys?

10mm cube centered:

3x 10mm cube dragged somewhere random:

[ejongejans]

I have a 10mm cube now. When putting values to big endian I can read floats 4.75, -5.25, 5 and 5 at various locations. This is probably the way to read it..

[ejongejans]

continued on this.. here is a cube of 10 x 10 mm.. probably a bit off center.
It seems it's writing out line segments in x1,y1->x2,y2 in big endian floating point format. There is 1 byte in between each line segment.
However it seems the curve is not a closed curve.. which would mean the printer not only rasterizes but also sorts the segments..

[ejongejans]

the 01 (3x) and 00 (1x) might be the directions of the segments.. no idea why you would do it like that..

[tslater2006]

This image format is RLE and actually already supported by UVTools in other Anycubic formats. The reason it is broken for this printer is they (Anycubic) named the files with a different extension. One that doesn't match the actual file format -_-

…

On Mon, Dec 9, 2024, 2:13 PM ejongejans ***@***.***> wrote: For what it's worth, I've been looking at the pwszImg format binary now for some minutes. It seems to me that: - it could be some kind of vector format. When exporting a simple cube, there is way to little data to be an RLE scheme. Because on this high screen resolution you would have many similar rows with black-white-black. At least a 100 or so. Not seeing that. - i first thought maybe they index every row again, so similar row's (black-white (cube)-black) get repeated. But then I tried a diamond shape. And the size of the binary files is only a little bigger.. - there are some patterns with {== and [-- which seem somewhat human readable - i scanned it a couple of times for float's, there are a lot of them. But i can't make sense of the values yet.. so it could be coincidence.. It doesn't seem direct coordinates of my mesh. Perhaps still encrypted somehow.. - saving 2x the same file yields the same. So no random keys? 10mm cube centered: image.png (view on web) <https://github.com/user-attachments/assets/3a5075ba-0701-4e1b-9e2c-e7ba083b85e8> 3x 10mm cube dragged somewhere random: image.png (view on web) <https://github.com/user-attachments/assets/690b6289-ce44-4d2e-944d-0e8d814681cf> — Reply to this email directly, view it on GitHub <#892 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANGZARCAK3X7KVQBOHAHMD2EX2XXAVCNFSM6AAAAABJYWJQ6WVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJRGI3DENI> . You are receiving this because you commented.Message ID: ***@***.***>

[tslater2006]

And somehow UVTools is supposed to just know that the file format is lying to it lol

[ejongejans]

yeah.. it's like a box of chocolates.. you never know what you are gonna get ;)

But i'm looking specifically at the .pwszImg files; as i think these are used in the .pm7/.pwsz file.
From what i read above they have not been documented yet. And that's why UVTools is not able to read/export to these other 2 machines. So probably the Max machine works; but that has half the resolution..

My guess is they went to vector format (storing vectors instead of RLE schemes) so save file size and rasterize on the printer.. as the resolutions and thus files just get to big..

[sn4k3]

I have not take a look into the pwsz more seriously but I will test that, I made 1px file to see the data.
But vector idea is not good if you use AA or blur. But the true is with the increasing resolution you need it less.

[ejongejans]

My guess is the machine rasterizes it then. So that could still mean AA being applied... depending how well it reads the settings :D

[ejongejans]

-xmin,ymin,xmax,ymax on top.
-before that 200? (unsure)
-dark purple, the 4 is the segment count.

• other zero's i don't know..

[Psychokiller1888]

I worked a lot on the pwszimg files. You are correct, but it's not xmin y min x max y max. The new format defines zones in the screen to minimize the file size. You have some Metadata in the first segment, that defines a global bounding box, with xmin ymin xmax ymax with some other data. That is defined after {===. It's like a fdm skirt to explain it. Then, you have blocks of data, after [===, that defines xstart, ystart, xend and yend. They are drawing a line as the base. Y minus goes up and X is mirrored. Data compression is tricky then

[sn4k3]

With all the information here I was able to decode all the pwsz format, you can find the definition here.

Interesting notes:

• If you use AntiAliasing they turn in use pw0 instead, as of course line/contour for AA is very heavy and not worth, this means, if you choose no AA it will render pwsz otherwise pw0
• Can not find the meaning of Coordinate Unknown field, is either Zero or One, not sure when to use 1 or 0...

[sn4k3]

Sure

Whats your machine model?

But I will stick with pw0 for release, since I tested and my vector generation is larger than pw0 compression. (I don't get the perfect lines as I would from the orginal stl)

[Psychokiller1888]

As I said several times, I worked a lot of the slice export, as I'm using a M7 pro, that uses the pwszImg files. I'm slicing with Lychee and offered them help about the export aboht a month and a half ago and then found this GH issue a couple of days ago.

[sn4k3]

Try these two files: fish_fossilz_30m_9ml_UVTOOLS.zip
Print without VAT and a white paper sheet and observe images. One is encoded with PW0 other with PWSZ from UVTools encoder.

As additional note, I find PW0 better than new pwsz, not to say that pwsz doesn't support AA.
PWSZ can only win on regular shapes on all file, even then not worth IMO.

Comparison (First is from AC slicer):

Shape:

[Psychokiller1888]

Thank you, I will try this later, now time to go work. But....

I worked on the .pwsz slice files, for Lychee and helping them integrate the full ecosystem. The last part missing were those pwszImg files. I made hundreds of tests and exports, generation of images. I don't know, maybe you did not read some of my comments, so here some condensate

• Anycubic Photon Slicer doesn't allow you to turn of AA entirely, you always have some AA turned on. You can see it in their "Slicer", and they both export in pwszImg.
• Some parts of the pixel blocks in the pwszImg contain grey level information
• A 10x10 square slice is 68 octets
• pwszImg win over pws0 file because the former only adresses a part of the screen, where the later adresses the entire screen. It results, for a simple 10x10x10 cube stl of a file size 286 times larger using the later.
• Screenshot of a same 50x50x50 cube exported with Photon Slicer, one with AA, the other one """""without""""" AA, meaning, setting left to 1 in the slicer
  

I have more, but I have to go to work now, so I'll report later

[sn4k3]

Anycubic Photon Slicer doesn't allow you to turn of AA entirely, you always have some AA turned on. You can see it in their "Slicer", and they both export in pwszImg.

While they seem to use AA=4 (if you select AA 1 from 4) (In the json is possible to observe that they use a raster_aa of 4 but also in preview), the encoded line does not contain any grey pixel information, it may be just for a better raster and get fewer lines because AA=1 would cause more segmentation. If machine fw then does apply any AA to the raster lines (model) is another topic and not relevant to the format implementation.

AA1 vs AA4 equality proves that they use fixed AA within this levels:

From AA8 to AA16 anycubic start to output PW0 and warns about file size:

Even with AA8 and PW0 generated by anycubic, the file size is lower than pwsz 🤣

Some parts of the pixel blocks in the pwszImg contain grey level information

So far, I can only see colorless XY lines. If you have a sample with grey level information, please send me the sample.

pwszImg win over pws0 file because the former only adresses a part of the screen, where the later adresses the entire screen. It results, for a simple 10x10x10 cube stl of a file size 286 times larger using the later.

I partial disagree. You win with regular shapes or huge shapes where a group of fill poly gives you advantage over rle. In most and real prints people will not print regular shapes that often and most are for the minis (many small areas), not to mention that supports and round shapes starts to kill compression as there are no arc support.

On my previous screenshot you can notice that anycubic pwsz image is heavier than pw0 counterpart, using a corona model with supports, yields in half file size for pw0.
First layers you can observe that pwsz is smaller than pw0, and that's true due the shape of the raft (regular), if you start to scroll layers you notice the complexity of the model defeats pwsz, pw0 weight half for layer 700 as example:

Then I grab a mini model and scale to build plate, as expected pwsz give a slight of advantage because of the single huge area, still is only 3MB better than PW0, and my thought remains, there's no need for pwsz because the size benefits will likely not to happen or when does the difference is small. Machine may raster the pwsz faster, but this is also another topic which need testing.

Then I duplicate the above test and slice two in the plate, as expected pwsz starts to lose!

More complex objects will degrade the pwsz compression over pw0.
Is clear that pwsz will perform worse than pw0 in size for the common people. For who print functional parts it will benefit but who will care for a few MB's if printer perform the same?

Some observations:

• UVtools have some line formats, some even support color information in line, but they are all bad in compression, they are worse than pwsz because they are either vertical or horizontal line (no diagonals)
• UVtools have vector-based file format (SVGX), which are true svg, yields better results than pwsz.

IMO pwsz is a failure, because at this stage they could have come with something better. eg: vectors (svg) which instead of lines can compress into single points and make contours, as so, instead a 17 byte line system they could have 6/8 byte contour system. That way a square would take 3 * 8 bytes = 24 bytes, but currently it does in 4 * 17 bytes = 68 bytes. The vector system would take 2.25x less file size, still without AA support.

Things to consider:

If the machine fw would apply an AA to the pwsz raster then is a valid point to use PSWZ instead PW0, otherwise if they expose raw without AA post-process then is "useless" compared with PW0. This is because PW0 with no AA will compress as good as or better in many situations but if you add AA to PW0 it will increase size for a good margin, yet is possible to oberve some cases with AA=8 yields lower file size than PWSZ by anycubic slicer, so...
This can be tested but will be very hard to notice 1 pixel wide AA. Maybe a phone with good zoom can make this conclusion?

[Psychokiller1888]

I made exports fron AC photon workshop in pwz with AA. I don't think you can turn off AA on their default slicer