Reduce map svg size

[edenhaus]

The following optimizations are done in this PR:

• Remove unnecessary spaces by monkey patching svg.PathData and extending Path class
• Switching from an RGBA to P(Pallette) image (old png map image would be 7kB instead of 14kB)
• Round values to 3 digits
• Use shorthand notation for colors
• Remove scale transformation (except from trace path) by calculating the values directly
• If x or y of a point is zero, use h/v to avoid an unnecessary zero
• Use Image.frombytes instead of looping over each pixel
• The space before a negative number can be omitted
• The command letter can be omitted if it is the same as the previous one

[codecov]

Codecov Report

Attention: 44 lines in your changes are missing coverage. Please review.

Comparison is base (4dc5f10) 79.66% compared to head (60ddf03) 80.77%.

Files	Patch %	Lines
deebot_client/map.py	67.40%	42 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #375      +/-   ##
==========================================
+ Coverage   79.66%   80.77%   +1.11%     
==========================================
  Files          64       64              
  Lines        2582     2648      +66     
  Branches      468      487      +19     
==========================================
+ Hits         2057     2139      +82     
+ Misses        481      464      -17     
- Partials       44       45       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[edenhaus]

The map svg was reduced from 33kB to 19kB with the same level of details.

@lukakama, can you test my changes and give me feedback on them?

[edenhaus]

Reduced it even further to 17kB

[lukakama]

The map svg was reduced from 33kB to 19kB with the same level of details.

@lukakama, can you test my changes and give me feedback on them?

Nice! I will try to check it tomorrow :) .

[lukakama]

Also, please consider to use SVGZ (a standardized gzipped SVG) to achieve minimum size. It could be also handled in the Image Entity of the HA integration, if you want to keep the library generated SVG in clear text.
It should be correctly handled by all browser supporting SVG, the only quirk seems to be the content type to use (see w3c/svgwg#701 ), but by far, it seems that most browser are able to handle SVGZ when using the standard SVG mime type "image/svg+xml".

[edenhaus]

Also, please consider to use SVGZ (a standardized gzipped SVG) to achieve minimum size. It could be also handled in the Image Entity of the HA integration, if you want to keep the library generated SVG in clear text.
It should be correctly handled by all browser supporting SVG, the only quirk seems to be the content type to use (see w3c/svgwg#701 ), but by far, it seems that most browser are able to handle SVGZ when using the standard SVG mime type "image/svg+xml".

I will ask after Christmas if the frontend applies automatically gzip for now I would leave it in cleartext

[lukakama]

There is a comparison between maps generated from my repo code and this branch code (I just added a gray background to see path lines):

Old map (from my repo):

New map (from this branch):

The image size reduced from 25KB to 14KB, and room BGs seems to be drawn correctly except for the top-left one.
The other issue is that some (not all) disconnected trace points are kept connected with previous one, but can't tell where is the problem (I didn't inspect the code).

This is the Ecovacs App map as reference (I think that "house boundaries" are calculated by the app using "walls" pixels from map BG, but I would say to ignore them, at least for now):

[lukakama]

The other issue is that some (not all) disconnected trace points are kept connected with previous one, but can't tell where is the problem (I didn't inspect the code).

I just made a quick test removing the "_as_str" method overridden int the custom Path class, and trace paths are rendered correctly (disconnected point are kept disconnected), so the issue should be in that code. Maybe the comparison between current and previous path command which filter out instruction that should not be filtered. Maybe it is enough to spot the issue. If not, I will be able to perform further analysis after Christmas. And... Merry Christmas :D !

[edenhaus]

The other issue is that some (not all) disconnected trace points are kept connected with previous one, but can't tell where is the problem (I didn't inspect the code).

I just made a quick test removing the "_as_str" method overridden int the custom Path class, and trace paths are rendered correctly (disconnected point are kept disconnected), so the issue should be in that code. Maybe the comparison between current and previous path command which filter out instruction that should not be filtered. Maybe it is enough to spot the issue. If not, I will be able to perform further analysis after Christmas. And... Merry Christmas :D !

Thanks and also Merry Christmas :)

Thanks for the feedback:)
No stress but I probably need the SVG of both, you can send me them also via discord (search for edenhaus)

[edenhaus]

room BGs seems to be drawn correctly except for the top-left one.

As specified in #372 the map bg data has a different value per room. Therefore I create the image palette now dynamically and fallback to floor. We can improve it later with #372

[lukakama]

With latest commits the map is generated perfectly:

Furthermore, the background image PNG contains just the used colors, as it should:

$ echo "[base64 value from svg]" | base64 -d | pngcheck -p -
File: stdin (64 bytes)
  PLTE chunk: 10 palette entries
     0:  (  0,  0,  0) = (0x00,0x00,0x00)
     1:  (186,218,255) = (0xba,0xda,0xff)
     2:  ( 78,150,226) = (0x4e,0x96,0xe2)
     3:  (222,233,251) = (0xde,0xe9,0xfb)
     4:  (237,243,251) = (0xed,0xf3,0xfb)
     5:  (186,218,255) = (0xba,0xda,0xff)
     6:  (186,218,255) = (0xba,0xda,0xff)
     7:  (186,218,255) = (0xba,0xda,0xff)
     8:  (186,218,255) = (0xba,0xda,0xff)
     9:  (186,218,255) = (0xba,0xda,0xff)
  tRNS chunk: 1 transparency entry
    0:    0 = 0x00
OK: stdin (147x165, 4-bit palette+trns, non-interlaced, 99.5%).

Thanks for all the improvements! :D