Sure, and I was obviously showing a simplification, but it doesn’t change the concept. If you turn on “Full Power”, the top end goes higher. Call it 110 or something. Maybe there’s nothing between 100 and 110, it’s pretty easy to account for that either way.
Again, correct but irrelevant to the point I’m making. I’m not trying to describe exactly how the power is modulated. Without inside information or Glowforge publishing the curves, I can’t do that. This is a simplified model for the purpose of explaining what Precision Power and Min Power do, how they relate to the range of grayscale values in the source image, and how there’s special handling for white. The only thing that “power is not linear” changes about this is the shape of the ramp from min to max. That’s a whole separate discussion, and one I care a lot less about.
I’m having a lot of trouble parsing this. My best guess at what you’re saying is that my scale is incorrect in the following way: since 255 has been stolen away from us to represent transparent, everything should be shifted down such that 254 is the whitest white and not, as I wrote, “Gray 254 (almost white)
”. That’s a valid, but different interpretation of the words. I was referring specifically to the representation of 8-bit grayscale in the source file, independent of Glowforge’s mapping. In Photoshop or Illustrator or whatever, if you have an 8-bit grayscale image, 255 is white and 254 is very light gray.
You may have noted that in my formula, it’s effectively impossible to get exactly Min pews. Take the second example: I put 10 in the Min box, but the actual range is 100 down to 10.4. 255 gray would map to 10 pews, but the rule for “white is transparent” stomps on that value and clamps it to 0. So you can’t hit exactly 10 pews. As has been noted by experts in the field, there are three unsolved problems in computer science: naming things and off-by-one errors. Knowing how programmers think and how the code is likely to be implemented, I think my formula is probably close to the one used, and in the grand scheme of things it’s not important.
If that’s what you’re referring to, then there is of course a trivial change to make it work the way you’re describing. Perhaps the programmer who implemented this was thinking about it that way and came up with (254-Gray)*((Power-Min)/254)+Min instead. Table 2 would come out like this:
Gray 0 (black) -> 100.0 pews [math: (254-0)*(90/254)+10]
Gray 1 (almost black) -> 99.6 pews [math: (254-1)*(90/254)+10]
Gray 2 -> 99.3 pews [math: (254-2)*(90/254)+10]
[...]
Gray 128 (midpoint) -> 54.6 pews [math: (254-128)*(90/254)+10]
[...]
Gray 253 (almost white) -> 10.4 pews [math: (254-254)*(90/254)+10]
Gray 254 (white) -> 10.0 pews [math: (254-254)*(90/254)+10]
Gray 255 (transparent) -> 0 pews [no math, white is always ignored]
It’s a very subtle difference. In fact, it’s so subtle that Table 3 doesn’t even change, if you keep it to one decimal place. (You can do your own math now, I’m tired.)
If there was some other point you were making, it’s lost on me.
Let’s not. I deliberately kept my examples to the actual numbers used in the computer. There are no negatives or infinities in either the PNG-8 scale or the Glowforge pew scale. The way I choose to represent white is by saying “off”, “ignored”, or “0 pews”, which all mean the same thing. No angry pixies come out of the laser when your file is white (255) because (all together now) white represents transparent.