Somewhere (SPI Interface?) there is a MSB/LSB swap when using the converter with ESP32 and the U8g2 library
which distorts the output.
I checked with 1bit per pixel output but added an optional bitswap checkbox, a function to do optinal swap and
added it to all output functions.
The lvgl online converter has got the same problem. Maybe there is is something wrong with the u8g...
Since endian is a traditional an generic issue I thought it's probably a nice feature inside the converter
which at least works fine for me.
UI changes:
- added a "Transparent" option in "Background color" selection
- replaced drawMode radio buttons with a drop-down list
- added a div (id=note1bit) around the note to switch to vertical mode
Code changes:
- added a ConversionFunctions object to hold the conversion functions (this makes it extendable towards more formats)
- renamed imageToStringHorizontal() to horizontal1bit()
- renamed imageToStringVertical() to vertical1bit()
- added horizontal565() to generate 16 bit 565 RGB images
- added horizontalAlpha() to generate transparency masks based on the image alpha value
- added conversionFunction to settings object
- added updateDrawMode() to handle the draw mode selection - also hides the note when using the new modes
- updated place_image() to skip background fill in case transparency is selected
- updated place_image(), commented out the conversion to black & white. Not sure at this time how to enable it again... drawMode?
- updated imageToString() to use the conversionFunction from settings
- moved getting the image raw data array from the conversion functions imageToString()
This should finally fix the problem with small images getting distorted.
Problem appears to have been that with some sizes (basically
everything that wasn't divisible by 8) the last part of a row would be
merged with the first part of the last row, creating an offset that
increased with every next row.
This update pads every last byte of a row with zeros to fill out to 8
bits.
Closing #21
Some images didn't get converted properly. This was easy to
spot in smaller image where the last part seemed to be missing.
Each of the hex values generated stands for a byte = 8 bits =
8 pixels. But sometimes the size of the image caused the last
hex value to contain less than 8 bits (because there weren't
enough pixels left). As the hex values represent 8 pixels being drawn
right to left, the missing bits would cause the pixels to move out
of the canvas.
The solution is to always pad the last hex to a length of 8.
.
javl
plewkaandGitHub
Daniyal-Warraich
Harry Best
Sebski123andGitHub
Adam KumpfandGitHub
hurricaneJoefandGitHub
Jochen Derwae
javl
whoisnian
davidalim