epdiy
epdiy copied to clipboard
vroland
Vendor waveforms issues
Hi @vroland I am able to generate json from 5bpp waveform files using your inkwave fork, but those don't seem to work correctly (colors are distorted). I acquired some 4bpp wbf as well but those don't save correctly (broken json) - seems like you only assume 5bpp wbf? Would be nice to support 4bpp as well since for example ED060XC3 does have 4b waveform available.
So my question is, how to correctly convert the files so that it works in epdiy. I really love how crisp and high quality the image is but the colors are distorted. I tried to convert waveform for ED060XD4 and ED097TC2 and they seem to do correct routine but the colors are wrong (grayscale test appears like the shades are mixed up).
Since we have discussed this on slack / matrix, I'll close this here, but we can re-open or raise a new issue if ther's something new.
I respectfully disagree :) In my opinion this is a bug of the waveform generator and should be tracked in github issues. What happends on slack can easily be forgotten and I see this as an important issue since some displays don't work properly without vendor waveforms.
Hmmmm. Cppcheck complains a lot of stil warnings... with gems like "unint32_t" checked for less than zero...
See https://github.com/vroland/inkwave/blob/32e58f4d02367ee639764cf61e1a9e1f15b94c76/main.c#L651
(I have no idea what this program is about. Totally not. But help is wanted and here I am. Useless. :-)
The original inkwave was already kind of hacky and my changes didn't make it better ;) The program is about decoding eInk waveform tables. However these are really hard to find. Hence, it would be nice to find a more general solution eventually, like a mathematical model to derivce the waveform timings from...
@vroland IMO the problem with the vendor waveforms is not so much that they are hard to find - they are, but as you know you can still find quite a few online or fetch them from commercial devices. The more serious problem is that no one in the (unfortunately quite small) eink hacking scene seems to know the meaning of some parts of the vendor files. And some of that seem to be crucial. I looked into this briefly a few months ago, and noticed that there are transitions from one shade of gray to another with equal number of "drive to white" and "drive to black) commands interleaved. I can't see how this makes sense unless there is additional, say, timing info associated with these commands. There are many chunks of data in those waveforms whose meaning is not yet deciphered as far as I know, and I'd guess some of that is timing info.
At least that was my conclusion, based on a brief look- could be wrong... I agree with you broader point that working on free/open waveforms would seem like the more fruitful direction.
True, in some datasheets you can find the timings for line in a table, e.g. in some waveshare datasheets. But this information must also be somewhere in the waveform files, but I haven't found it yet.