Closed riuson closed 10 years ago
From riu...@gmail.com on January 04, 2014 07:02:25
Status: Accepted
Owner: riu...@gmail.com
From riu...@gmail.com on January 08, 2014 00:45:15
Try compile revision 005d957022d11d063df5f9f5f1df39ef7fa7f273 from sources.
Endian should not reverse order of bits in bytes. Endianness defines only byte order for multibyte data (16 or more bits). Bits order can be changed in Reorder section of Settings: https://code.google.com/p/lcd-image-converter/wiki/OptionsConversionReordering
Status: Started
From djeffdio...@gmail.com on January 08, 2014 03:39:53
This is improved, thank you for taking the time to look at it. This is much closer:
The character " (double quote) is a 4 wide 12 high pixmap
Options: Inverse, Left to Right, Monochrome, 8 Bit Blocks, Split Rows
Expected result:
0xc0, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00
(Each column is 12 bits, packed into 2 bytes, 4 columns, reading top to bottom)
Preview result:
0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x00
The ! (exclamation point) character is 3 wide by 12 high
# # # # # # #
#
Expected result:
0x00, 0x00, 0xfe, 0x80, 0x00, 0x00
Preview result:
0x00, 0x00, 0x00, 0x00, 0xe0, 0xe0, 0xa0, 0x00, 0x00, 0x00, 0x00, 0x00
From riu...@gmail.com on January 08, 2014 05:54:06
Expected result:
0xc0, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00
-> Disable 'Split Rows' option.
From djeffdio...@gmail.com on January 10, 2014 22:00:48
Thanks for this, sorry for the delay in testing again.
With 'Split Rows' disabled, the bits are correctly packed into blocks (bytes in this case). That is, a new column does not start a new block, it continues (correctly) in unfilled blocks for maximum density. The " (double quote, 12x4) preview:
0xc0, 0x00, 0x00, 0xc0, 0x00, 0x00
However, if Split Rows is checked the preview is:
0xc0, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x00
This seems still not quite correct. Block size is set to 8 bits. Height (Left to Right, so a 'row') is 12 bits, which takes 2 bytes (8+4 bits, plus 4 spare bits). Therefore, since the character is 4 wide, that is, 4 'rows', totally 8 bytes. It appears however that each 'row' here is 3 bytes long for some reason (there is an off by one error, perhaps, in row byte count?) and here we have 12 bytes. I really do think the expected output with "Split Rows" should be:
0xc0, 0x00, 0x00, 0x00, 0xc0, 0x00, 0x00, 0x00
I also recommend the Split Row option might be better labeled 'Pad to Block Size' or something like that, just for clarity :-)
Cheers and thanks again for your help, sorry for being pedantic. J.
From riu...@gmail.com on January 12, 2014 08:54:49
Confirmed. Image 'prepare' code was too optimized for the previous version, without the use of scripts. Need time to investigate.
From riu...@gmail.com on January 17, 2014 10:13:45
Try revision 086117fc5393793c828b86562e557e6522a8e3b2 .
From riu...@gmail.com on February 15, 2014 06:06:20
This issue was closed by revision 9625c712980c .
Status: Fixed
From djeffdio...@gmail.com on January 03, 2014 18:26:29
What steps will reproduce the problem? Create font with character "!", 12 px high.
Endian should reverse order of bits in bytes (when in monochrome) What version of the product are you using? On what operating system? Built from git c026d86327e5f04f3abec55993f611256557efd6 on Mac OS X 64 bit. Please provide any additional information below. Hypothesis: because monochrome packs multiple pixels into bytes, reordering is incorrect... algorithm operates on whole bytes.
Original issue: http://code.google.com/p/lcd-image-converter/issues/detail?id=19