Small tools inside a familiar interface
This early project brings several Python utilities into Telegram: extracting text from an image, transcribing an audio file, turning text into speech, rendering text onto an image, and simple conversation. The idea was to make each tool reachable through a message and a guided choice, without asking someone to run a separate script.
The interface begins with image, audio, and chat modes. Each mode presents the relevant next step, with back and cancel actions to move through the conversation. A state-based handler routes incoming messages to the operation the user selected.
From an uploaded file to a reply
The OCR path downloads an image and prepares it with OpenCV. Grayscale conversion, thresholding, inversion, and morphological operations create an input for Tesseract, which returns the extracted text to the conversation.
The audio path downloads an uploaded file, converts it to WAV when needed, and passes it through the SpeechRecognition library's Google recognition integration. The reverse operation uses gTTS to create an audio file from text and sends that file back through Telegram.
Text-to-image is a smaller utility built with Pillow. It draws the supplied text onto a canvas using a bundled font. The conversation feature uses ChatterBot with SQLite storage. Together, these tools demonstrate several integration patterns behind a single messaging interface.
Organizing the application
The bot separates Telegram conversation handlers from the utility classes that perform each conversion. The handlers manage prompts, file downloads, responses, and the next conversation state; the utility module contains the OCR, audio, image, and chat operations.
Temporary working directories hold files during a request, with cleanup after processing. Error paths return a prompt to retry the relevant upload or text input. This makes the flow understandable even when an external service or file conversion fails.
Outcome and lessons
The project produced a working implementation of the message-to-file-to-result pattern across several media types. It was an early exploration of integrating existing tools, with the interface and processing steps kept close enough to inspect and understand.
It also exposed the boundaries of a small bot architecture: temporary file handling, third-party service behavior, and conversation state deserve the same care as the underlying recognition tool. Those concerns connect directly to other work on student assistants and document processing.
The source code preserves this historical prototype and its utility implementations.