I found time in the weekend to test the ESP32 version in the branch feature/compression

https://github.com/martinberlin/eink-calendar/tree/feature/compression

The idea is to take advantage of ESP32 bigger memory to receive a Zlib compressed Bitmap, which reduces in about factor 4 the download time (4.5 seconds vs 0.9 seconds)

Proof-of-concept serial output with 800*480 px Waveshare eink

displayWidth: 800 height: 480 File size:48146 Compressed: 3995
Image Offset:146
Header size:124
Width:800 Height:480 Bit Depth:1
Planes:1 Format:0

Read=48032 bytes. Sending BMP pixels to display
Eink isRendered: 1 BENCHMARKS:
Download: 908 ms Decompress: 4 ms Total Rendering including download: 10 seconds

As for what deepleep goes, my father reported in his Wemos D1 ESP8266, about 0.8 mA in deepsleep mode.

In the ESP32's I have currently available, I still get higher values for deepsleep, here a thread I started on the bluebird: 

https://twitter.com/i_grr/status/1216235263149522944 -> Follow me for more updates on my projects here

Lolin 32 v1.0.0: 19 mA in deepsleep
Heltec            : 10 mA (turning off the oled)

DFRobot Firebeetle V2: <1mA (But costs up to 19€)

So I highly recommend if you want to achieve low consumption to start with a modern Lolin D32 and make a small research to get a board that is design with lower consumption in mind. Many out of there in the 5 to 7 € price range are consuming too much when on deepsleep.

Some of the options mentioned after researching this topic where the DFRobot Firebeetle ESP32 and also the TinyPICO a project by UnexpectedMaker. There may be many others and even ranger at lower prices, please make your research and comment about your favourite pics. 

18uA is what TinyPICO consumes on deep sleeping and that would be an ideal candidate for a Battery operated CALE, not only for the deepsleep consumption but also for it's mini-size which will fit in very small cases. 
Another alternative to consume less is to reduce the CPU Frequency to 80Mhz in platformio.ini

board_build.f_cpu = 80000000L
This will of course make the processing and decompression slower but only minimally at the adventage of using less battery.