I tried to insert it via LibreOffice Writer / Copy-paste and got the same results.

Problem is a malformed JPEG, when I insert the JPEG image into a Windows build
Version: 5.2.0.0.alpha0+
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
    Red:
      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
    Green:
      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
    Blue:
      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:
    Overall:
      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
  Chromaticity:
    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
  Properties:
    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
  Artifacts:
    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

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.

No freeze when inserting to Calc.

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

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

Version: 5.2.0.0.alpha0+
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)

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.

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!

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).

@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.

http://opengrok.libreoffice.org/xref/core/vcl/source/filter/jpeg/JpegReader.cxx  
http://opengrok.libreoffice.org/xref/core/vcl/source/filter/jpeg/jpegc.cxx?#159

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...

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...

(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: 5.0.3.2 (x64)
Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75
Locale: fi-FI (fi_FI)

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

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.

@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.

(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.

Bug still present in Version: 5.5.0.0.alpha0+
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.

Repro 7.3+. I change to Calc, because image inserts in Writer. 
It doesn't hang, but is of enormous size in Calc.

Repro as in comment 23 in recent-ish master build:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 77fca616e0bd79e0b405fd0b3543cf8e94e15df3
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

All other modules OK (Writer, Draw, Impress).