Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

res2img testing - new res size #13

Closed
edpf opened this issue Sep 7, 2017 · 12 comments
Closed

res2img testing - new res size #13

edpf opened this issue Sep 7, 2017 · 12 comments

Comments

@edpf
Copy link

edpf commented Sep 7, 2017

Hi everybody. first of all congrats for your work and thanks

I am testing res2img.py and i found one issue. My testing:

1 - Run res2img.py -u
2 - change all raw files so they are generated again
3 - Run res2img.py -p

Original res file size was 228656 bytes and new res file size is 373207. That is without changing any of the images: all the images are the original ones extracted in step 1.

Further analysis shows that every new raw has exactly double size of the original one (header excluded) and I think that is related with depth of the images extracted which seem to double the original depth read from the original res file

I suppose there should be a limit in memory space in the amazfit, so this colud be a issue

Could you check it?

@dpeddi
Copy link
Contributor

dpeddi commented Sep 12, 2017

Give a try now using -f png

@edpf
Copy link
Author

edpf commented Sep 13, 2017

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

imagen

@dpeddi
Copy link
Contributor

dpeddi commented Sep 13, 2017

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

@edpf
Copy link
Author

edpf commented Sep 13, 2017

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:

imagen

@heartlandzf
Copy link
Contributor

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

@edpf
Copy link
Author

edpf commented Sep 13, 2017

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

imagen

@heartlandzf
Copy link
Contributor

Should be Fixed now ..

@JDesing
Copy link

JDesing commented Sep 13, 2017

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

fix_bmp

@edpf
Copy link
Author

edpf commented Sep 13, 2017

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!!!!

@heartlandzf
Copy link
Contributor

@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!

@JDesing
Copy link

JDesing commented Sep 15, 2017

@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.

@kingdj
Copy link

kingdj commented Dec 7, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants