I was just going to ask why xsize (width) 
Looks like the height in pnmwindshieldwiper is currently hardcoded to 144 * 10:
It also decides the number of angles: 800
So if that also becomes the POV_DATA_HEIGHT variable, it should work…?
Would all this be easier in a PR?
I have other edits to all this as well.
PRs are always good.
As always I recommend changing one thing at a time if possible. 
Are the angles independent of the height? or would we have to calculate something there either
Height and number of angles (width) are independent.
1 Like
type mismatch.
%d wants to be an integer but we’re giving it size_t maybe?
printf("#define POV_DATA_HEIGHT %d\n", image.ysize());
just cast it
ok. results look too tall.
original
after height edits
@kaQnub could you share the smaller image for tests please?
@profezzorn. 2 side notes.
Running the default tools, running make, I get an error when it tries to download the Star Wars logo, although the link is fine and I can get it in a browser. Any idea?
Also, and a weird one, I also get additional hex data files created aside from the expected 2 data and one preview.png
The tools files themselves get a hex plus an ELF file with DWARF info as a .dSYM packaged version as well?
So I end up with the following files generated in total:
single color data from source .png
full color data from source .png
preview.png
pgmtorle as hex
pgmtorle.dSYM
pnmtorle as hex
pnmtorle.dSYM
pnmwindshieldwiper as hex
pnmwindshieldwiper.dSYM
Looks like you edited the width, not the height.
Do you have wget?
No idea where the hex and dSYM files come from.
We probably need to change pnmescale -height 144 to pnmscale 0.1
Invalid number 0.1
How about pnmscale -reduce 10 then?
Yes that gives a scale of 0.100000.
However, still the too-tall looking result.
P.S> I was missing wget, now that’s fine.
It’s the edit to pnmwindshieldwiper’s height.
I revert that and all else seems to work. Still need to try with an image less than 144.
The example SW logo is 1024x618.
I was trying this:
#define POV_DATA_HEIGHT image.ysize()
int main(int argc, char** argv) {
read_pnm(stdin, &image);
output.resize(800*10, POV_DATA_HEIGHT*10);
No.
The best we can do is to create a command-line flag for the height in pnwindshieldwiper, because it has absolutely nothing to do with the input image size.
side note, I think the hex and DWARF file stuff is from from G++ optimization maybe.
Ok well I have to admit while this is fun and all, I’m not really sure of the goal.
Is it to scale anything larger than 144 down to 144, but smaller images show native resolution?
No, the goal is for the “height” to be identical to the number of LEDs in your blade. That way there is no scaling involved which may make it look better. Also, smaller heights means that it takes less flash memory. The number of input pixels is essentially irrelevant.
We may also want to work on tweaking the width to reduce flash usage.
putting this at the bottom of pgmtorle and pnmtorle:
printf("#define POV_DATA_HEIGHT (%ld)\n", image.ysize());
writes it to the data files, however the value is always what is specified in the pnmwindshieldwiper line
output.resize(800*10, 73*10);
I put 73 in there and that’s what the data files got, even though the input file was 618, or 72, or anything.
*from here on I’ll be using ‘pwsw’ when typing that filename!