I am literally running just the above makefile in the default files, no edits, and it works perfectly.
On the saber? It converted correctly but after I swung this, the board froze. Only after changing the pov.h was it running smoothly.
Or are we still scaling now and that’s not what we want?
Kinda lost on the whole “why” on this height thing.
Should the question be “What’s the blade length in pixels?”
Or “do you want a smaller image than full blade?”
You took a 1814x1814 image and went down to 72 pixels . Cool. But why?
That’s it, at least for my understanding.
Edit:
In Theorie this might look better, because the data won’t have to be scaled at run-time.
As @profezzorn mentioned it is definitely saving flash memory.
Of course if you have a multiple blade setup you might need the one for the longest blade, but not sure what would happen if I would run the 72 height image on my longer npxl blade. Maybe I can try that out tonight. Or then it will scale up, what might look worse.
Because I have a 72 NPXL blade. That is the beauty that it makes this easy and I am not limited to pictures already in the size for my desired blade.
One source image can be used for different performance and flash memory optimized images.
Ok well going to have to have Fredrik chime in again.
The question now is how things work really.
We’ve learned we can set a height in Makefile for all the tool files to use, and things get processed accordingly, AND width seems to follow in relation.
You’ve said that without changing pov.h to the same height value, it seems to show up scaled correctly, but freezes the board…I think.
We know how to pass height to pov.h in a variable, and I figured out how to pass it to pnmwindshieldwiper (although then the scale for width is either wrong or needs to also be set).
I guess the next step is to confirm that Makefile changes only does indeed have a freezing problem.
If yes, does the pov.h using the height variable fix it on it’s own, or does pnmwindshield wiper also need changes.
I should probably fire this stuff up on a real blade…
I figured out how to pass a command line argument of HEIGHT=N to
I think I’m getting confused between scaling in the image process, and scaling in real time on the blade.
We’re looking to avoid the latter I think. Scaling in pre-process shouldn’t be as degrading as in real time in the air?
POV.h changes should suffice. No windshield changes required. At least that unfroze it for me completely.
The last actual picture was with the 72 Height data file.
I believe what Fredrik suggested was for us to make the EZ POV source files printing a line into the *data.h file with the image.ysize info, so when we define the Filename pov.h can access that height info and use it instead of the 144.
Yes, the latter. That is what we hope/believe at least. Maybe performance wise it could help as well, due to the size is already correct.
Right ok. So that’s adding the print lines to pgmtorle and pnmtorle, then editing all the hardcoded 144’s in pov.h to the variable.
ok. But he mentioned wiper too, so …that’s what started me down a long dark discovery/learning path
and while that can also be passed a HEIGHT variable, there’s some magic it does on it’s own before editing that already scales things in proportion, which goes away if the height is specified and not the width. Well, in the coding I did at least.
So maybe that’s the sticking point here.
Let me see what step one does for me. The conversion looks correct, but that’s all I’ve seen with eyeballs (the preview.png resulting size)
I know, but I think that might not be necessary and led us down the wrong rabbit hole. At least I did not do that and it runs great, with the benefits of at least saving flash memory. The picture I managed to do was also quite good.
Initial test. put 72 in. all looks like it generated 72. Real blade seems like full blade. I am going to do a full height color image so I can see defined edge of image, and also try something that should clearly be smaller, like 30.
Meanwhile, on a not-great note… Do you have flashes of image if you CLASH the blade when OFF?
Because that’s happening currently to me.
Have to check. Not sure. Will let you know.
Select POV font, turn off the blade, clash hilt while in an angle it would show pieces of the image?
Expectations: you don’t see anything.
Actual behavior: it flashes the image part? Is that it?
I cannot reproduce that behavior. When my saber is OFF I don’t get flashes while clashing the hilt or anything.
yes. So a few weird issues.
- image height at 72, 30, 10 all look the same, taking up I’d say 90% of the blade, and centered top to bottom. Emitter and tip are dark.
- Tried image at HEIGHT=144. Well, that’s causing the board to crash after boot.wav plays. Even got a squee-of-death once of the 4 tries. Board doesn’t come back unless BOOT+RESET each time.
- Went back to HEIGHT=10 and works fine, although again almost full blade.
- When it does work, the blade shows spots of the image WHILE off, when clashed or even on its own sitting idle.
So we broke something maybe, or it’s something buggy we’re just finding now or ¯_(ツ)_/¯.
I don’t see why altering wiper would do anything. It seems we just double scale it, unless I see this wrong, but the recipe calls for wiper first, then pnmscale via netpbm. THAT’s the spot we’re setting the $HEIGHT, then onto hex creation last.
So wiper makes it 800x144, then pnmscale takes it down to something like10 from my example.
Upload using default pov_tools, custom FC image. Freezing board. Oddly, at the moment only our SMALLER than 144 images are NOT crashing the board!
Trying default image now. SC version.
Same lit random when off, but no board freeze.
Can definitely stab the ground when ON and gets bursts of light when the clash registers. The image is off at the bottom part of the arc, but prominent display of light with each stab of the ground.
Do you get that?
Maybe it’s blade or hilt PCB, but I’m fairly certain all is well in wiring and condition of this test saber.
It IS a 3.7 board, so that’s another variable I suppose.
Trying FC of default SWlogo.
Still lights when they don’t belong. No crashing.
And unfortunately, I see zero scaling on any settings, files, versions etc.
all look pretty much full blade.
So it looks like nothing accomplished 
What blade do you use?
My guess is a 72 Height image will be optimized for a 72 NPXL blade but it will scale up, if you choose to put in a longer blade. Basically the same way before it scales down from 144 to anything you have.
But from a image manipulation perspective scaling up should be more visible than scaling down.
But that is not the point. The Idea was to know your blade length of X NPXLs and therefore use an optimized Image with a height of X.
I also witnessed that the image will always be filling up the blade length, even if in the original image I provided black areas. My guess is that there is somewhere an algorithm that reduces the image to the content. But even when a little confusing, I made my peace with it. At least it would be a different issue.
The POV image will stay the same, but the the image is smaller, will reduce flash memory usage (from 144 to 72 about 50%) and maybe even perform better because OS will not have to scale during runtime.
The good news is I have the script working well, and the ability to set the data file from te config file.
This gets added to ProffieOS.ino just before the StyleAllocator class:
#define CONFIG_POV
#include CONFIG_FILE
#undef CONFIG_POV
this goes in config, just like a prop;
#ifdef CONFIG_POV
#include "../styles/ShadowfoilLogo_FC_POV_data.h"
#endif
and remove the #include line in pov.h