Printing images is excruciatingly slow

[borfast]

I'm trying to use escposprinter in a RaspberryPi 3 with the very latest Raspbian (released just a few days ago) and an Epson TM-T20 II printer.

Printing text works just fine and is quite fast but printing an image is excruciatingly slow.

This is for a ticketing system, so what I'm doing is using PIL to load a white image (previously created with the right dimensions for the purpose: 400x210), drawing the text over the image and saving it to a temporary file. Then I call Escpos.image() and pass it the path to the temporary image. I'm attaching an example here.

It works and the image gets printed but very, very slowly.

When the printer finishes, it seems like the image was divided in rows and each row was printed individually. You can even hear the printer printing each individual row and see the thin blank lines between each filled/drawn row.

Any clue as to why this may be happening and how to fix it?

Here's the code I'm using:

def printQueue(queue_number, queue_line):
    # Base white image where text is to be printed
    img = Image.open(original_img)
    draw = ImageDraw.Draw(img)
    font = ImageFont.truetype("/usr/share/fonts/truetype/roboto/RobotoCondensed-Bold.ttf", 110)
    queue_text = queue_line + ' ' + queue_number
    draw.text((190, 0), queue_text, (0, 0, 0), font=font)
    img.save(temp_img)

    with EscposIO(printer.Usb(0x04b8, 0x0e15)) as p:
        p.printer.image(temp_img)

[rtu-dataframe]

Hi, i'm having the same issue, currently, i'm printing images logos on receipt, but i have the same problem of you, the procedure of converting image is slow and i have to optimize it (or try to do it...)

Another solution is to download the image to NVRAM and print the image by sending a specific HEX string to printer, but if it's a static image (like logos) everything works fine (because the image is already in the NV RAM) but, if you're placing some text dynamically on this image this approach doesn't work anymore.

In any case, i'll look on the image conversion procedure, in order to optimize it.

Kindly.
Simone.

[borfast]

@Simonefardella, I probably did not explain myself clearly but the problem is not during the image conversion process. That is also slow, yes, but it's nothing compared to the time the printer itself takes to print. I'm talking about after the printer starts printing.

As for the NVRAM approach you mentioned, I don't understand what you mean. Are you talking about the printer's NVRAM? The way I see it, an image with some text added to it is still just an image. And in my specific case, since your library can only read files from disk (at least as far as I could tell), I'm even saving the dynamically created image to another file and printing from there. For all intents and purposes, this is a plain black and white image. Could it not be sent to NVRAM like you are describing?

[rtu-dataframe]

• The image printing is something really simple: the image it's converted and, from the specification of the escpos protocol will be divided in pixel columns in order to print the content, as you can see from the protocol description over there:
  

After this brief introduction, i've tried to print the image that you posted in the previous post and everything works fine: (the image elaboration procedure took something like <1 second) and the printer printed everything like a charm, printing the image without any slowdown (i have a 300 mm/s printer).

So, due to that, maybe there is something related to your printer, that if i'm not wrong has a print speed of 150mm/s, so, the half speed compared to mine (PRINTER)

In any case, try to post a video and monit via htop your resources usage during the image printing process.

• About the NVRAM, every (recent) esc/pos printer has a NVRAM, in order to store an image and call via a specific command the direct printing (i haven't implemented yet this feature)...but...not all printers supports this approach, and in addition, in your case, you have to check if for your printer there is an application to elaborate the image and put it on the nvram, but it isn't the goal of us. in fact, with this approach you will be able only to print static images like logo and not print over them like you've described.

[borfast]

This is weird: when printing from my desktop computer, I notice that lag I was talking about but when printing from the Raspberry Pi, it works fine. I do notice the lag between clicking the button to print and the printer actually starting to print, but at least the ticket is printed normally.

Here are a few videos you can watch to see what I mean: https://goo.gl/photos/ocsMe99kn4UHAYRb6

From left to right, top to bottom, the first one shows printing directly from the browser interface on the Raspberry Pi with a touchscreen, the second one shows printing a big image from my PC, the third one shows printing from the Raspberry Pi but accessing the browser interface from my PC (shouldn't make any difference at all but...) and the fourth one shows printing from my PC again but this time with a small image (same size as the image being printed on the Raspberry Pi).

When printing from the PC you can hear the "rows" that I was talking about and you can see the gaps between them. When printing from the Raspberry Pi, it takes a bit longer to start printing but it prints perfectly well, without any rows/gaps and no stopping between them like what happens on the PC.

I made two videos from the PC to show the difference between printing with a big or a small image. The big one takes considerably longer than the small one.

I have absolutely no idea why this happens. All the code is exactly the same on the PC and the Raspberry Pi, all using your library.

[rtu-dataframe]

That's really strange, when you try to print from your pc, you're using the usb or are you sending the print via ethernet?

[borfast]

Always via USB, on both the Pi and the PC.

[rtu-dataframe]

Really i have no idea, this is really strange, send me the images: the small and big one, i'll try to print them from my pc.

[borfast]

Here's the small image:

And here's the big image:

Remember they are just blank images to serve as the background for printing. I'm using the code I posted on the first comment to add the numbers, save the image to a temporary file, and then print from there.

[rtu-dataframe]

i see only empty images...

[borfast]

Exactly, like I said, they are blank/empty/white images to serve as the background for printing and I add the numbers with the code in my first comment.

The whole process is:

1. Open the blank image and put it in memory.
2. Using PIL, manipulate the image in memory and add the numbers.
3. Save the image with the numbers to a temporary file.
4. Use your library to print the temporary file.

[borfast]

If you want the temporary images ready for printing, here are a couple of them:

[rtu-dataframe]

Ok i'll try.

Thanks.

[patkan]

Hi, I just saw this issue. You could try python-escpos (It's python2 and 3 compatible) or have a look at how it is implemented there. We have implemented the native image printing methods which might work better.

[rtu-dataframe]

Thanks @patkan , i'll try to integrate your image processing to my library, that's ok?

In which differs? can you show me image-manager code?

Thanks!
Simone.

[patkan]

Well, the code is published under GPLv3. So as long as you stick to the rules that come with this license you can do what ever you want. As a notice: in this case the code does not come from me, but a collaborator.
Just have a look at the image-function in escpos.