XnView Software

Hello! I have been using XnView Classic for at least 5 years and today I first encountered this problem, ClipboardNewMethod=0 helped, the latest version of the program, Windows 10 with the latest updates.

Thanks, with the new entry [Start] ClipboardNewMethod=0 it is possible to copy images. Not logical, as it is different in browser and viewer but it finally works :D
I switched to xnviewMP where ctrl-shift-c is always coping the image.

While testing it I found another bug: not all PNGs are shown/recognized as PNG. I coudn´t find the reason. Could be due to the amount of layers inside PNG, but the final size doesn´t matter.

In Browser, if you copy a 32bits PNG, it will be loaded as 24bits, so Ctrl+C works always

Sorry but the problem is not with CopyClipboard (keep CopyClipboard=0)

But [Start] ClipboardNewMethod=0

It seems that some apps don't like the new clipboard format...

In MP, when you use ctrl+c - it copies several things to the clipboard simultaneously - it copies the filename (for pasting into text-only situations) and it copies the image data (bmp, I think).
Exactly. I tried to illustrate this bahavior in my previous post.

I was just surprised that the image was copied without transparency when I used ctrl+c.
:-) Me too, and that's why I'd like to find out why Ctrl+C loses the transparency while Ctrl+Shift+C doesn't.

There was a similar discussion a while back, …

Copy paste PNG from chrome give black background
“Copy image data” loses transparency
Bug: Copy image to clipboard doesn't work anymore ...
… but the focus was on XnView Classic which has a special INI setting .

logo.png @ XnView MP v0.84 x32:

Format | Format Name | Handle Type | Size | Index
-------+-------------------------+-------------+--------+------
17 | CF_DIBV5 | Memory | 55'204 | 1
8 | CF_DIB | Memory | 41'656 | 2
 49566 | image/png | Memory | 8'341 | 3
 49567 | image/bmp | Memory | 41'670 | 4
 49568 | image/cur | Memory | 57'182 | 5
 49569 | image/dds | Memory | 55'208 | 6
 49571 | image/icns | Memory | 5'237 | 7
 49572 | image/ico | Memory | 57'182 | 8
 49573 | image/jpeg | Memory | 1'966 | 9
 49574 | image/jpg | Memory | 1'966 | 10
 49575 | image/pbm | Memory | 1'745 | 11
 49576 | image/pgm | Memory | 13'785 | 12
 49577 | image/ppm | Memory | 41'325 | 13
 49581 | image/tif | Memory | 55'286 | 14
 49582 | image/tiff | Memory | 55'286 | 15
 49583 | image/wbmp | Memory | 1'739 | 16
 49584 | image/xbm | Memory | 8'967 | 17
 49585 | image/xpm | Memory | 39'784 | 18
Format | Format Name | Handle Type | Size | Index
-------+-------------------------+-------------+--------+------
17 | CF_DIBV5 | Memory | 55'204 | 1
8 | CF_DIB | Memory | 41'656 | 2
15 | CF_HDROP | Memory | 46 | 3
 49395 | UniformResourceLocatorW | Memory | 40 | 4
 49376 | UniformResourceLocator | Memory | 19 | 5
13 | CF_UNICODETEXT | Memory | 24 | 6
1 | CF_TEXT | Memory | 17 | 7
 49566 | image/png | Memory | 8'341 | 8
 49567 | image/bmp | Memory | 41'670 | 9
 49568 | image/cur | Memory | 57'182 | 10
 49569 | image/dds | Memory | 55'208 | 11
 49571 | image/icns | Memory | 5'237 | 12
 49572 | image/ico | Memory | 57'182 | 13
 49573 | image/jpeg | Memory | 1'966 | 14
 49574 | image/jpg | Memory | 1'966 | 15
 49575 | image/pbm | Memory | 1'745 | 16
 49576 | image/pgm | Memory | 13'785 | 17
 49577 | image/ppm | Memory | 41'325 | 18
 49581 | image/tif | Memory | 55'286 | 19
 49582 | image/tiff | Memory | 55'286 | 20
 49583 | image/wbmp | Memory | 1'739 | 21
 49584 | image/xbm | Memory | 8'967 | 22
 49585 | image/xpm | Memory | 39'784 | 23

Then why if ClipboardNewMethod=1 copying to clipboard may produce CF_DIB with NULL handle?
The system implicitly converts data between certain clipboard formats: if a window requests data in a format that is not on the clipboard, the system converts an available format to the requested format. The system can convert data as indicated in the following table.
And from the table you can see that system must be capable of converting CF_DIB to CF_DIBV5 and vice versa. But with ClipboardNewMethod=1 it can't for some reason.
And it's even more strange that InsideClipboard always shows NULL for CF_DIB made from logo.png only in Windows XP SP3.
You can't paste such clipboard into HeliosPaint because it errors "java.io.IOException: system clipboard data unavailable". GIMP says such clipboard is empty too (even though there is CF_DIBV5). While if it was nontransparent jpeg copied, then pasting works. Looks like some troubles with transparency implementation.
In 2K SP4 InsideClipboard shows Memory and valid size for CF_DIB, but pasting either crashes applications or is pasted black rectangle.

[after more experiments deleted part of my post]

Well, it appears some apps are buggy, some can't handle alpha channel in any other way but replace it with color, some can import CF_DIBV5 if CF_DIB is not available (like XnView and Pixelformer), some report errors (like HeliosPaint and GIMP). But better fix this NULL handle.

Question to Pierre. When ClipboardNewMethod=1, do you call SetClipboardData() with handle set to NULL? Do you call CloseClipboard() after CF_DIB is pushed to clipboard with ClipboardNewMethod=1 ?

I don't understand, ClipboardNewMethod=0 or 1 works in the same way. I call SetClipboardData with the handle of the CF_DIBV5 or CF_DIB. CloseClipboard is called

Question to Pierre. When ClipboardNewMethod=1, do you call SetClipboardData() with handle set to NULL? Do you call CloseClipboard() after CF_DIB is pushed to clipboard with ClipboardNewMethod=1 ?

hMem [in, optional]
Type: HANDLE
A handle to the data in the specified format. This parameter can be NULL , indicating that the window provides data in the specified clipboard format (renders the format) upon request. If a window delays rendering, it must process the WM_RENDERFORMAT and WM_RENDERALLFORMATS messages.
Set ClipboardNewMethod=1, open XnView in Browser mode, Ctrl+Shift+C logo.png into clipboard. Open InsideClipboard to see CF_DIB has handle NULL. Close XnView. Refresh InsideClipboard's view to make sure CF_DIB still has handle NULL. Now, with XnView closed, which application should process WM_RENDERFORMAT and WM_RENDERALLFORMATS messages (if XnView ever processed them at all)?
-------------------------------------------------------
And something else. Previous test were made with http://www.xnview.com/wiki/logo.png. Does keeping transparency work for you with http://www.xnview.com/assets/img/app-xnsoft-512.png ?

The bug ocurrs on XP SP3 and 2K SP4.
Does it depend on the Windows version how applications (such as XnView) copy image data to the clipboard?
After XnView 2.34 is out, copying logo.png to clipboard works for me on XP SP3 and 2K SP4 in following way.
With ClipboardNewMethod=0 copying and pasting in any application works good, except for the picture itself looks as if alpha channel is ignored or picture layers are set in reverse order. Clipboard contains CF_DIB and CF_DIBV5.
With ClipboardNewMethod=1 on 2K SP4 copypasting works only inside XnView, other apps (MS Paint, Clipboard Format Spy, Ultimate Paint) get crashed in different ways (An unhandled exception has been detected: "Floating point division by zero" ; An unhandled exception has been detected: "List index out of bounds (0)" ; Access violation ). If something is pasted, then it is usually black rectangle of the size of image.
With ClipboardNewMethod=1 on XP SP3 copypasting into MS Paint (transparent parts are replaced with black), XnView (transparency preserved), viewing with CFS works. CF_DIB in clipboard has no size (and handle type is Null when it should be Memory as seen in posts above and in https://msdn.microsoft.com/en-us/library/windows/desktop/ff729168(v=vs.85).aspx ; seems like XP can handle such situation without crashing). CF_DIBV5 has the same size as when ClipboardNewMethod=0.

Thanks for the answer there http://newsgroup.xnview.com/viewtopic.php?f=35&t=32032#p127305
Parameter "ClipboardNewMethod" has no influence on how XnView copies logo.png to clipboard from its own browser on Win2k, object in clipboard has the same size no matter what options are set for reading PNG. Yet you can have difference in reports on color depth of logo.png in tooltip and status bar at the bottom of XnView browser if "Compose with alpha" is selected. Tooltip always shows 32bit when you place mouse pointer over this file in XnView browser, while if "Compose with alpha" is selected for PNG (and after XnView is restarted to apply changes) status bar reports 24bit. Seems like status bar reports properties not for actual file, but for picture to be displayed after all internal XnView conversions.

Is this option absent in Options GUI?
Yes.



ClipboardNewMethod
When disabled, XnView will copy alpha channel transparency (32-bit RGBA) as non-premultiplied/unassociated/straight (vs. premultiplied/associated) component (see Transparency – Straight vs. premultiplied alpha ).
Value: Boolean (0/1), enabled by default
Added in v2.24

[Start]
ClipboardNewMethod=0/1
Is this option absent in Options GUI?

Thank you for reporting back!

I tried again with ImportFormat=1 + ClipboardNewMethod=1 but it doesn't change anything.

I give up... :-)
Yeah, I'm at my whit's end here, too :x
However, I don't think it's necessarily XnView's fault as I've seen too many clipboard incompatibilities between graphics applications during my tests. I'm wondering if something like “ paste special ” would be the solution…

See aslo: “Copy image data” loses transparency

Thanks XnTriq. :)

I tried again with ImportFormat=1 + ClipboardNewMethod=1 but it doesn't change anything.

I give up... :-)

I have inserted "ClipboardNewMethod=0" into xnview.ini and now copy /paste works perfect.

Also I was going to report about error when using "Extract All Into..." with some PSD-files, but then I've found this topic: Error saving PNG so I didn't

Thanks a lot :-)

BTW: Welcome to the forum, Markhaen :-)

However I experience this with Internet Explorer 11 too.
Oddly enough, it works with IE8 on XP :?
Out of curiosity, I've done some testing with Mozilla Firefox…

Code | Description | Size
-----+-------------------------------+----------
0002 | CF_BITMAP | -
0008 | CF_DIB | 1.048.616
0011 | CF_DIBV5 | 1.048.700
C009 | DataObject | 4
C013 | Ole Private Data | 152
C134 | application/x-moz-nativeimage | -
… and the following xnview.ini :

[Cache]
IsActive=0
SavingMode=1

[Capture]
ImportFormat=0/1

[Start]
ClipboardNewMethod=0/1
ParamsSavingMode=1
SavingMode=1
Results:

ImportFormat=0 + ClipboardNewMethod=0 and
ImportFormat=0 + ClipboardNewMethod=1 :
transparency is lost
ImportFormat=1 + ClipboardNewMethod=0 :
transparency is lost & pHYs chunk is added
ImportFormat=1 + ClipboardNewMethod=1 (default):
alpha channel is preserved & pHYs chunk is added
( pHYs chunk = physical pixel dimensions = 120.0×120.0 dpi)