I cannot reproduce with my sample graphics, please attach the offending graphic
to this issue, so that we can reproduce and fix the problem here. Feel free to
re-open the issue when you've done.
Thanks for supporting us!

Created attachment 36686 [details]
Jpg file saved with 300 DPI

Created attachment 36687 [details]
Jpg file saved with 300 DPI

Sory for the 2 files was not the intention

When you tested with graphics saved with a 96 DPI resolution, ofcourse you can 
not "see" the defect (oo is working with 96 DPI) only graphics with a different 
DPI shows the defect
So my testfile is saved with a 300 DPI resolution.
Hope it helps

Now I see.

MRU->SJ: opening the attached graphic with OO seems to import a wrong "original"
size. Comparing this to MS Paint or Moz Firefox, the graphic is much smaller in OO.

sorry but,
There is more than that, opening as a link or as embedded has different results 
of how the image is "scaled and sised"

here i am again :-)

You must alsoo notice thats the defect behaviour is only present in WRITER not 
in the other Components where we can insert a Picture.
What happens is:
When we insert a picture "embedded" in Writer then OO acts as we can expect: 
the insertWizard uses the number of Pixesl in the Imagefile and the Resolution 
(DPI) who is also present in the Imagefile.
Recently I looked in the API (to find a solution to have more control of how 
pictures are insterted) and found that the graphic.Provider gives us the pixels 
and the dimensions (must be a result of pixesl devided bij the DPI) 

[int(oShape.Graphic.sizepixel.height)] gives us the "pixelHeight in pixels"
[int(oShape.Graphic.size100thMM.height] gives us the "dimension in thMM"
 
Now:
If we embedded a picture, the insertwizard gives us a correct "Original Size" 
but no information on the number of pixels and the DPI pressent in the 
Imagefile.
If we Linked a picture, the inszerwizard gives us a wrong "Orginal Size" who is 
the result of deviding the number of pixesl by the stadard OO-DPI (96) and then 
correct this behaviuour by scaling the picture to endup with the "wanted-
correct" Dimensions.
At is thats no problem as long we stayed in Writer, the problems ocour when 
making PDF's, HTML.... 

Please try to convince your desion-makers that gaving information (who is 
pressent in every ImageFile) about thet number of pixels and the saved-DPI is 
of heigh importance to produce doc's with a proffesional quality, for the WEB, 
LaserPrinters an Press. These diferent outputs have totaly different needs .
For the web we needs 72-96 pixels/inch
For a Laserprinter we need 150-170 pixels/inch
For a press-quality (CMYK) we need 250-300 pixesls/inch 
Having control over this things bring OO a big stap higher as a tool to produce 
Docs who can be used in different ouput envoriments!!!!! 

Thanks for your patience
Fernand(sos)

sj: As sos said, it is a writer problem only, I change the owner to the proper
person of the Writer team..

8 months without news ??
Its still an anoying problem !!!!

8 months without news ??
Its still an anoying problem !!!!

8 months without news ??
Its still an anoying problem !!!!

I can see no difference depending the image is inserted linked or embedded.
Both modes have the same size.

I can confirm the difference of the scaling-value in the Pictures-Dialog, but
honestly I don't think that is high priority...

Trye to understand that, for a more Professional use off OO importing, croping
Images is still a must an one of the (few) weaknesses of the Writer part 

SOLVED

od->mru:
Please take over and confirm that this issue is solved.

yes, can confirm. Compared with Gimp, the graphic has now a correct size in OOo
Writer.

Closed.