Apply custom images to Ford Convers+

[Gwe89]

For me, as long as the changes to GUI are not very big from a version to another, it is easy to have the new version in both layouts: just change the name of the layout that it's going to be used and press a button to compile the application.

The only drawback of this wide layout is that it doesn't fit that well in QT Graphical Designer

gives this area tho to maybe put the buttons there?

newCH.PNG

[Gwe89]

Ptc heater before Screenshot_20210101-200732_Skype.jpg

Ptc heater now
20210103_104004.jpg



The new CH has become very useful thank you again DGAlexandru


A bit more editing just about right now, maybe just a tad smaller20210103_134241.jpg

Got there in the end very happy with the outcome

20210103_164448.jpg

[DGAlexandru]

Those buttons are "special"... they are defined as Menu Actions and can be also presented like this. You can move them anywere in the app for that session only.

[DGAlexandru]

All images stored in Flash in this format:
===================================
00 00 00 FF 01 00 00 00 - Header
...
... RLE-Encoded (with zero-pad)
...
XX XX - width
XX XX - Height
XX XX - width
00 00 - <probably> Height - but seems like always 00 00
30 XX XX XX - PTR to start of data frame
30 XX XX XX - PTR to start of image
00 00 56 38 - End of image (EOI)
===================================

Today I found out that the above "Header" of the image contains actually other information and in certain situations might be different.. so the way we were using this format in CH to find images in Main or Extended Flash is ... wrong

The above table translates to:
===================================
00 00 00 XX - number of colors for image - usually, yes, XX = 0xFF = 255 (Curious if I can put more than 0x00FF and Convers will be able to show it)
01 00 00 00 - unknown for now
XX XX XX XX - offset of where is LUT table for this image (BGR format). If all are 00, then use the current Theme LUT table.
...
... RLE-Encoded (with zero-pad)
...
XX XX YY YY - X = Width, Y = Height (Offset in flash for the first byte = Offset4Main in CH and represents the only information that IPC algorithm needs to know in order to show an image)
XX XX 00 00 - X = number of bytes per line (usually this is equal with width); 00 00 seem to be present only to keep data aligned in a 4-byte format
YY XX XX ZZ - pointer / offset to image data (the RLE-Encoded image part); YY = 00 then it's in Main Flash; 30 it's in Extended Flash; ZZ = (VV - 0x0C)
YY XX XX VV - pointer / offset to image frame; YY = 00 -> in Main Flash; 30 -> Ext. Flash; This is the offset where we find the first bytes that are explained in this table
00 00 56 38 - End Of Image (EOI) - I think this exists only to be able to try to see if there is an image here when you don't have an "Offset4Main"; for the designing software... or tools like CH
===================================

In CH we were looking for the Header then the EOI and what was in between together with those 2 was considered to be image frame.
Because we were looking only for "00 00 00 FF 01 00 00 00" we couldn't detect some images... that are present in custom firmware
Also, because of this, there were images in custom FW with logos that couldn't be decoded or made CH crash - the bytes that contain the offsets for image data and frame are changed for the original image with bytes that contain offsets for the new image. This means that if you want to change an image all you have to do is to go to original image and change them. There is no need to go to Main Flash and change there the offset "Offset4Main" - even if it also worked this way.

Flashing back Main Flash is faster that flashing Extended Flash. So if you want to replace an image, from my point of view, if you also modify Main Flash then you only need to write a sector (or how many are needed for that image to be stored in Ext. Flash) instead of entire Extended Flash.
The easy way which takes longer to flash back is to modify only Extended Flash.

I'll come back with an updated version of CH that will have this new algorithm in order to find all the images... and maybe also the option to have a VBF that contain all what is needed to be flashed back to Extended Flash.

[sanndo]

I'll come back with an updated version of CH that will have this new algorithm in order to find all the images...

Gread job.. again!!

[Gwe89]

All images stored in Flash in this format:
===================================
00 00 00 FF 01 00 00 00 - Header
...
... RLE-Encoded (with zero-pad)
...
XX XX - width
XX XX - Height
XX XX - width
00 00 - <probably> Height - but seems like always 00 00
30 XX XX XX - PTR to start of data frame
30 XX XX XX - PTR to start of image
00 00 56 38 - End of image (EOI)
===================================

Today I found out that the above "Header" of the image contains actually other information and in certain situations might be different.. so the way we were using this format in CH to find images in Main or Extended Flash is ... wrong

The above table translates to:
===================================
00 00 00 XX - number of colors for image - usually, yes, XX = 0xFF = 255 (Curious if I can put more than 0x00FF and Convers will be able to show it)
01 00 00 00 - unknown for now
XX XX XX XX - offset of where is LUT table for this image (BGR format). If all are 00, then use the current Theme LUT table.
...
... RLE-Encoded (with zero-pad)
...
XX XX YY YY - X = Width, Y = Height (Offset in flash for the first byte = Offset4Main in CH and represents the only information that IPC algorithm needs to know in order to show an image)
XX XX 00 00 - X = number of bytes per line (usually this is equal with width); 00 00 seem to be present only to keep data aligned in a 4-byte format
YY XX XX ZZ - pointer / offset to image data (the RLE-Encoded image part); YY = 00 then it's in Main Flash; 30 it's in Extended Flash; ZZ = (VV - 0x0C)
YY XX XX VV - pointer / offset to image frame; YY = 00 -> in Main Flash; 30 -> Ext. Flash; This is the offset where we find the first bytes that are explained in this table
00 00 56 38 - End Of Image (EOI) - I think this exists only to be able to try to see if there is an image here when you don't have an "Offset4Main"; for the designing software... or tools like CH
===================================

In CH we were looking for the Header then the EOI and what was in between together with those 2 was considered to be image frame.
Because we were looking only for "00 00 00 FF 01 00 00 00" we couldn't detect some images... that are present in custom firmware
Also, because of this, there were images in custom FW with logos that couldn't be decoded or made CH crash - the bytes that contain the offsets for image data and frame are changed for the original image with bytes that contain offsets for the new image. This means that if you want to change an image all you have to do is to go to original image and change them. There is no need to go to Main Flash and change there the offset "Offset4Main" - even if it also worked this way.

Flashing back Main Flash is faster that flashing Extended Flash. So if you want to replace an image, from my point of view, if you also modify Main Flash then you only need to write a sector (or how many are needed for that image to be stored in Ext. Flash) instead of entire Extended Flash.
The easy way which takes longer to flash back is to modify only Extended Flash.

I'll come back with an updated version of CH that will have this new algorithm in order to find all the images... and maybe also the option to have a VBF that contain all what is needed to be flashed back to Extended Flash.

Interesting stuff you know what your doing, one thing I have been wondering how does the background of an image change colour when you change theme colour, I'm pretty certain its the lut do the images have to be coded a certain way so it will work with the selected theme

[DGAlexandru]

Yes.
Let's say your first pixel in an PNG image is pure green... and the image has max 256 colors.
When you RLE encode it, it takes the RGB values of this pixel and tries to find in LUT table the best match.
In Theme 1 you have it at element 10 and in Theme 2 you have it at element 20. Also in Theme 2 element 10 is pure red.
So if the image is encoded using Theme 1 for first pixel it writes that it should use color from position 10 from LUT table.

When you show it on screen the first pixel that is now encoded with position 10 is shown with the color that is present in current LUT table at position 10.
For Theme 1 this pixel will be pure green.
For Theme 2 this pixel will be pure red.

[tomy75]

My new red car

[Drago]

It looks great!

[Gwe89]

My new red car

Looks good, I was looking at trying to make one that looked more like an smax but can't get it quite right