Some jpg files cannot be send in quick way on version 5.xx (works ok on 4.16.8)

[eugene-rom]

Steps to reproduce

To reproduce, try to send this image in quick way. (Drag and drop from folder, or click attachment icon from telegram.) Bug introduced on version 5 (4.16.8 works ok). Bug present in static binary (5.0.2) and in snap package (currently, 5.0.1-40-g4fddaef11 in edge channel).

Expected behaviour

Telegram will compress image and send it in quick way (inline image).

Actual behaviour

This image file cannot be send in quick view. It sends as attached file.

Operating system

Ubuntu 24.04, 20.04 (GNOME DE, Xorg)

Version of Telegram Desktop

5.0.2

Installation source

Static binary from official website

Crash ID

No response

Logs

No response

[ilya-fedin]

Forwarded to https://github.com/libjxl/libjxl/issues/3609

[taha-ghadirian]

Well, I think it works for me on version 5.0.3.

[eugene-rom]

Well, I think it works for me on version 5.0.3.

Just updated, doesn't work for me. In console:

qt.gui.imageio.jpeg: ./lib/jpegli/decode_marker.cc:551: Unexpected marker 0xd3

[taha-ghadirian]

Well, I think it works for me on version 5.0.3.

Not working anymore in 5.0.4.

[uniconstructor]

Confirm this issue on Telegram 5.1.4 (Ubuntu 22.04 LTS), with another image: https://ipfs.io/ipfs/QmSKk6PE3oEok2gMeVBTxEkmA9qToQhZ7RaLEVvT2tUBjh

Will forward details to libjhl too.

[ilya-fedin]

Confirm this issue on Telegram 5.1.4 (Ubuntu 22.04 LTS), with another image:

Are you sure it is? I can't confirm this image leads to any issue.

[uniconstructor]

@ilya-fedin sorry, I'm incorrectly attached my image. Github transformed it in some way. Here is IPFS link to original image: QmSKk6PE3oEok2gMeVBTxEkmA9qToQhZ7RaLEVvT2tUBjh

[ilya-fedin]

Here is IPFS link to original image: QmSKk6PE3oEok2gMeVBTxEkmA9qToQhZ7RaLEVvT2tUBjh

It still reads just fine

[uniconstructor]

@ilya-fedin very strange. Just tested again and crashed my Telegram one more time. Maybe zip: broken-image.zip ?

[ilya-fedin]

Stop. Are you sure you have this issue? This issue is that sending the image looks like this: And qt.gui.imageio.jpeg: ./lib/jpegli/decode_marker.cc:551: Unexpected marker 0xd3 message gets printed into terminal. If you don't have either of those then you don't have this issue. The issue description also doesn't say anything about crashes.

[ilya-fedin]

if you have mistaken then please remove the misleading comment from libjxl issue

[uniconstructor]

Maybe you are correct. There is something different here. WOW. Something REALLY new. I tried to restart telegram-desktop from console after crash. At this time my Telegram starts completely "fresh": all my settings, sessions, anything dropped. Like fresh install:

I restarted Telegram, logged in using QR and my phone, entered my cloud password, see my contacts and chats again.

Than tried to attach broken image to favorites. Have another crash. Restarted Telegram. Got fresh app state again.

[ilya-fedin]

I see you're using a third party build. That is likely the reason of the crash, not the image.

[uniconstructor]

@ilya-fedin no problem, let's try fresh build exactly from this repo: My actions was:

1. Go to https://desktop.telegram.org/
2. download Telegram for Linux x64 (url: https://telegram.org/dl/desktop/linux - not flatpack, not snap, 175 Mb binary)
3. unpack downloaded files, run Telegram from console
4. restore access using mobile phone + cloud password
5. try to attach image again (clicked "send" button)

Crash again.

➜  telegram ./Telegram 
QPainter::begin: Paint device returned engine == 0, type: 2
QWidget::render: Cannot render with an inactive painter
./lib/jpegli/encode.cc:293: Sampling is not supported for simgle component imag
terminate called after throwing an instance of 'std::exception'
  what():  std::exception
[1]    607889 IOT instruction (core dumped)  ./Telegram

[ilya-fedin]

@eugene-rom your problem doesn't seem related to this issue at all

[uniconstructor]

if you have mistaken then please remove the misleading comment from libjxl issue

@ilya-fedin I had problems with "./lib/jpegli/encode.cc" as you see above. Is it related to libjxl or not? Both problems looks like related to jpeg-encoding process but I don't know how exactly. Should I remove my cross-posted comment from libjxl issue or not?

[ilya-fedin]

It could be another issue with libjxl. But it's not this issue for sure. Thus off-topic for this issue and the issue on libjxl repo.

[ilya-fedin]

Should I remove my cross-posted comment from libjxl issue or not?

Yes, please.

[uniconstructor]

@ilya-fedin ok, I got it. But can you, please, guide me about my next actions about this? Issue processing standards are important. I'm understand it and want to create some useful activity. Not mess.

Is it problem should be described as newly issue in libjxl repo (not in Telegram repo)? Is it my correct next action?

[ilya-fedin]

@uniconstructor create your own issue on tdesktop repo and fill all the fields (especially crash id) in the template

[uniconstructor]

@ilya-fedin got it, thanks. I will create new a issue on tdesktop repo using relevant issue template.

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[eugene-rom]

This issue was inactive for a long time

But still not fixed.

[ilya-fedin]

@eugene-rom I'm doubt it will be fixed cause the upstream issue I linked in the first message is inactive, i.e. no one else comes across this issue which means such images are rare and don't deserve attention

[ilya-fedin]

Anyone who tracks this issue, please subscribe to the upstream issue linked in the first comment.