[Bug] Transition Layer Exposure Time Discrepancy between UVtools and Reality

[Chainsoroth]

System

UVtools v5.0.5 X64
Operative system: Microsoft Windows 10.0.22631 X64
Processor: AMD Ryzen 9 7950X3D 16-Core Processor          
Processor cores: 32
Memory RAM: 15.44 / 63.12 GB
Runtime: win-x64
Framework: .NET 9.0.0
AvaloniaUI: 11.2.3
OpenCV: 4.9.0

Path:       C:\Users\dauer\UV Tools\
Executable: C:\Users\dauer\UV Tools\UVtools.exe
Loaded file: TransTest.ctb [Version: 5] [Class: CTBEncryptedFile]

Printer and Slicer

• Printer: Elegoo Saturn 4 Ultra (FW 41.28)
• Slicer: ChituBox (v2.3)

Description of the bug

UVtools is showing wrong transition layer exposure times for a .ctb and .goo file sliced in ChituBox.
Print Settings: 2 Bottom Layers @ 20s, 5 transition layers, 2,1sek normal layers
Expected behaviour: Two layers @ 20s and then 5 Layers decreased by 2,98s every Layer.

Times shown in UVtools:
Layer 0: 20s
Layer 1: 20s
Layer 2: 17,76s
Layer 3: 15,52s
Layer 4: 13,29s
Layer 5: 11,05s
Layer 6: 8,81s
Layer 7: 2,1s

Times measured with a stopwatch at the printer:
Layer 0: 20s
Layer 1: 20s
Layer 2: 17,3s
Layer 3: 14,1s
Layer 4: 10,9s
Layer 5: 8,1s
Layer 6: 5,1s
Layer 7: 2,1s

Regarding my reaction times in handling the stopwatch, the measured data seems to be completely in the range of expected values (2,98s decrease in exposure time per Layer).

But UVTools shows completely different values.

How to reproduce

Shows up in every opened .ctb .goo file. (See attached file)

Files

TransTest.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]

It's expected to have a small difference. Your printer uses hardware transition layers, the time is controlled by firmware and not by file. As so UVtools recreates the exposure time based on a simple math which can or not match the printer math for transition exposure time.
We have no control over it, other than selecting the number of transition layers, printer will do the rest...

Also, your measurement test is not accurate (Have a potential error), unless you do a video and use the frames to get the actual time between exposures. I won't consider that tool valid for this test, >200ms can easy pass between your action to lapse the timer.

[Chainsoroth]

In other words the math/formula/calculation in UVtools is faulty.

And I think I have an idea, what is wrong about it.

I (and Chitubox it seems) would calculate the time decrease per transition layer as followed:
("Bottom Layer Time" - "Normal Layer Time")/("# of Transition Layers" + 1) --> (20s-2,1s)/(5+1) = 2,98s

And it seems that UVtools calculates:
("Bottom Layer Time" - "Normal Layer Time")/("# of bottom Layers" + "# of transition layers" + 1) --> (20s-2,1s)/(2+5+1) = 2,24s

I testet it by increasing the number of bottom layers and the shown transition layer decrease time in UVtools also gets smaller.

[sn4k3]

UVtools calculates the step like you have in chitu formula:

UVtools/UVtools.Core/FileFormats/FileFormat.cs

Lines 5254 to 5259 in 27f46ff

	public static float GetTransitionStepTime(float longExposureTime, float shortExposureTime, ushort transitionLayerCount)
	{
	return transitionLayerCount == 0 || longExposureTime == shortExposureTime
	? 0
	: (float)Math.Round((longExposureTime - shortExposureTime) / (transitionLayerCount + 1), 2, MidpointRounding.AwayFromZero);
	}

If you go to layer 2 you can see the information is right both in UVtools and File

The bottom information has "different" information from your observations, which don't matter much as that is just a representation for HW controlled exposure. However you should get what layer table says when it's controlled by File, which in your case is not, it is controlled by firmware and they maybe use other formula! In other words no matter what time UVtools shows or set it won't make any difference, UNLESS you turn the flag to follow layer table instead of firmware globals.

Also 20s - 17.76s = 2.24s which is why bottom says 5/-2.24s

That reading comes from the file which was populated by slicer in first hand (Not UVtools):

UVtools/UVtools.Core/FileFormats/FileFormat.cs

Lines 5238 to 5245 in 27f46ff

	public float ParseTransitionStepTimeFromLayers()
	{
	if (LayerCount < 3) return 0;
	var transitionLayerCount = ParseTransitionLayerCountFromLayers();
	return transitionLayerCount == 0
	? 0
	: (float)Math.Round(this[BottomLayerCount].ExposureTime - this[BottomLayerCount + 1].ExposureTime, 2, MidpointRounding.AwayFromZero);
	}

[Chainsoroth]

Thank you for the further clarification!

To conclude the findings:
ChituBox saves "incorrect" transition layer exposure times into the layer data.
BUT, it is of no consequence due to my (most?) printers use firmware based calculations for the transition layer exposure times, which leads to correct exposure times(/correct decrease in exposure time).

UVtools displays the decrease in exposure times which it finds between the last bottom layer and the first transition layer. Thus showing "technically correct" data.

Again, thanks for clarifying and sorry for my persistence. My lack of knowledge really annoyed me and I needed to understand the connections between everything.

[sn4k3]

Your printer can use custom transition times set by you, but the default for most printers that offer native transition is hardware.
Using your own time will require set a flag but I do not recommend just for it.
The transition time is just to smooth the time diference reducing a brute exposure diference and avoid potential visual artifacts, it does not matter for prints on a raft. It's more useful for prints direct on build plate, and even then, as you use 2 bottom layers and low bottom exposure you will not get any benefit out of it.
If your measurements are correct, the difference is not even worthy of such concern.