Hey folks, thanks to @iElvis sharing his or her logo 'data' from the OP6. I have adapted my previous OnePlus programs that let you change the splash screen to work with the OP6. This means that the encoding of the data structure and the encoding of the image data are done. I do not have a OP6 and can not test certain things like where to put the modified file. In the past, flashing was always easy (and always has been especially with the OnePlus models).
My holdup and why I need the XDA/OP6 community support is to find out where to exactly put this modified file. In the past I haphazardly made a super fast in-memory program for altering the splash screen for the Nexus 6p that was (and is currently) at a roadblock for one reason. That reason was Google used ELFs to populate partitions (not short people with pointy ears and green clothing), and at that time utilized separate partitions that the ELFs populate. Not all were ELF generated, but that is outside of the scope of what I do because to a certain point the ones that I wanted to change were generated that way.
This concept of splitting partitions, back then, was just trying to grab a footing on seamless upgrades initially from what I have read up until this newer style. I have put some research into some things involving this, but Google is kind of bland in it's description of what this all means. This is different than the Nexus 6P that I mentioned previously, and if you read that last link, it may be just as easy as flashing it to both partitions logo_a & logo_b. One partition is always active and has two different statuses, which make the device 'ideally' always bootable after an OS update.
Most of my research was done through reading a lot of the open source code put out by the AOSP for "fastboot". You can learn more than you can ever derive from documentation in this realm. I hope to hear some feedback of attempts so that I can delete all of this up above
Please read below so you can better understand this type of encoding being used:
The attachment contains the executable that was compiled using mingw32 on a 64 bit Windows 10 PC. The awesome PNG library that I used for generating the pngs is LodePng, the source can be found here.
To use the OnePlus 6 Logo Injector:
Decode your logo.bin:
All the PNG 's will be extracted from logo.bin. Edit the PNG(s) 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. The 'splash' partition is 16 MB on the OP6. If you use too much color on too many of the images you will easily go over 16 MB. The program will tell you and delete the "modified.logo.bin" that was created. If for some strange reason you would like to keep it, use the "-B" flag on the command.
The last step is to flash the modified logo file via fastboot with the command
Use this at your own risk.
Always make backups.
Always.
My holdup and why I need the XDA/OP6 community support is to find out where to exactly put this modified file. In the past I haphazardly made a super fast in-memory program for altering the splash screen for the Nexus 6p that was (and is currently) at a roadblock for one reason. That reason was Google used ELFs to populate partitions (not short people with pointy ears and green clothing), and at that time utilized separate partitions that the ELFs populate. Not all were ELF generated, but that is outside of the scope of what I do because to a certain point the ones that I wanted to change were generated that way.
This concept of splitting partitions, back then, was just trying to grab a footing on seamless upgrades initially from what I have read up until this newer style. I have put some research into some things involving this, but Google is kind of bland in it's description of what this all means. This is different than the Nexus 6P that I mentioned previously, and if you read that last link, it may be just as easy as flashing it to both partitions logo_a & logo_b. One partition is always active and has two different statuses, which make the device 'ideally' always bootable after an OS update.
Most of my research was done through reading a lot of the open source code put out by the AOSP for "fastboot". You can learn more than you can ever derive from documentation in this realm. I hope to hear some feedback of attempts so that I can delete all of this up above
Please read below so you can better understand this type of encoding being used:
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 found 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 horizontal line 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 line /// 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 line 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) (254, 254, 254)<<<
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 found 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 horizontal line 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 line /// 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 line 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) (254, 254, 254)<<<
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 executable that was compiled using mingw32 on a 64 bit Windows 10 PC. The awesome PNG library that I used for generating the pngs is LodePng, the source can be found here.
To use the OnePlus 6 Logo Injector:
Decode your logo.bin:
Code:
OP6Logo -i logo.bin -dAll the PNG 's will be extracted from logo.bin. Edit the PNG(s) 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 file, or a different 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 file, or a different style, then the program will tell you and exit.
Inject the image(s) back in to the logo.bin:
Code:
OP6Logo -i logo.bin -j fhd_oppo fhd_at
Code:
OP6Logo -i logo.bin -l
Code:
OP6Logo -i logo.bin -L
Code:
OP6tLogo -i logo.bin -d -s
Code:
OP6Logo -i logo.bin -j image_name -sNote:
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
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. The 'splash' partition is 16 MB on the OP6. If you use too much color on too many of the images you will easily go over 16 MB. The program will tell you and delete the "modified.logo.bin" that was created. If for some strange reason you would like to keep it, use the "-B" flag on the command.
The last step is to flash the modified logo file via fastboot with the command
Code:
fastboot flash LOGO modified.logo.binUse this at your own risk.
Always make backups.
Always.
Last edited:
