Created attachment 82361 [details]
Test image

Copy this image into an odt file (by r-click > paste) - it pastes correctly.

Now copy the image out of the odt file (l-click > copy), and paste it into various graphics applications like IrfanViewer and Paint.NET.  The image is corrupted as shown in the example

Created attachment 82362 [details]
Test image corrupted as it appears in IrfanView and Paint.NET etc,

Can not confirm
AOO410m1(Build:9750)  -  Rev. 1557669
2014-01-14_04:11:13 - Rev. 1557927
Inkscape 0.48
Krita 2.7.5
Debian

Edwin
What application are you pasting it into?  It is also interesting you are using Debian, not W7, suggesting it may be limited to Windows.  
My wife's laptop (W7 Home 64bit) and a colleague who uses OOo (W7 Professional 64bit) both see the problem so I am surprised you don't see it.

My OpenOffice is 
AOO401m5(Build:9714)  -  Rev. 1524958
2013-09-20 11:40:29 (Fr, 20 Sep 2013)

Paste into the applications Inkscape and Krita
No Win 7 access to me at the moment

I can confirm the wrong clipboard content using AOO410m1(Build:9750)  -  Rev. 1554205 on Windows 7. The Windows application clipbrd.exe shows four active formats:
Erweiterte Metadatei -> looks OK
Grafik -> looks OK
Bitmap -> WRONG, errors are as described in the attached text document
DIB - Bitmap -> not viewable with clipbrd.exe

There are some other formats listed, but they are not active in clipbrd.exe:
DataObject, SVXB (StarView Bitmap/Animation), Star Object Descriptor (XML), GDIMetaFile, PNG, Windows Bitmap, Ole Private Data.

Created attachment 82371 [details]
Paint screenshot

Can not confirm
AOO410m1(Build:9750)  -  Rev. 1560574
Rev.1560574
Win 7

Edwin
You have viewed it in MS Paint which the original post says does not exhibit the problem.  Please view it in IrfanView, Paint.NET or MS Windows ClipBook Viewer (\system32\clipbrd.exe in XP and Vista, n/a in W7 or W8).

missed it, sorry
I don't use these programs but OK in XnView 2.05

Created attachment 82379 [details]
Screen dump of InsideClipboard v1.12 showing contents of clipboard in binary form.


LHS - original, correct image 24 bit, 100 x 100, red[255,0,0]

RHS - corrupt image after copying from Writer, when red > blue

It appears as though the CF_DIB data has been correctly extracted from OpenOffice, but it has been given the incorrect label CF_DIBV5.

Use a test image which 100 x 100 pixels coloured red [255, 0, 0] using 24 bit colour.  When copied onto the clipboard (left in image attached) it is saved in 3 formats:

CF_BITMAP       0 bytes
CF_DIB     30,040 bytes
CF_DIBV5   30,124 bytes

When this image is pasted into Writer, and copied out of Writer, the clipboard has 8 formats.  Looking at CF_DIBV5 we see

CF_DIBV5   30,040 bytes

This is the identical size as the uncorrupted image stored as CF_DIB. 
 
When the clipboard contents are examined, it can be seen that the original CF_DIB image (left in attached image file) is identical to the corrupted CF_DIBV5 image (right in the attached file).

Hi John, thankls for the good analysis, this is probably the reason. I will check this...

The clipboard stuff is quite complicated; I guess I have the choice between adding a new mimetype and support it besides "application/x-openoffice-bitmap;windows_formatname=\"Bitmap\"" or to not offer CF_DIBV5 at all. 2nd option would mean that e.g. Paint.NET would just ask for png which is good and works flawlessly. Checking further...

Trying out the removal of DIBV5 and making png more prominent, this is through many modules, will take a while.

Works well with removed DIBv5 and extended png support, checking how adding DIBv5 would work and if it would give some advantages...

Works well, sad is only that Paint.NET is not exchanging pngs on the clipboard. Checked , I use version 3.5.10, I may upgrade to 3.5.11 to check. All other apps I checked (MyPaint, Gimp2) exchange well with all AOO apps in png. Paint also only uses DIB format.

Tried to add DIBV5 as own mime-type, but then the clipboard format 17 (CF_DIBV5) gets not even asked for. Also checked again that Paint.NET does not exchange transparent graphics with either MyPaint nor Gimp2, so it seems a problem of Paint.NET.
Going on the version with removed CF_DIBV5, preparing to add patch (needs to be checked on other systems)...

Extensively tried that version, I think comitting is safe. Preparing commit...

"alg" committed SVN revision 1562493 into trunk:
i124085 disabled CF_DIBV5 (no advantages but some problems), increased png su...

Comitted, done.

Armin
Many thanks.  If you can point me to how I can download the latest build with this included, I will test it (although I am sure you have fixed it).

Hi John, thanks for wanting to take a look. Its nice that you are sure I fixed it, but taking a look is always better. I have seen other things go wrong...
To the link: There are snapshot builds available, please see http://ci.apache.org/projects/openoffice/. HTH!

Armin

Thanks - it's fixed!
  
I tested http://ci.apache.org/projects/openoffice/install/win/Apache_OpenOffice_4.1.0_Win_x86_install_en-US.exe_1563305.exe with the original images pasted into, then copied out of, Writer and I confirm it has been fixed in all the applications I reported (IrfanView 4.37 and Paint.NET v3.5.11 (build 3.511.4977.23443).  It views correctly in MS ClipBook Viewer in all four formats, namely default format, enhanced metafile, picture and bitmap.  

It also pastes correctly into MS Paint, GIMP and OpenOffice.

I have uploaded the views in InsideClipboard of the fixed results.

Thanks for such a speedy fix.

Created attachment 82499 [details]
Screen dump of InsideClipboard v1.12 showing contents of clipboard - FIXED

Contents of InsideClipboard
LHS - Clipboard contents pasted into OOo
RHS - clipboard contents copied out of fixed OOo Writer

Hi John, thanks for checking! You may set it to verified then and close it.

ALG: Verified by John, thanks!

Closing

Armin
Unfortunately, I have discovered an issue with the fix, although it was also present in 4.0.1.  I cannot identify when the bug I reported was introduced as I inadvertently failed to upgrade from 3.4.1 until January 2014, when I immediately spotted the bug I reported.  I believe everything was OK in 3.4.1.  
In 3.4.1, when I opened a JPG in IrfanView, and copied it and pasted it into OOo, OOo accepted it as a JPG, and stored it in filename.odt[Pictures] as a JPG file.  
In 4.0.1 and this fix, when I open a JPG in IrfanView and paste it into OOo, OOo accepts it as a PNG, and stores it as a PNG.   
In both 3.4.1 and 4.0.1, and this fix, when I File > Insert > Picture > From file, OOo remembers the file type.
Forcing PNG dramatically increases the odt file size for JPG (photo) files.  For example, my $200 camera takes 4320 x 3240 images which are typically about 5MB.  Stored as a PNG they are typically 15MB.
Can I suggest a fix based on OOo remembering whether the pasted file is a lossy compression (JPG) format; or whether it is a lossless or uncompressed (PNG, GIF, TIFF, BMP etc) format; and storing the file in the odt as lossy or lossless in each case.
Storing JPG files in PNG format removes the user selected options at File > Export as PDF > General, where users select the image handling options for producing a PDF suitable for printing.

I edit a magazine and I am extremely careful to select the appropriate format (JPG for photos, and never for text or graphics; and even so at high Quality Factor); and PNG for anything with sharp edges (text or graphics).  If a file comprises both photo and text, an informed decision on whether to use JPG (smaller file, fuzzy edges) or PNG (larger file, no loss of quality) has to be taken.
A workaround is to insert JPG images by Insert > Picture > From file but that loses a lot of flexibility when an image in the document needs to be copied out of OOo, manipulated in an image editor such as IV to reduce pixels, change gamma etc, and then pasted back into OOo.

Hi John, thanks for bringing this up. Just installed irfanview and did the following:
- opened jpeg with inrfanview
- copied to clipboard
- pasted to new draw, saved draw, extracted pic from ODF
-> indeed a PNG

The problem is not that "OOo accepts it as a PNG, and stores it as a PNG". AOO accepts it as RGBA bitmap data (in this case PNG as clipboard format). AOO does not get the original jpeg file via the clipboard (and I thin this is not offered - if someone knows better, please describe here) and thus *cannot* remember it for saving it.
AOO gets a selection of clipboard format and uses the one with the highest quality (this is the best it can do - no reason to change that). Same at save time: AOO chooses the most lossless format (also the best AOO can do - also no reason to change that), in this case of data adding - as said - it has no access to the original data.

When doing the following:
- new Draw
- insert jpeg of your choice
- saved draw, extracted pic from ODF
-> stays original data

In this case AOO *has* access to the original jpeg data and does all correctly. In this case it 'knows' that it cannot increase/save quality when using PNG, so the original jpeg is used (as expected).

So the problem is the method of insertion which in turn defines what information AOO *can* have about the data it gets. Unfortunately the user has to know here what he is doing. Copy/paste from pic viewers or editors (which may already have altered the data) does not contain the original data, so I do not think there can be done something here.

Of course when someone knows how to make e.g. irfanview to deliver the URL to the original file in the clipboard or maybe knows that it's included there, please speak out.

Armin
I apologise for my delay in responding.  
I confirm your observations that copying from an image editor like IrfanView does not pass information of the opened file's format; but Insert > Picture > from file does allow AOO to save the image in the file's format.I was trying to "make sense" of what I was seeing.  I jumped to too many conclusions.

I did a further test which adds weight to your observations being correct.  I opened a JPG in IV and saved it as a PNG.  I then opened the JPG in IV and copied it to clipboard; and opened the PNG in IV and copied it to the clipboard.  In both cases the clipboard contents appeared to be identical in InsideClipboard.  I then pasted the "copied JPG" and the "copied PNG" into Writer.  The ODT contained only one file - a PNG - which strongly suggests that the clipboard content must have been identical in both cases.
 
I reinstalled 3.4.1 and it behaves in the identical manner to (pre-release) 4.1.1, so my observation "it was OK in 3.4.1" is incorrect.
  
It does seem as though the present way of AOO working is best, namely save in the highest quality; and if the user wants to keep his image formats, then he must use Insert rather than paste.

... but copy and paste is so much easier :-(.  I shall have to rethink how I do my magazine.

As an aside, I would expect users to notice that if they paste a photo from a typical camera the ODT will be much bigger than the original JPG image. I was doing some testing with many large images and soon had my ODT up to 200MB.  Four images took it to 60MB.

As a second completely off topic aside, it would be good if the industry came up with a "Universal image format" which was intelligent enough to scan the image pixels and save the "photo" component in JPG and the "graphic" component in PNG.  We would then have minimum file size with maximum quality.

Hi John,

thanks for your comments. Yes, copying the graphic data from another app can be compared to e.g. copying text from Notepad to writer; you just do not know anything about the original format and if 'all' was copied to the clipboard or only some lines. Its similar for graphics, unfortunately. So - yes - the user needs to know here what he is doing, there is no way an app reading the clipboard can find out if it originally e.g. was a jpeg.
At that point the original compression is already gone and even if knowing, re-compressing of the pure pixel data will decrease quality. It is also no option to 'assume' jpeg with big files due to the simple fact that jpeg has no 'holes' (transparency). If it was one fine; if not such aspects may be lost.
I think what the OS producers *could* do is to provide a data type 'original' for the clipboard, that would contain the mime type and the raw data as in the file it comes from (if available), in the format it comes from. Then at least e.g. pixel modifying apps could put this to clipboard when the user had used CTRL-A, CTRL-C; this would be a major change for OSes, other apps and - last and in this change least - users of this data like AOO...Sigh.

Armin
Thanks.  You mention "data type original".  I don't know if this is the same thing, but Clipboard Formats at http://msdn.microsoft.com/en-us/library/aa359736%28v=vs.85%29.aspx, if I read it correctly, seems to say that the clipboard formats CFSTR_MIME_xxx where xxx can be BMP, GIF, JPEG, PJPEG, PNG, SVG, TIFF etc code for those image formats.  Presumably both the sending and receiving applications would need to use them so it would need changes everywhere.

Hi John,

Yers, that's why I added PNG (the most used one) to AOO4; unfortunately not even that is used intensively. Maybe you can make experiments how far others are supported (using your clipboard viewer) or there may be info on the net. Also we are not only on one system (win) but on many. If these formats become more widely used it may be worth to open a feature task...

I got some strange notes about changes in behaviour, I will need to recheck this one.
- copy/paste to new Writer doc with only cursor sometimes only works with 'paste special - bitmap'
- copy/paste from some apps looses transparency, pastes ugly pictures
Verifying if this was caused by these changes before evtl. reopening this task...

Definitely is caused by these changes; I took them back in a current version and the symtoms described vanished. Need to re-check these changes carefully, reopening...

And accepting...

I looked deeper into the clipboard stuff for windows (unified using UNO API implementations) and with deeper understanding found the problem. For mime-type based stuff there is no fixed CF_XYZ ID for the Windows clipboard, but that ID changes with each win restart (probably dependent of who registers it first at the system clipboard). Thus, do not use a fixed ID in the translation table. It would be possible to update that value in the table dynamically when clipboard content is received (at that time there is a match between ID and mime type), but it's all alreday there; just use CF_INVLAID as ID and the correct mime type handling for windows is already in place. I was misleaded niitially by the name of CF_INVLAID; it does not stand for an invalid ID but more for 'this type has no classic CF_XYZ ID'.
Checked and works well. Preparing commit.
@John: At this point really the file is received from the clipboard (in PNG format, others may follow), thus it would be possible to associate this with the BitmapEx and use that 'original' for exports. Unfortunately all our internal APIs only carry the BitmapEx, so this would be very much work to do here.

"alg" committed SVN revision 1570241 into trunk:
i124085 improved support for PNG clipboard format on windows

Okay, committed, done. The described effects are gone.