need help about lcd-image-converter

[riuson]

Ok, I understand format...
☑

0011111111111100
0100000000000010
0100001000000010
0100011000000010
0100110000000010
0101100000000010
0100011000000010
0100000110000010
0100000001100010
0100000000011010
0100000000000010
0011111111111100

[riuson]

Script inside this html page is not working in my browser.

[riuson]

84x16_IronOS.txt

Ok. There is scanning from latest column to first. Image is flipped horizontally.

replace the white space with carriage return & line feed after every 28th

This is completely unnecessary. The compiler doesn't care about the length of the code line.
If you are worried about the appearance of the code, you can use utilities like AStyle. All source code of the lcd-image-converter is formatted using that utility.

[riuson]

The image you provided in first message does not match the byte array. It is only slightly similar.

I have attached preset what you can import in app's options dialog - discip.zip

Demo:

Font.h#L40:

0xFC, 0x02, 0x02, 0x02, 0x02, 0x02, 0x02, 0x82, 0x62, 0x1A, 0x02, 0xFC,
0x3F, 0x40, 0x42, 0x46, 0x4C, 0x58, 0x46, 0x41, 0x40, 0x40, 0x40, 0x3F, // ☑ (check box on, menu true)

[riuson]

1. What is reverse line order?
2. May be, depends on the cause of the occurrence. But compiler is indiffirent to this.
3. No. But compiler is indiffirent to this.

Above, I gave the settings that produce the same result as specified in the project. Why aren't you using it?

[riuson]

Ah sorry I used the term notepad++ uses to swap the first line with the last, the second with the forelast ...

This swapping is already enabled in my preset.

---

But you said yourself that this setting is not applicable to the image I posted initially.

Yes. Because your image is seems not correctly encoded for algorithm from here:

It is used in this software: https://github.com/Ralim/IronOS/blob/master/source/Core/Drivers/Font.h

Difference seems like missing lines on border. You can decode your byte array by my table posted above. This is example for 12*16 character ☑.

Start of decoding:
0x00, 0xE0, 0x18, 0x04, 0x02, 0x02, 0x01, 0x41, 0x61, 0x61, 0x61, 0xE1, 0xC1, 0x81,

00000000 <<<<<<<<<<<< this column is missing on your image, top left corner
11100000
00011000
00000100
00000010
00000010
00000001
01000001
01100001
01100001
01100001
11100001
11000001
10000001

[riuson]

Hello,
Unfortunately, I'm not a cryptanalyst.
Conversion requires knowing the format of the output file.

[discip]

@riuson
Good afternoon sir,
first of all thank you for having reacted to this post. 😃👍
Please don't be offended by my approach, since I am not familiar with this kind of topic, I thought the 'source' and the 'result' would suffice. 😁
I used your tool to convert the picture above but was not able to get it done no matter what I choose, it was almost the same but not exactly.
What exactly do you mean by format? 😅

The things I know are:

1. monochrome
2. 8 bit
3. 84 x 16
4. left to right

That is what I am getting, if I use your tool:

0x07,0xe0,
0x18,0x18,
0x20,0x04,
0x40,0x02,
0x40,0x02,
0x80,0x01,
0x80,0x41,
0x80,0x81,
0x81,0x01,
0x82,0x01,
0x84,0x65,
0x8a,0x99,
0x92,0x01,
0x82,0x01,
0x82,0x01,
0x82,0x01,
0x80,0x01,
0x82,0x01,
0x80,0x01,
0x82,0x01,
0x82,0x01,
0x82,0x01,
0x87,0x01,
0x87,0x01,
0x85,0x01,
0x87,0x01,
0x85,0x01,
0x87,0x01,
0x87,0x01,
0x85,0x01,
0x85,0x01,
0x85,0x01,
0x85,0x01,
0x87,0x01,
0x82,0x01,
0x80,0x01,
0x40,0x02,
0x40,0x02,
0x20,0x04,
0x18,0x18,
0x07,0xe0,
0x00,0x00,
0x00,0x00,
0x07,0xe0,
0x18,0x18,
0x20,0x04,
0x40,0x02,
0x40,0x02,
0x80,0x01,
0x80,0x01,
0x82,0x41,
0x86,0x61,
0x86,0x61,
0x86,0x61,
0x87,0xe1,
0x83,0xc1,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x81,0x81,
0x83,0xc1,
0x87,0xe1,
0x86,0x61,
0x86,0x61,
0x86,0x61,
0x82,0x41,
0x80,0x01,
0x40,0x02,
0x40,0x02,
0x20,0x04,
0x18,0x18,
0x07,0xe0,
0x00,0x00

thanks in advance

[riuson]

Data format.
Description of each byte in resulting array.

Are you have a code what draws image from this array?

[discip]

It is used in this software: https://github.com/Ralim/IronOS/blob/master/source/Core/Drivers/Font.h
But unfortunately I do not know, which part is responsible for decoding the arrays. 😅

[riuson]

Can you provide rendered images for ☐, ., | ?

[discip]

I have compared the two arrays mentioned above and realized: The code itself is the same except for the fact that it is arranged somewhat differently:
To put it the way I would need it I would have to read the code (which was generated by your tool)

from bottom right to the top right and then
from the bottom left to the top left

and afterwards write it down

from left to right and top to bottom
divided into 6 equal chunks. Hopefully I made myself clear enough. 😅

[discip]

Sorry, but I can't since I am only seeing the rendered images on the Iron.

[discip]

@riuson
Maybe this could be of any help:
https://github.com/Ralim/IronOS/blob/master/Translations/BitmapEditor.html

[discip]

I think I am close to the solution with this:
IronOS _almost.txt

The only additional steps I have to perform are:

1. reverse line order
2. delete carriage return and line feed
3. insert the carriage return and line feed after every 28th , (comma)

Can this be achieved with your software as well?

[discip]

1. Ah sorry I used the term notepad++ uses to swap the first line with the last, the second with the forelast ...

Above, I gave the settings that produce the same result as specified in the project. Why aren't you using it?

But you said yourself that this setting is not applicable to the image I posted initially.

The image you provided in first message does not match the byte array. It is only slightly similar.

[discip]

@riuson

Again a big thank you for this software and the effort you took on to help me figuring this out! ❤👍

Here is the setting attached that did the trick (The only thing I have to do manually, is to replace the white space with carriage return & line feed after every 28th ,) 😅
84x16_IronOS.txt

[discip]

Thank you!