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

maybe webApp can output gif to share? #110

Open
bbyyxx2 opened this issue Oct 4, 2024 · 4 comments
Open

maybe webApp can output gif to share? #110

bbyyxx2 opened this issue Oct 4, 2024 · 4 comments

Comments

@bbyyxx2
Copy link

bbyyxx2 commented Oct 4, 2024

When I first found out about this project I was excited, but I realized that it is not a traditional static QR code and I didn't find a sharing solution. Do I think it is possible to share via gifs?

@sz3
Copy link
Owner

sz3 commented Oct 7, 2024

The issue is file size. Compression (zstd) is built into the format, but compression can only help so much. The reason cimbar works (imo) has a lot to do with the ephemeral nature of the frames -- we create one, show it on screen, and throw it away and move onto the next -- which allows it to sidestep the issue of the size of the encoded image.

That said, the cimbar cli can output pngs, and those image files can be combined into a gif. But the gif might be larger than the initial file!

@diabolusss
Copy link

While I completely understand that the resulting GIF might be larger, I believe this solution can still be very useful. Perhaps storing images as separate PNGs could be a better approach than using a single GIF.
Imagine a sheet of paper as an alternative to CDs or DVDs.
However, it raises an interesting question: what portion of the PNGs can be lost while still allowing the file to be successfully restored?

@sz3 Thank you for your great work on this tool!

@sz3
Copy link
Owner

sz3 commented Jan 26, 2025

However, it raises an interesting question: what portion of the PNGs can be lost while still allowing the file to be successfully restored?

This will depend on how many redundant frames we generate -- for over-the-air data transfer we use a multiple of the data size(e.g. "4x") to limit the chance of encountering duplicate frames: if we're already decoded a frame, seeing it again doesn't help us. For offline usage, whether shared as a gif or on paper, too many extra frames seems like a bad idea (too much redundancy is waste), so I've tended to assume 10-20% redundancy is ok. That is, the number of frames is the bare minimum + 20% extra, so we could afford to skip/lose 20% of the encoded frames (any of them) and still decode.

@Anonymous3-a
Copy link

Another use case for GIFs is for tunnling data. For example (I know this has been done better, this is an example), uploading a cimbar GIF to a video site.

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

4 participants