Some improvement ideas #1

Open
opened 2023-08-05 01:44:40 +00:00 by eloy · 6 comments
Contributor

First, thanks for writing this bot!

Just writing down some ideas we had while using this bot:

  • Histogram normalization for color images, which improves the quality when printing in grayscale.
  • Adding a feature to 'livestream' the printed stickers on Mastodon/fediverse. Should be done with user opt-in and content warning enabled by default.
  • Per user rate limiting and/or banning
  • Daily rate limiting to make the sticker supply last the entire event
  • Generate the password on some type of geohashing for fun: https://en.wikipedia.org/wiki/Geohash
  • Recommend adding a comment where to find the printer when deploying. People are sharing the bot username to each other, without nessecaily telling where to collect the actual stickers on the event field. This should be found in the intro message of the bot.
  • Clear feedback when images are rejected based on aspect ratio. Maybe automatically crop the image or something. Or ask the user if they want to resent their preferred cropped version.
First, thanks for writing this bot! Just writing down some ideas we had while using this bot: - Histogram normalization for color images, which improves the quality when printing in grayscale. - Adding a feature to 'livestream' the printed stickers on Mastodon/fediverse. Should be done with user opt-in and content warning enabled by default. - Per user rate limiting and/or banning - Daily rate limiting to make the sticker supply last the entire event - Generate the password on some type of geohashing for fun: https://en.wikipedia.org/wiki/Geohash - Recommend adding a comment where to find the printer when deploying. People are sharing the bot username to each other, without nessecaily telling where to collect the actual stickers on the event field. This should be found in the intro message of the bot. - Clear feedback when images are rejected based on aspect ratio. Maybe automatically crop the image or something. Or ask the user if they want to resent their preferred cropped version.
Owner

First, thanks for writing this bot!

Just writing down some ideas we had while using this bot:

  • Histogram normalization for color images, which improves the quality when printing in grayscale.

You mean adapting the range of the blackiest/whitest pixel, to 0:255? Or am i missing something else?

  • Adding a feature to 'livestream' the printed stickers on Mastodon/fediverse. Should be done with user opt-in and content warning enabled by default.

That could be a nice idea, but i have no idea how the api for Mastodon works. I would need to research more about it.

  • Per user rate limiting and/or banning
  • Daily rate limiting to make the sticker supply last the entire event

I'm working on that already. Also perhaps rate limiting should be per-mm rather than per stickers (printing 10 5mm tall stickers is much better than 10 60mm tall stickers).

You can already set the password to an arbitrary string. Am i missing something there? How would that work?

  • Recommend adding a comment where to find the printer when deploying. People are sharing the bot username to each other, without nessecaily telling where to collect the actual stickers on the event field. This should be found in the intro message of the bot.

You can add it in the welcome message from config.py

  • Clear feedback when images are rejected based on aspect ratio. Maybe automatically crop the image or something. Or ask the user if they want to resent their preferred cropped version.

Rejected ratio is usually triggered by unusually long stickers. I believe it would be hard to find an acceptable cropping algorithm which would keep in focus the "important" part of the image. IMHO, the error is already clear enough and i've seen that in events people usually understand the gist of it quite clearly.

> First, thanks for writing this bot! > > Just writing down some ideas we had while using this bot: > - Histogram normalization for color images, which improves the quality when printing in grayscale. You mean adapting the range of the blackiest/whitest pixel, to 0:255? Or am i missing something else? > - Adding a feature to 'livestream' the printed stickers on Mastodon/fediverse. Should be done with user opt-in and content warning enabled by default. That could be a nice idea, but i have no idea how the api for Mastodon works. I would need to research more about it. > - Per user rate limiting and/or banning > - Daily rate limiting to make the sticker supply last the entire event I'm working on that already. Also perhaps rate limiting should be per-mm rather than per stickers (printing 10 5mm tall stickers is much better than 10 60mm tall stickers). > - Generate the password on some type of geohashing for fun: https://en.wikipedia.org/wiki/Geohash You can already set the password to an arbitrary string. Am i missing something there? How would that work? > - Recommend adding a comment where to find the printer when deploying. People are sharing the bot username to each other, without nessecaily telling where to collect the actual stickers on the event field. This should be found in the intro message of the bot. You can add it in the welcome message from config.py > - Clear feedback when images are rejected based on aspect ratio. Maybe automatically crop the image or something. Or ask the user if they want to resent their preferred cropped version. Rejected ratio is usually triggered by unusually long stickers. I believe it would be hard to find an acceptable cropping algorithm which would keep in focus the "important" part of the image. IMHO, the error is already clear enough and i've seen that in events people usually understand the gist of it quite clearly.
Author
Contributor

You mean adapting the range of the blackiest/whitest pixel, to 0:255? Or am i missing something else?

That's the essence of it yes, but I don't know the details of the algorithm. Now some stickers look quite bright in full color but weak in grayscale, I think this would improve that.

That could be a nice idea, but i have no idea how the api for Mastodon works. I would need to research more about it.

I wrote some code for it yesterday using the Mastodon.py library, it is quite trivial. You create an API key on Mastodon, instantiate an object with that key and hostname, upload the image and submit a post with that image attached.

I'm working on that already. Also perhaps rate limiting should be per-mm rather than per stickers (printing 10 5mm tall stickers is much better than 10 60mm tall stickers).

Cool, a friend of me wrote some banning code yesterday which is now running at our BornHack village.

You can already set the password to an arbitrary string. Am i missing something there? How would that work?

My point is to create some form of challenge into the pin code to the event visitor so they have to keep coming back for new stickers instead of printing a whole bunch of them remotely. But it requires a thoughtful balance so it stays fun and does not become an annoyance. But this is very much a nice-to-have feature, a code on the printer works fine :)

You can add it in the welcome message from config.py

Yes, but I mean that it should be suggested to the person who sets up a new deployment, so maybe in the README.md.

Rejected ratio is usually triggered by unusually long stickers. I believe it would be hard to find an acceptable cropping algorithm which would keep in focus the "important" part of the image. IMHO, the error is already clear enough and i've seen that in events people usually understand the gist of it quite clearly.

Ah, maybe it was a different issue then. I remember telling this to someone without looking at the actual error and they said my advice helped. If you say the error is clear enough, I guess it's fine.

>You mean adapting the range of the blackiest/whitest pixel, to 0:255? Or am i missing something else? That's the essence of it yes, but I don't know the details of the algorithm. Now some stickers look quite bright in full color but weak in grayscale, I think this would improve that. >That could be a nice idea, but i have no idea how the api for Mastodon works. I would need to research more about it. I wrote some code for it yesterday using the Mastodon.py library, it is quite trivial. You create an API key on Mastodon, instantiate an object with that key and hostname, upload the image and submit a post with that image attached. >I'm working on that already. Also perhaps rate limiting should be per-mm rather than per stickers (printing 10 5mm tall stickers is much better than 10 60mm tall stickers). Cool, a friend of me wrote some banning code yesterday which is now running at our BornHack village. >You can already set the password to an arbitrary string. Am i missing something there? How would that work? My point is to create some form of challenge into the pin code to the event visitor so they have to keep coming back for new stickers instead of printing a whole bunch of them remotely. But it requires a thoughtful balance so it stays fun and does not become an annoyance. But this is very much a nice-to-have feature, a code on the printer works fine :) >You can add it in the welcome message from config.py Yes, but I mean that it should be suggested to the person who sets up a new deployment, so maybe in the README.md. >Rejected ratio is usually triggered by unusually long stickers. I believe it would be hard to find an acceptable cropping algorithm which would keep in focus the "important" part of the image. IMHO, the error is already clear enough and i've seen that in events people usually understand the gist of it quite clearly. Ah, maybe it was a different issue then. I remember telling this to someone without looking at the actual error and they said my advice helped. If you say the error is clear enough, I guess it's fine.
Owner

You mean adapting the range of the blackiest/whitest pixel, to 0:255? Or am i missing something else?

That's the essence of it yes, but I don't know the details of the algorithm. Now some stickers look quite bright in full color but weak in grayscale, I think this would improve that.

I believe we can present a matrix to the user with various settings and let them decide the one that looks better, perhaps?

That could be a nice idea, but i have no idea how the api for Mastodon works. I would need to research more about it.

I wrote some code for it yesterday using the Mastodon.py library, it is quite trivial. You create an API key on Mastodon, instantiate an object with that key and hostname, upload the image and submit a post with that image attached.

I'm working on that already. Also perhaps rate limiting should be per-mm rather than per stickers (printing 10 5mm tall stickers is much better than 10 60mm tall stickers).

Cool, a friend of me wrote some banning code yesterday which is now running at our BornHack village.

Damn. I'll enable SSH soon so you can push that and we can keep improving the code!

You can already set the password to an arbitrary string. Am i missing something there? How would that work?

My point is to create some form of challenge into the pin code to the event visitor so they have to keep coming back for new stickers instead of printing a whole bunch of them remotely. But it requires a thoughtful balance so it stays fun and does not become an annoyance. But this is very much a nice-to-have feature, a code on the printer works fine :)

Using a PN532 and the nfcpy library it could be trivial to create a nfc "totem" from where to "redeem" prints. Telegram already implements a way to send data to bots using a link like "https//t.me/yourbot/payload_here". Perhaps using a ndef payload sending a link like that could work?

You can add it in the welcome message from config.py

Yes, but I mean that it should be suggested to the person who sets up a new deployment, so maybe in the README.md.

Good idea.

Rejected ratio is usually triggered by unusually long stickers. I believe it would be hard to find an acceptable cropping algorithm which would keep in focus the "important" part of the image. IMHO, the error is already clear enough and i've seen that in events people usually understand the gist of it quite clearly.

Ah, maybe it was a different issue then. I remember telling this to someone without looking at the actual error and they said my advice helped. If you say the error is clear enough, I guess it's fine.

Maybe check a bit more on that and let me know so that we can work more on that.

> >You mean adapting the range of the blackiest/whitest pixel, to 0:255? Or am i missing something else? > > That's the essence of it yes, but I don't know the details of the algorithm. Now some stickers look quite bright in full color but weak in grayscale, I think this would improve that. I believe we can present a matrix to the user with various settings and let them decide the one that looks better, perhaps? > > >That could be a nice idea, but i have no idea how the api for Mastodon works. I would need to research more about it. > > I wrote some code for it yesterday using the Mastodon.py library, it is quite trivial. You create an API key on Mastodon, instantiate an object with that key and hostname, upload the image and submit a post with that image attached. > > >I'm working on that already. Also perhaps rate limiting should be per-mm rather than per stickers (printing 10 5mm tall stickers is much better than 10 60mm tall stickers). > > Cool, a friend of me wrote some banning code yesterday which is now running at our BornHack village. Damn. I'll enable SSH soon so you can push that and we can keep improving the code! > > >You can already set the password to an arbitrary string. Am i missing something there? How would that work? > > My point is to create some form of challenge into the pin code to the event visitor so they have to keep coming back for new stickers instead of printing a whole bunch of them remotely. But it requires a thoughtful balance so it stays fun and does not become an annoyance. But this is very much a nice-to-have feature, a code on the printer works fine :) Using a PN532 and the nfcpy library it could be trivial to create a nfc "totem" from where to "redeem" prints. Telegram already implements a way to send data to bots using a link like "https//t.me/yourbot/payload_here". Perhaps using a ndef payload sending a link like that could work? > > >You can add it in the welcome message from config.py > > Yes, but I mean that it should be suggested to the person who sets up a new deployment, so maybe in the README.md. Good idea. > > >Rejected ratio is usually triggered by unusually long stickers. I believe it would be hard to find an acceptable cropping algorithm which would keep in focus the "important" part of the image. IMHO, the error is already clear enough and i've seen that in events people usually understand the gist of it quite clearly. > > Ah, maybe it was a different issue then. I remember telling this to someone without looking at the actual error and they said my advice helped. If you say the error is clear enough, I guess it's fine. Maybe check a bit more on that and let me know so that we can work more on that.
Author
Contributor

Maybe we should open more issue threads, but I'm reporting it here to remind myself as well.

There is a permission issue with /dev/usb/lp0 file on Fedora Server. It resets the file permissions on reboot and on disconnects of the printer, which means that everytime I have to start a shell script with chmod. This should probably be fixed by writing an udev config file for the printer. Not sure if this is needed for all distros and needs some more testing. I tried the group command in the README.md before already, did not worked on this server.

Also, the printer (QL-700 is my case) seems to go to sleep after a while. Maybe it is possible to send some sort of keepalive to it, I have to research that.

Maybe we should open more issue threads, but I'm reporting it here to remind myself as well. There is a permission issue with `/dev/usb/lp0` file on Fedora Server. It resets the file permissions on reboot and on disconnects of the printer, which means that everytime I have to start a shell script with `chmod`. This should probably be fixed by writing an udev config file for the printer. Not sure if this is needed for all distros and needs some more testing. I tried the group command in the README.md before already, did not worked on this server. Also, the printer (QL-700 is my case) seems to go to sleep after a while. Maybe it is possible to send some sort of keepalive to it, I have to research that.
Author
Contributor

https://hacksrus.xyz/notice/AYp3DXBOjWhgkhbZJI

Maybe we should create some deployment recommendations section in the readme, such as buying Brother DK-22606 tape for warning stickers.

Also, having that web server from samw integrated in this project would be really neat, so it's also accessible for non-Telegram users.

https://hacksrus.xyz/notice/AYp3DXBOjWhgkhbZJI Maybe we should create some deployment recommendations section in the readme, such as buying Brother DK-22606 tape for warning stickers. Also, having that web server from samw integrated in this project would be really neat, so it's also accessible for non-Telegram users.
Owner

https://hacksrus.xyz/notice/AYp3DXBOjWhgkhbZJI

Maybe we should create some deployment recommendations section in the readme, such as buying Brother DK-22606 tape for warning stickers.

Done.

Also, having that web server from samw integrated in this project would be really neat, so it's also accessible for non-Telegram users.

Doable, but uhh, i believe out of the scope right now.

> https://hacksrus.xyz/notice/AYp3DXBOjWhgkhbZJI > > Maybe we should create some deployment recommendations section in the readme, such as buying Brother DK-22606 tape for warning stickers. Done. > Also, having that web server from samw integrated in this project would be really neat, so it's also accessible for non-Telegram users. Doable, but uhh, i believe out of the scope right now.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: foxo/printer_bot#1
No description provided.