Built-in WBF parser in EPDIY firmware?
Closed this issue · 3 comments
Hi all,
I'm just curious has anyone ever implemented or consider to implement a WBF parser in the EPDIY firmware?
So far AFAIK each batch of e-paper displays may (or may not) use their own WBF waveform specifically optimised for that batch of display panel, at least that's what I've been dealing with those commercial e-paper projects. The panel supplier may send us a different WBF file to us every time we purchase a batch of panels and we program them into the TCON chip.
My understanding from the suppliers and our own experiments are, using the generic waveform vs. the tailored WBF waveform makes no significant differences visually, at least I couldn't tell much differences with our human eyes. However the suppliers still recommend us to use whatever their tailored WBF waveform they supplied for each batch anyhow. 😅
Therefore I'm just thinking, if possible and if nobody else working on this, I might consider implementing a built-in WBF parser for EPDIY firmware, so that allowing this project to be used in some more professional/commercial scenarios properly.
Jackson
P.S. I know there are some existing projects like this: https://github.com/aceisace/python-waveform-parser/blob/main/wbf-parser.py
But either these are for a brief parsing or for external research purposes only. They are not for something like: we build a EPDIY TCON board, program the WBF waveform binary to the flash (or even download from our internal server over network), it parses the WBF and display content using that supplied waveform directly.
Anyway if nobody else consider working on this, I will have a try later. But no ETA so far as I've got a lot more things to do... 😅
Hello Jackson,
if you check #226 there is Ace that had the idea to parse WFB to the format that epdiy requires.
This repository has only open source waveform that work very good for certain sizes like 6" and 9.7" (others too) but they where mostly adjusted by hand after many tries and hard work.
I'm also looking forward to solve this thema. But maybe we canalize it in Issue 226?
Because it does make much sense that we open many issues about the same thematic.
What would help is that we take the time to focus in the code, how is done now, and how we would like to shape it. And document every part of the process.
Maybe you can send me an email (in my github profile) and we can plan something together in this topic?
I've it pending since long and I would like to have some partner to follow the research and analyze it.
I'm also looking forward to solve this thema. But maybe we canalize it in Issue 226?
Sure, I will close this for now and discuss in the Issue #226 .