Bug 96178 - Improve handling of JPEG images that have no defined units, LO mishandles the import into calc
Summary: Improve handling of JPEG images that have no defined units, LO mishandles the...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: filter:jpeg
Depends on:
Blocks: Calc-Images Image-DPI
  Show dependency treegraph
Reported: 2015-12-01 12:50 UTC by Adam Szanto-Varnagy
Modified: 2019-03-01 03:50 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

The image I am unable to insert (56.54 KB, image/jpeg)
2015-12-01 12:50 UTC, Adam Szanto-Varnagy

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Szanto-Varnagy 2015-12-01 12:50:06 UTC
Created attachment 120924 [details]
The image I am unable to insert

I attached recently several images without any problems. Whenever I try to insert this one (see attachment) it freezes the system, almost impossible to shot it.

It does it even in a totally empty worksheet, even after changing the filename. There is something weird about this really small picture that makes it impossible to handle.
Comment 1 Adam Szanto-Varnagy 2015-12-01 13:12:07 UTC
I tried to insert it via LibreOffice Writer / Copy-paste and got the same results.
Comment 2 raal 2015-12-04 11:27:15 UTC
I can not confirm with version Please test with actual version, https://www.libreoffice.org/download/libreoffice-fresh/
Comment 3 Adam Szanto-Varnagy 2015-12-04 13:08:48 UTC
I can! For me, it produces the very same freeze. (I am using Lubuntu / Ubuntu 14.04.3 LTS.)
Comment 4 tommy27 2015-12-04 20:42:23 UTC
you are using an obsolete LibO version ( which is no longer supported

retest with an updated LibO release ( or and tell if issue persists.

Comment 5 Adam Szanto-Varnagy 2015-12-05 16:15:54 UTC
Yes, this is what I wrote, sorry for being ambigious. I downloaded the new version using the given link and the result is the same.
Comment 6 V Stuart Foote 2015-12-05 19:53:34 UTC
Problem is a malformed JPEG, when I insert the JPEG image into a Windows build
Build ID: f34b4844473d08c0c264ba4453a875e32f5c326b
Threads 8; Ver: Windows 6.19; Render: GL; 

it comes in at 452.91" x 338.91"--just a little oversize, adjust from the "Position and Size" dialog.

And if inserted into Draw it resizes to fit in drawing page margins. But the "Restore Original Size" bumps it out to 16.62" x 13.91", and when using the position and size to bring it back down to size--have to adjust position offset back to o.oo"

So here is an Imagemagick identify -verbose run against it. Note that Units are "undefined".  Fix the source of the JPEG, looks like image had been annotated, so suspect the save format there.

Image: tdf96178_teszt.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Mime type: image/jpeg
  Class: DirectClass
  Geometry: 453x339+0+0
  Units: Undefined
  Type: TrueColor
  Endianess: Undefined
  Colorspace: sRGB
  Depth: 8-bit
  Channel depth:
    red: 8-bit
    green: 8-bit
    blue: 8-bit
  Channel statistics:
    Pixels: 153567
      min: 0 (0)
      max: 255 (1)
      mean: 123.388 (0.483874)
      standard deviation: 54.902 (0.215302)
      kurtosis: 0.0554868
      skewness: -0.108679
      entropy: 0.935102
      min: 0 (0)
      max: 255 (1)
      mean: 112.238 (0.44015)
      standard deviation: 50.1036 (0.196485)
      kurtosis: -0.458876
      skewness: -0.513472
      entropy: 0.928207
      min: 0 (0)
      max: 255 (1)
      mean: 103.948 (0.407639)
      standard deviation: 49.614 (0.194565)
      kurtosis: -0.490233
      skewness: -0.387346
      entropy: 0.931538
  Image statistics:
      min: 0 (0)
      max: 255 (1)
      mean: 113.191 (0.443888)
      standard deviation: 51.5951 (0.202334)
      kurtosis: -0.0169653
      skewness: -0.273849
      entropy: 0.931616
  Rendering intent: Perceptual
  Gamma: 0.454545
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Background color: white
  Border color: srgb(223,223,223)
  Matte color: grey74
  Transparent color: black
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 453x339+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: JPEG
  Quality: 95
  Orientation: Undefined
    comment: CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 95

    date:create: 2015-12-05T13:26:24-06:00
    date:modify: 2015-12-05T13:26:24-06:00
    jpeg:colorspace: 2
    jpeg:sampling-factor: 2x2,1x1,1x1
    signature: efe3b28adb67740f12e5d26fe74b2c59220b4ac76ab3e6afa0bea8eff060b256
    filename: tdf96178_teszt.jpg
    verbose: true
  Tainted: False
  Filesize: 57.9KB
  Number pixels: 154K
  Pixels per second: 9.223372EB
  User time: 0.000u
  Elapsed time: 0:01.000
  Version: ImageMagick 6.9.2-0 Q16 x64 2015-08-15 http://www.imagemagick.org
Comment 7 Adam Szanto-Varnagy 2015-12-06 09:45:12 UTC
I don't understand.

When I open this image in any other program except LibreOffice Calc, it opens without any problem. Any image viewer, or any other LibreOffice application.

However, when I open it in Calc, it freezes. It doesn't answer with an error message about the image (which IMHO should include a reasonable way to fix the image as well). It freezes my computer, in a way that it is hard to get back. Often the best solution is to turn off the computer and turn it on again. I think this is a major error. The minimum is to throw an error message, in order not to take precious working time of the users.

You just used imagemagick in order to determine the problem, so I assume it would be very easy to fix. Calc should check the image first, instead of freezing.
Comment 8 Buovjaga 2015-12-06 13:43:43 UTC
No freeze when inserting to Calc.

Ubuntu 15.10 64-bit 
Build ID: 1:5.0.3~rc2-0ubuntu1
Locale: en-US (en_US.UTF-8)

Win 7 Pro 64-bit, Version: (x64)
Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75
Locale: fi-FI (fi_FI)

Build ID: 81fa5340191baf8687f9c82f1f414f5afc86b529
Threads 4; Ver: Windows 6.1; Render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-03_21:19:19
Locale: fi-FI (fi_FI)
Comment 9 V Stuart Foote 2015-12-06 14:37:55 UTC
Hmm, well still see it as not our bug--garbage in and all. How does one even get a JPEG without units?

@Tomaž, Armin -- do I have the right take on this, a bug (not ours), or a filter issue?  It seems like regardless of a malformed JPEG, i.e. no units, LO should gracefully handle things on import.  Provide a gentle "fix the image" message, or force a pixel default--but not hang the UI as OP suggests.

Image attached, so "hang" should be reproducible (maybe). I couldn't, but I did get varying image scaling with different LO modules--and calc did have the most trouble with its scaling.
Comment 10 Armin Le Grand 2015-12-07 12:56:09 UTC
In the office, every graphic needs a PrefMapMode and a PrefSize, defining it's 'real' size in the world. If there is no size in the loaded image (there are quite some formats without real world size definitions) there normally is a fallback to MAPMODE_PIXEL and the size in pixels in PrefSize, which should lead to using the default dpi definition (72x72 or 90x90dpi, not sure currently). This will then be used internally to have a size for the image. HTH!
Comment 11 Armin Le Grand 2015-12-07 12:59:25 UTC
One more note: This is usually done by the import filters. I remember there have been cases where the import format did support image sizes, but these were out of scope/wrong. Thus, in cases with unplausible values the import filters would have to detect and work-around that, too (which most currently will probably not do).
Comment 12 V Stuart Foote 2015-12-07 15:01:49 UTC
@Armin, thanks.

Setting component over to filters and storage, rather than against calc alone (it just has the harder time of things).

Looks to need a tweak to set a fallback for sane density_unit/X_density/Y_density values to pass in creating the bitmap container in JPEGCreateBitmapParam, I guess it would go in jpegc.cxx parser.

Comment 13 Armin Le Grand 2015-12-09 16:47:45 UTC
The density_unit gets set to 1 in examine_app0 in the jpeg importer which makes the unit look like inches. Since the image size is in pixels (nA=453 nB=339), the correct translation is {nA=1150620 nB=861060} 100th mm which is way to big.
The unit gets set to 1 since the pic has a /* Found JFIF APP0 marker: save info */ which is used. There indeed a '1' is set ang gets used in 'cinfo->density_unit = GETJOCTET(data[7])'. I guess that is an error in that one file.
Question is how to reliably detect that...
Comment 14 Armin Le Grand 2015-12-10 09:37:06 UTC
Loading with IrfanView and looing at info lets the dpi fields empty, very different from other jpegs. Loading with paint.net uses and shows a size of 453x339 inch, thus keeping the pic at a 'real' size of 5,6 meters width.
It can not be known if this size is by purpose, so I think the office should just handle that - it does already in most cases. Inserting in Draw/Impress make sno problem, the pic gets scaled to page width anyways (if it is bigger as in this case). Thus, the question is:

Where in the office do images with a size like this one lead to problems?
Tried our apps, looks good. Calc indeed uses the logical size and I see only the top-left pixels of the image. This may lead to problems on systems with bad rendering. On Win, this works.
All: Please add feedback for other systems, there seems to be a problem on linux. That would be another strong argument for better rendering for Linux - with any correct image the same effect will happen when just zooming in deeply...
Comment 15 Buovjaga 2015-12-10 10:18:57 UTC
(In reply to Armin Le Grand from comment #14)
> All: Please add feedback for other systems, there seems to be a problem on
> linux. That would be another strong argument for better rendering for Linux
> - with any correct image the same effect will happen when just zooming in
> deeply...

On Linux I see huge pixel blocks.
On Windows it smoothes them.

Win 7 Pro 64-bit, Version: (x64)
Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75
Locale: fi-FI (fi_FI)

Ubuntu 15.10 64-bit 
Build ID: 1:5.0.3~rc2-0ubuntu1
Locale: en-US (en_US.UTF-8)
Comment 16 Tomaz Vajngerl 2015-12-10 10:53:25 UTC
For pragmatic reasons I would treat DPI < 10 as an invalid metadata and would reset to 72 DPI. Someone that really wants a picture with a low <10 DPI can still resize it manually afterwards.

On Linux I don't see the image until I resize it to something reasonable.
Comment 17 Armin Le Grand 2015-12-10 13:27:02 UTC
@Beluga: Thanks for the feedback, seems rendering on your version is good. Win uses (normally) DirectDraw which smoothes the pixels. Do you know what your LO uses on Linux?
@Tomaz: Good suggestion, problem is that when user makes the image big or zooms in we fall back to the same problem. It is a big but valid image. In that case probably an error, but sooner or later we would get a bug with an image that size or similar which is like that by purpose.

At the end it *is* a rendering problem. When only the top-left 10x8 pixels are visible in any (however achieved) configuration, that should be painted flawlessly - on any system.
Comment 18 Buovjaga 2015-12-10 14:53:47 UTC
(In reply to Armin Le Grand from comment #17)
> @Beluga: Thanks for the feedback, seems rendering on your version is good.
> Win uses (normally) DirectDraw which smoothes the pixels. Do you know what
> your LO uses on Linux?

Well I'm using Ubuntu in Virtualbox. Not sure, how to get that info.
Comment 19 QA Administrators 2017-01-03 19:41:02 UTC Comment hidden (obsolete)
Comment 20 Thomas Lendo 2017-05-31 19:15:11 UTC
Bug still present in Version:
Build ID: 5c16d16ed3db32f922b2aeaad49592d2615c7e2c
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-05-26_23:00:41
Locale: de-DE (de_DE.UTF-8); Calc: group

Inserted the attached picture into an empty spreadsheet -> complete Linux system freeze.
Comment 21 QA Administrators 2019-03-01 03:50:02 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team