res2img testing - new res size about tools HOT 12 CLOSED

Should be Fixed now ..

from tools.

Give a try now using -f png

from tools.

Trying with - f png
Sorry, but PNGs I got are not fully decoded:

from tools.

just tested with gimp and it works correctly. What editor are you using?

from tools.

I am at work and I only have access to my linux console at home, so I am generating PNGs under linux, but viewing images in Windows. I get same results with embedded viewer, with photo app and with Paint (all of them from Microsoft). With ImageMagick Display under Windows I get the following error:

from tools.

The embedded decoder and others don't accept the crc..

I made some test on few pixel and it was working, but there is something to fix.

But, please, confirm if images in gimp are fully decoded

from tools.

Testing images with gimp under windows --> gimp open images but I wonder if there is a problen in the last line of each image. Look at the images compared with BMPs generated with a prevoius version of res2img.py (left images are new pngs and on the right side bmps). Last line of pixels in pngs seems to be incorrect

from tools.

Hi, I try to extract the BMP files with the new res2img.py but not decode them correctly

from tools.

Wow! Great job! Now almost everything seems to work right ;-) Just a few comments:

• All pngs are fully decoded and seem to be OK (I didnt try bmps, sorry).
• When encoding them again I get the new res file with same size as original which is what I think it should be (Wonderful!!!!)
• Finding differences between original res files and new res file I get 2 diffs (5 bytes):

1. Version number (6th byte in res file) is not the same, I think you are reading 7th byte, so line 600 should be:
   version = ord(fileContent[5:6])
   instead of
   version = ord(fileContent[6:7])
2. Bytes 0x11 and 0x12 in images 204 and 205 are equal to 0x00 in the raw files generated when unpacking the original res file and those bytes are equal to 0xFF in raw files generated when packing. I suppose those bytes are one of the colours of the palette but I have no idea of what happened.

Anyway, the main reason of this issue was that size of packed images was twice the size of unpacked images and that problem is solved. Sorry for being so hard testing your script, but uploading firmware files whose size is bigger than expected is a typical way of bricking devices. So I think you did a great improvement!!!!

from tools.

@JDesing :
Png conversion are done directly while other formats use 'imagemagick'.
Imagemagick is probably the most powerful tool I know, but the use of multiple functions produce some unexpected problems.
I don't know if we can fix other formats, but with png we have more control over the output.

@edpf:

1. later or tomorrow I check.. I'll upload the new version with compressed png support
2. If transparent bit is set, the first entry in colormap is .. transparent .. I choose to represent transparent color with rgb( 254, 254, 0) as first element in the png colormap. Converting to raw, if first value is (254,254,0) , transparent bit is set and the rgb value is not a problem.
   Please note that it looks like display has 8 colors and official resources only use 0 or 255 for color components.

I hope that all works well!

from tools.

@heartlandzf

Ok, thanks for the reply. The problem is that if I modify some PNG is not seen correctly in the Amazfit Bip, the modified PNG is seen only grabs. However, if I use the BMP and although they are not well decoded in the PC, then in the Amazfit Bip is seen correctly. I have tried several ways to save in PNG but none works for me. I will continue to use BMP.

Thanks and best regards.

from tools.

Hey any one knows how to design custom watchface for amazfit bip u.

from tools.