This is a program that I wrote to decode the newer style "logo.bin" files used in some OPPO, and OnePlus devices. Please read below so you can better understand this type of encoding being used:
The attachment contains the C source code (which is also in the 2nd post) and the executable that was compiled using mingw32 on a 64 bit Windows 7 pc. The png library that I used is LodePng, the source is in the download.
To use logoinjector:
Decode your logo.bin:
All the PNG 's will be extracted from logo.bin. Edit the PNGs that you want to change...
Inject the image(s) back in to the logo.bin:
To list whats in your logo file:
For a more detailed list:
If the colors are messed up use the "-s" switch while decoding.
If you had to use the "-s" switch to decode properly, you'll have to use it to inject also:
The size of your modified.logo.bin will displayed along with the original size, if everything went good. Please know the size of you logo partition. I made this program to encompass any device using this format, and there is no set size of the logo partition between devices. Fastboot will just error out if you try to flash data bigger than the partition before it writes anything. But if someone gets brave and trys to "DD" to the logo partition, it could get ugly.:cyclops:
Flash the "modified.logo.bin" file through fastboot.
v1.2
Use this at your own risk.
Always make backups.
Always.
What Is A Raw Image?
A raw image, whether it be a file or an image in memory, is simply pixel data. There is no extra information like width, height, name, end of line... Absolutely nothing, just pixel data. If you have an image that is raw and the resolution is 1080x1920 and you are using a typical RGB24 or BGR24 (like the ones used here), then your exact filesize or size in memory will be 1080x1920x3! We use 3 here because there is one byte for the R or red component, one for the G (green), and one for the B(blue).
What Is A Run Length Encoded Image?
A run length image encoding uses a count ;usually a single byte (char), 2 bytes (short int), or 4 bytes (long int); and then the pixel components. So instead of writing out 300 bytes of '0's to make a line of 100 black pixels. Black is RGB(0,0,0). You could encode this as 100, 0, 0, 0. And only use 4 bytes of data to get the exact same image as the 300 byte raw image. All the run length encoding I've found, except the Motorola style which is a little different, use a run length encoding that is pixel-oriented like this.
Now I've figured out this new one and it is a byte-oriented run length encoding. This is for runs of bytes, not pixels. You may think, well whats the big deal? When you add a little area of color, you increase the run length encoded image in you logo.bin immensely! You use 6 bytes per pixel if there aren't any runs of color data. If you had an image that was a 1080x1920 black image with a 25 pixel wide, by 25 pixel high red box in the middle. The encoder would be doing runs of black data efficiently until it reached the red area.
.....0 255 0 255 0 255 0 255 0 255 0 133 /// we've reached the top left corner of the red square /// 13 1 30 1 255 1 // << that was just one red pixel!! in bgr color order (13, 30, 255) <<// And it keeps going through the rest of the red pixels on that line using 6 bytes per pixel, which is the opposite of compression. Before reaching the red square the encoding was decoding to 255 zeros over and over, until finally 133 zeros. 255 zeros is 85 black pixels stored in just 2 bytes!
This type of encoding is only good for grey scale images. It is not good with color, but it still will handle color of course. In grey scale, the Red, Blue, and Green data components are always the same values. All the way from black (0,0,0) to white (255, 255, 255); including every shade of grey in between>>>(1,1,1) (2,2,2) (3,3,3)....(243, 243, 243) (244, 244, 244)<<<
One other difference in this method of run length encoding is that the color byte is before the count, which is backwards from all of the other methods.
A raw image, whether it be a file or an image in memory, is simply pixel data. There is no extra information like width, height, name, end of line... Absolutely nothing, just pixel data. If you have an image that is raw and the resolution is 1080x1920 and you are using a typical RGB24 or BGR24 (like the ones used here), then your exact filesize or size in memory will be 1080x1920x3! We use 3 here because there is one byte for the R or red component, one for the G (green), and one for the B(blue).
What Is A Run Length Encoded Image?
A run length image encoding uses a count ;usually a single byte (char), 2 bytes (short int), or 4 bytes (long int); and then the pixel components. So instead of writing out 300 bytes of '0's to make a line of 100 black pixels. Black is RGB(0,0,0). You could encode this as 100, 0, 0, 0. And only use 4 bytes of data to get the exact same image as the 300 byte raw image. All the run length encoding I've found, except the Motorola style which is a little different, use a run length encoding that is pixel-oriented like this.
Now I've figured out this new one and it is a byte-oriented run length encoding. This is for runs of bytes, not pixels. You may think, well whats the big deal? When you add a little area of color, you increase the run length encoded image in you logo.bin immensely! You use 6 bytes per pixel if there aren't any runs of color data. If you had an image that was a 1080x1920 black image with a 25 pixel wide, by 25 pixel high red box in the middle. The encoder would be doing runs of black data efficiently until it reached the red area.
.....0 255 0 255 0 255 0 255 0 255 0 133 /// we've reached the top left corner of the red square /// 13 1 30 1 255 1 // << that was just one red pixel!! in bgr color order (13, 30, 255) <<// And it keeps going through the rest of the red pixels on that line using 6 bytes per pixel, which is the opposite of compression. Before reaching the red square the encoding was decoding to 255 zeros over and over, until finally 133 zeros. 255 zeros is 85 black pixels stored in just 2 bytes!
This type of encoding is only good for grey scale images. It is not good with color, but it still will handle color of course. In grey scale, the Red, Blue, and Green data components are always the same values. All the way from black (0,0,0) to white (255, 255, 255); including every shade of grey in between>>>(1,1,1) (2,2,2) (3,3,3)....(243, 243, 243) (244, 244, 244)<<<
One other difference in this method of run length encoding is that the color byte is before the count, which is backwards from all of the other methods.
The attachment contains the C source code (which is also in the 2nd post) and the executable that was compiled using mingw32 on a 64 bit Windows 7 pc. The png library that I used is LodePng, the source is in the download.
To use logoinjector:
Decode your logo.bin:
Code:
logoInjector.exe -i logo.bin -d
All the PNG 's will be extracted from logo.bin. Edit the PNGs that you want to change...
Note:
Your original "logo.bin" file is never changed, it is just read. If the file you try to load isn't a logo.bin file, or if it is the older style, then the program will tell you and exit
Your original "logo.bin" file is never changed, it is just read. If the file you try to load isn't a logo.bin file, or if it is the older style, then the program will tell you and exit
Inject the image(s) back in to the logo.bin:
Code:
logoinjector.exe -i logo.bin -j image_name_1 image_name_3
Code:
logoinjector.exe -i logo.bin -l
Code:
logoinjector.exe -i logo.bin -L
Code:
logoinjector.exe -i logo.bin -d -s
Code:
logoinjector.exe -i logo.bin -j image_name -s
Note:
With version 1.2, you can put as many names after "-j" as you want, and it's not case sensitive. You also don't have to put the whole name. If you just put "-j fhd" every image in the logo.bin that starts with "fhd" will be injected. There has to be a PNG with the name in the directory though
With version 1.2, you can put as many names after "-j" as you want, and it's not case sensitive. You also don't have to put the whole name. If you just put "-j fhd" every image in the logo.bin that starts with "fhd" will be injected. There has to be a PNG with the name in the directory though
The size of your modified.logo.bin will displayed along with the original size, if everything went good. Please know the size of you logo partition. I made this program to encompass any device using this format, and there is no set size of the logo partition between devices. Fastboot will just error out if you try to flash data bigger than the partition before it writes anything. But if someone gets brave and trys to "DD" to the logo partition, it could get ugly.:cyclops:
Flash the "modified.logo.bin" file through fastboot.
v1.2
- made it possible for multiple injections in one command
- doesn't add png to the decoded png if it was already in the name
- fixed out of scope with image 26 in OPPO find 7 logo.bin
- added LodePng source in the download
- made the default color order BGR
- displays the modified logo file size as well as the original file size
- runs the modified.logo.bin back through the list function after injecting
- checks the number of offsets between the original and modified logo.bin
Use this at your own risk.
Always make backups.
Always.
Last edited: