Apache OpenOffice (AOO) Bugzilla – Issue 62269
jpg graphics imported distorted when cropped
Last modified: 2017-05-20 11:15:37 UTC
a jpg is imported in writer and shown correctly. When cut using the built in menu the cut picture is shown correctly in the preview window but it will be shown distorted in the text. The export to pdf will be distorted. But a copy of the picture using cut and paste to a graphics program will be undistorted. A test file including test procedure has been sent to Michael Hoehne and Robert Grosskopf. Robert Grosskopf verified this problem on his system. So it is not related to Win2k. The cut option did work when the picture was converted to png or tif.
Created attachment 34283 [details] shows procedure to get error, includes test picture
*** Issue 62269 has been confirmed by votes. ***
MRU->OD: I was only able to see the problem in Writer. Isert the graphic into a WRiter document, crop with with similar values as in the sample document and the graphic's content will be distorted.
adjust target milestone to OOo 2.x
Defect not reproducable in OOo 2.0.3, if the picture is newly inserted (existing picture in given document still corrupted). There seems to be a problem in previous version on importing JPEG graphic file - the size of picture isn't imported correct. Thus, the cropping algorithm doesn't work as excepted.
re-assign to MRU for verification
set status to WORKSFORME
Yes, in OO2.0.3 this will work.
the cutting of the jpg works correctly if it is embedded as a graphics. But when I import the above example graphic with the file not being embedded (by clicking on the 2 fields "Verknüpfen" and "Vorschau" in the picture embedding menue) it wont work. The picture then will be unfortunately shown distorted as before.
MRU->OD: Matthias is right, the bug still occurs inserting the graphic linked into a document. Then cropping with same values as in the sample will give a kind of stretched graphic.
Yes, I've missed this difference. Further investigations reveals that the original size between the embedded graphic and the linked graphic differ. The one for the linked graphic is much bigger. I tried another JPEG file. The original size of this JPEG file doesn't differ in embedded and in linked case. Thus, no problems during cropping. I opened JPEG file <stoerfeld.jpg> with MSPaint and saved it with another filename. I also can't reproduce the described defect with the resaved JPEG file. I opened JPEG file <stoerfeld.jpg> with IrfanView and after adjusting the DPI values I saved it with another filename. With this JPEG file I either can't reproduce the described defect. Thus, it seems that the JPEG file <stoerfeld.jpg> is somehow corrupt. Probably the JPEG header data isn't consistent in its value of pixel size and DPI - only a suggestion.
OD->MRU: Please verify my investigation, that the described defect only occurs this the attached JPEG file and close this issue as WONTFIX
the interesting thing is that the cutting of the picture really does work correctly when the picture is imported. The cutting is also shown correctly in the preview window. The only problem occurs when these 2 boxes are marked. It is still not very clear for me if this is really a problem of the jpg file itself.
sj->od: The problem is that the crop attribute depends to the original graphic size. And as I found out, in Writer the original graphic size of jpegs vary between jpegs using the logical size and jpegs using the pixel resolution (as it is standard in html). By default our jpeg import filter is using the logical size, in case of SvxBrushItems the jpeg graphic is imported using pixel resolution. If you want to reproduce this phenomenon, then please break in svtools/source/filter.vcl/jpeg/jpeg.cxx at following line: pJPEGReader = new JPEGReader( rStm, pCallerData, ( nImportFlags & GRFILTER_I_FLAGS_SET_LOGSIZE_FOR_JPEG ) != 0 ); If nImportFlags is having the value 1, then jpegs are imported using the logical size, otherwise if the value is 2 the pixelsize is used. From my point of view it is a Writer problem.
if I "save as" the above file to word 97/2000/XP and then have a look at the picture it looks as distorted as before. In Writer the scaling in the "cut"-menue is given with 40 to 40% for width and height. In the exported Word file, opened up in Word the cut values for width and height are given correctly als in Writer but the scaling is given (incorrect) with 694 to 94% which explains why the picture looks such distorted. When I change the scaling to 94 to 94% in Word it looks much better, but still is not what was shown in the writer preview.
according to release status meeting -> 3.x
now I have OO 3.2. Since my first report 4 years have passed. I got jpg files from a scanner and embedded them in an odt file. Then I wanted to crop one picture. This was shown correctly in the preview but not in the document as you can see in the attached file. So this is not solved yet - waiting 4 years for a fix. 8 votes are there? Will there be a fix in the next year? Or no fix at all? I really would like to know about.
Created attachment 69746 [details] test file to show problem, unfortunately picture 01.jpg is bigger than 1MB, so I cant add this here.
The link to the picture file is this: http://www.cshare.de/file/99ec44339334f3199a68963daa3bc68f/01.jpg.html normally this will be deleted in 30 days.
the problem with the jpg picture remains when I use Irfan to resave it as another jpg.
Investigation of the newly provided JPEG file reveals the same as four years ago: - saving the given JPEG file in MSPaint somehow corrects its. The given size resolutions in the JPEG seems to be inconsistent. But, as SJ already pointed out the problem can be also workaround in the Writer by using adjusting its usage of the JPEG reader. I will have a closer look.
I figured out that for the picture format dialog when it is used from the Writer for linked graphics is filled with a more or less "empty" <SvxBrushItem> instance. Thus, an import of the intrinsic graphic is triggered by the <SvxBrushItem> instance. This import, as SJ figured out, triggers a JPEG read process using the pixel resolution to determine the graphic size. This is not necessary. The <SvxBrushItem> instance can be filled as in the case for an embedded graphic. I will perform the corresponding change to the code in cws sw33bf05.
fixed in cws sw33bf05 - changed file: /sw/source/ui/shells/grfsh.cxx, change set 93841f4f9ae2
od->mru: Checked in internal installation set of cws sw33bf05 - please verify. Please have a close look at the complete graphic format dialog and its tab pages, especially for linked graphics.
->mru/od: The changesets of this fix have been removed from the cws. The crop dialog worked for newly inserted jpg pictures, only. After storing and reloading the document the crop dialog didn't work anymore.
MRU->OD: the fix has to be adjusted. Problem is, that when inserting a linked image, saving and reloading all controls in the crop dialog will be disabled.
That is bad - according to Murphy such things happens and I was on vacation. In the meanwhile the development for OOo 3.3 is closed - http://wiki.services.openoffice.org/wiki/OOoRelease33 -> adjusting target
set target 3.x since not relevant for 3.4 release.
Reset assigne to the default "issues@openoffice.apache.org".