Issue 22753 - Image Cropping with jpeg preview ok but on the page wrong
Image Cropping with jpeg preview ok but on the page wrong
Status: ACCEPTED
Product: Writer
Classification: Application
Component: code
OOo 1.1
PC Windows 2000
: P3 Trivial with 2 votes (vote)
: ---
Assigned To: Oliver Specht
: oooqa
Depends on:
Blocks: 105217
  Show dependency treegraph
 
Reported: 2003-11-23 13:11 UTC by Unknown
Modified: 2013-08-07 14:38 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
oo writer with image with wrong cropping (488.92 KB, application/octet-stream)
2003-11-26 21:20 UTC, Unknown
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2003-11-23 13:11:23 UTC
Cropping images no longer works accurately. In 1.0.3 it worked fine with jpeg.
Comment 1 jensja 2003-11-25 23:45:55 UTC
@perelandra: Please post a step by step instructions to reproduce the
problem. If possible attach sample files that can be used in
conjunction with your description.
Comment 2 Unknown 2003-11-26 21:20:18 UTC
Created attachment 11576 [details]
oo writer with image with wrong cropping
Comment 3 Unknown 2003-11-26 21:21:15 UTC
Added Example with wrong cropping.
Comment 4 jensja 2003-11-27 18:04:09 UTC
Tested with build 680 M13 on Win2k. 
Reproducible problem with the attached document: Actual cropping area
differs widely from cropping preview on "Crop" page in "Graphics" dialog.
Looking for duplicates.
Comment 5 jensja 2003-12-03 15:49:23 UTC
confirming. set target -> OOo 1.1.1
Comment 6 jack.warchold 2003-12-11 17:17:11 UTC
due the las comment of jensja
reassigend to od

regressionbug
let target as 1.1.1

Comment 7 Oliver-Rainer Wittmann 2003-12-12 10:41:03 UTC
OD->THB:
Please take over.

Debug hint for Writer: 
method SwGrfNode::GetGraphicAttr(..) in /sw/source/graphic/ndgrf.cxx, and 
method SwNoTxtFrm::PaintPicture(..) in /sw/source/doc/notxtfrm.cxx

BTW, cropping in Calc doesn't function at all.
Comment 8 thb 2003-12-15 11:46:27 UTC
Hm, looks like a problem in the (shared) crop dialog. Will have a look.
Comment 9 thb 2003-12-15 17:42:26 UTC
Hm. It now looks like the behaviour for _linked_ graphics is correct. KA once fixed a problem in 
SvxBrushItem::DoneHdl_Impl, forcing to load JPEGs without logical size specifically for 
Writer (internal bugid 106763). There are several other places in sw which call ImportGraphic 
without that flag, have to check that with the writer folks tomorrow.

I cannot reproduce the 
problem with Calc, my OOo1.1 final behaves correctly.
Comment 10 thb 2003-12-16 13:29:58 UTC
THB->OS: As discussed, please have a look at the crop dialog's usage of SvxBrushItem. The 
behaviour of the SvxBrushItem is kinda fixed, to remain compatible with old documents.
Comment 11 stefan.baltzer 2003-12-16 14:44:09 UTC
SBA: Target set to OOo 1.1.2
Comment 12 Oliver Specht 2003-12-19 13:10:48 UTC
.
Comment 13 thorsten.ziehm 2004-03-12 10:26:54 UTC
Because of limited resources it is not possible to fix this problem in OOo1.1.2.
We decided to set this task to OOo2.0.
Comment 14 andreas.martens 2004-06-17 15:07:11 UTC
Because of a shortage of resources we have to retarget this issue to OOo later. 
Comment 15 greyham 2008-03-15 05:29:05 UTC
This problem still exists in OOo 2.3. I came across it using a different JPEG 
image.
It only occurs when the image is inserted as a link. If the image is inserted 
into the document without using a link, cropping works as expected. It works 
correctly in both cases if the image is a GIF, and also works correctly with 
other JPEG images.

It looks like it's related to the image dimensions or resolution being 
miscalculated. If you open the attached document in cropping_problem.zip, 
go "break link", and reopen the Picture->Crop panel, the "Original Size" 
and "Scale" values change, the cropping region in the preview changes, and 
aspect ratio of the picture in the document is all wrong; but now that the link 
is broken, cropping starts working sensibly.

I also notice that when the document is first opened, "Read Error" appears in 
the document window very briefly before the image appears. Perhaps the initial 
attempt to read the image dimensions is mucking up somehow.
Comment 16 greyham 2008-04-06 12:41:12 UTC
I've just been having a look at this problem. It only happens with JPEG images 
which have an explicit resolution in them (i.e. jpeg_read_header returns with a 
cinfo.density_unit != 0). These JPEGs are commonly generated by scanners.

It appears that when an image is inserted as a link, its dimensions are 
remembered in ImpGraphic::maEx in Pixels (MAP_PIXELS). When it is inserted 
without using a link, its dimensions are remembered in hundredths of a mm 
(MAP_100TH_MM). I haven't yet worked out where in the code this distinction is 
made, or whether this behaviour is correct.

When the Picture dialogue box is opened, SvxGrfCropPage::GetGrfOrigSize is used 
to calculate the original image size in TWIPs. In the former case where the 
dimensions have been remembered in pixels, SvxGrfCropPage::GetGrfOrigSize calls 
OutputDevice::PixelToLogic to do the conversion; but it uses the resolution of 
the output device (96 DPI) rather than the original image resolution so it gets 
the wrong answer.

The file landschaftsgartner_8.jpg in the attached .zip for example has a 
resolution of 200 DPI which is why it triggers the bug.
The behaviour is also wrong in OpenOffice 2.0.4 on Debian GNU/Linux Etch; it's 
not just a Windows problem.
Comment 17 Matthias Basler 2008-12-21 21:09:24 UTC
I ran into this issue today with OOo3.0 m9 (!) on WinXP SP2.

How can it be that an image cropping bug hasn't been fixed for years?
Do you need more reproducable examples?

What I found today were two (possibly related) effects:
- Cropping an image on the left side would show a correct preview, but on the
page the image would be stretched to the left into the (correctly calculated)
space. Of course the image aspect ratio was NOT supposed to change.
- After I set an image to "Original size" it would ignore any cropping applied,
even if deleted and reinserted.

Sorry to say this, but the crop function seems so buggy to me it is almost
unusable for an everyday user.
Comment 18 greyham 2008-12-21 23:11:12 UTC
The original attachment shows the problem quite convincingly; in fact, any high
resolution image from a scanner will do so. Digital camera images on the other
hand generally will not, because they lack an explicit pixel density. What we
need is someone who understands the OOo imaging model well enough to work out
what's going wrong and how to fix it.

A workaround in the meantime is to avoid using links when importing JPEG images
from scanners.