“Copy image data” loses transparency

[XnTriq]

XnView v2.33

1. Download logo.png.
2. Select the thumbnail in XnView's browser.
3. Go to Edit » Copy image data.
4. Go to Edit » Import Clipboard.

[xnview]

it works for me on 7

[XnTriq]

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?

[xnview]

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?

yes i think

[uRsti11anError]

This is a matter of how particular application uses clipboard.
You can see the difference using Clipboard Format Spy.
In Windows 2000, when you copy to clipboard downloaded logo.png from XnView browser, clipboard contains object CF DIBV5 size of 41740 bytes. Importing clipboard to XnView gives white background. If you open the same downloaded logo.png file from your disk with Opera 12, then right-clicking it and choosing Copy Image gives you CF DIBV5 object size of 55204 bytes in clipboard. Difference in size is roughly size of alpha-channel data. Importing this clipboard to XnView gives transparent background.

[XnTriq]

This is a matter of how particular application uses clipboard.
You can see the difference using Clipboard Format Spy.

Yes, CFS is the utility I've been using for my tests:

Out of curiosity, I've done some testing with Mozilla Firefox…

Code: Select all

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 |         -

Firefox v11.0 is the only program on my old Windows 2000 box capable of copying the alpha channel over to XnView. A more recent version on XP fails to do so.

Code: Select all

Code | Description           |    Size
-----+-----------------------+--------
0002 | CF_BITMAP             |       -
0003 | CF_METAFILEPICT       |      16
0008 | CF_DIB                | 784'936
0009 | CF_PALETTE            |       -
000E | CF_ENHMETAFILE        |       -
0011 | CF_DIBV5              | 785'020
C003 | OwnerLink             |      35
C004 | Native                | 378'562
C009 | DataObject            |       4
C00B | Embed Source          | 378'562
C00E | Object Descriptor     |     126
C013 | Ole Private Data      |     344
C1C8 | Adobe Photoshop Image |       -
C1ED | Photoshop DIB Layer   |       -
C1EE | Photoshop DIB Layer X |       -

Code: Select all

Code | Description                             |    Size
-----+-----------------------------------------+--------
0002 | CF_BITMAP                               |       -
0008 | CF_DIB                                  | 790'584
0011 | CF_DIBV5                                | 786'556
C009 | DataObject                              |       4
C013 | Ole Private Data                        |     184
C295 | PNG                                     |  76'487
C2BF | Fireworks Internal Clipboard Format 3.0 |       -

Code: Select all

Code | Description                              |      Size
-----+------------------------------------------+----------
0002 | CF_BITMAP                                |         -
0003 | CF_METAFILEPICT                          |        16
0008 | CF_DIB                                   |   784'936
000E | CF_ENHMETAFILE                           |         -
0011 | CF_DIBV5                                 |   785'020
C009 | DataObject                               |         4
C013 | Ole Private Data                         |       312
C16E | Jasc Paint Shop Pro 7.0 Clipboard Format |   524'288
C1FB | Jasc Paint Shop Pro 6.0 Clipboard Format |   524'288
C207 | Jasc Paint Shop Pro 9.0 Clipboard Format | 1'048'576
C213 | Jasc Paint Shop Pro 8.0 Clipboard Format | 1'048'576

Code: Select all

Code | Description |    Size
-----+-------------+--------
0002 | CF_BITMAP   |       -
0008 | CF_DIB      | 786'472
0011 | CF_DIBV5    | 786'556

Code: Select all

Code | Description |    Size
-----+-------------+--------
0002 | CF_BITMAP   |       -
0008 | CF_DIB      | 786'472
0011 | CF_DIBV5    | 786'556

[uRsti11anError]

PNG reading options is something that works not clear enough for me.
When I have them unchecked like here http://newsgroup.xnview.com/viewtopic.p ... 32#p127263 , logo.png is displayed with preserving transparency by XnView on Windows 2000. When I have them both enabled, logo.png has white background. I'll try them one at a time next.
Ok, with "composed with transparency" logo.png has transparent background, with "composed with alpha" white. Second option seems to override first? Why is allowed selecting both? Shouldn't transparency and alpha channel serve the same purpose?

[XnTriq]

PNG reading options is something that works not clear enough for me.

My recommendations regarding these settings: 2007 & 2014

[uRsti11anError]

Thanks for the answer there http://newsgroup.xnview.com/viewtopic.p ... 32#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.

[XnTriq]

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.

Yes, this is also how XnView handles indexed-color/paletted PNGs with alpha-channel transparency (v1.97+)…

• Colours in PNG images not displayed properly
• Alpha channel in PNGs
• Some PNGs 32 BPP shown as 24BPP…
• Partial Transparence in GFL_COLORS and GFL_GREY
• Resize does not preserve the alpha channel of PNG images

… as well as animated GIFs (v1.96+)…

• AGIF with local palettes & interframe transparency

OldGifAni

• When enabled, XnView uses old 8-bit instead of 32-bit decoding for animated GIF files.
  Value: Boolean (0/1), disabled by default

… and PNG animations:

• APNG - BPP

[XnTriq]

Shame on me! I forgot about MP

Code: Select all

Code | Description      |      Size
-----+------------------+----------
0002 | CF_BITMAP        |         -
0008 | CF_DIB           |   786'472
0011 | CF_DIBV5         | 1'048'712
C009 | DataObject       |         4
C013 | Ole Private Data |       472
C16B | image/xbm        |   168'275
C18C | image/bmp        |   786'486
C190 | image/png        |    28'625
C1A5 | image/tiff       | 1'048'758
C1B3 | image/jpeg       |    65'603
C1E2 | image/ico        |    67'646
C201 | image/tif        | 1'048'758
C20B | image/jpg        |    65'603
C217 | image/ppm        |   786'447
C238 | image/xpm        |   536'704

BTW: Converting Icon_2-512.png (512×512) to BMP format results in 1'048'630 (32-bit) and 786'486 (24-bit) bytes.

[XnTriq]

InsideClipboard + XnView v2.33 & logo.png

Code: Select all

Format ID | Format Name | Handle Type |   Size | Index
----------+-------------+-------------+--------+------
        2 | CF_BITMAP   | Bitmap      |      0 |     2
        8 | CF_DIB      | Memory      | 41.656 |     1
       17 | CF_DIBV5    | Memory      | 41.740 |     3

Code: Select all

Format ID | Format Name | Handle Type |   Size | Index
----------+-------------+-------------+--------+------
        2 | CF_BITMAP   | Bitmap      |      0 |     2
        8 | CF_DIB      | Memory      | 55.120 |     3
       17 | CF_DIBV5    | Memory      | 55.204 |     1

[Mixer]

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/librar ... s.85).aspx ; seems like XP can handle such situation without crashing). CF_DIBV5 has the same size as when ClipboardNewMethod=0.

[XnTriq]

I can confirm that XnView v2.34 (standard settings) produces identical results for Copy image data (Ctrl+Shift+C) in Browser and Copy (Ctrl+C) in Viewer

[Mixer]

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 ?