XnView Software

Drahken wrote:Hmm.... When you open that image, are you opening it at full zoom? Taking a hint from xntriq's last post, I tried zooming out on your pic & it disappeared. I unchecked the compose with alpha option, and everything went back to normal. I would definitely try turning that off.

If you still have problems, try batch converting a couple of those images into JPG or PNG or whatever, then open the images you just created. Just because there's an issue displaying an image doesn't always mean that there's an issue reading the image. Sometimes an image will convert without difficulty, even if it displays wrong.

I open it with 100% view, the program is running in full screen. When the transparent index is turned off there are absolutely no problem with those BMPs. When I turn it on there is no picture, no matter what I do (converted pictures are OK) but the small thumbnail-like picture on the tab is alright.
See: http://img216.imageshack.us/img216/6610/xnviewtg5.png

In that case, you don't really have much of a problem. You can either just leave the alpha/transparent index setting turned off when working with those images, and/or use batch convert to convert them all to jpgs or whatever.

xnviewuser wrote:I see. Do you have any ideas about what I should do?

1. Go to Tools » Options... » View » View.
2. Set Auto Image Size to No fit.
3. Open your 32-bit BMP.
4. Convert the image to 24-bit color depth (Image » True Colour) to get rid of the unnecessary alpha channel transparency.
5. Hit Ctrl+S to save/overwrite the file.

XnTriq wrote:Drahken, could you please do a few tests with the Auto image size settings on your system?

Some gifs changes their background when zoomed in/out

Sorry, I should have been more specific. What I meant to say:

XnView v1.90 didn't display transparency of 8-bit GIFs correctly (Some gifs changes their background when zoomed in/out) if Auto Image Size was set to No fit. This bug is fixed in v1.91.
Now I'm wondering whether there's a similar problem with 32-bit RGB-A images like the one posted by xnviewuser.

Drahken wrote:In that case, you don't really have much of a problem. You can either just leave the alpha/transparent index setting turned off when working with those images, and/or use batch convert to convert them all to jpgs or whatever.

I'm looking for a solution that would show all pictures correctly without any conversion or having to change any setting. As far is I know BMPs do not have alpha channel transparency. If that's so kind of a workaround would be possible if the program would detect that the current picture is a BMP so it would temporarily turn off the transparent index automatically (I'm not a programmer).
Please don't get me wrong, I don't want to seem pretentious.

Wikipedia ([url=http://en.wikipedia.org/wiki/Screenshot]Screenshot[/url]) wrote:Hardware overlays

Screenshots of games and media players sometimes fail, resulting in a blank rectangle. The reason for this is that the graphics are bypassing the normal screen and going to a high-speed graphics processor on the graphics card called the hardware overlay. Generally, there's no way to extract a computed image back out of the graphics card, though software may exist for special cases or specific video cards.

The trick to capturing those images is to turn off the hardware overlay. Because many computers have no hardware overlay, most programs are built to work without it, just a little slower. Here's a quick way to switch off the hardware overlay in Windows XP. Open Display Properties, Click Advanced, Click the Troubleshoot Tab, and Move the Hardware Acceleration Slider to "None." The hardware overlay is now disabled.

moonrocks (AfterDawn.com Forums: [url=http://www.htmlhelpcentral.com/messageboard/showthread.php?t=12977]How do I print screen from Media Player Classic?[/url]) wrote:Instead of using Print-Screen, in MPC have you tried File, then Save Image?

Otherwise, I'm guessing it's a problem with the video being displayed in overlay mode. In MPC, View, Options, Playback, Output, under Direct show video try switching from System Default or Overlay to VMR7 or VMR9 renderless.

visions (HTML Help Central: [url=http://www.htmlhelpcentral.com/messageboard/showthread.php?t=12977]How to take Screenshots of Movies[/url]) wrote:Here are some common solutions to capture pictures from DVD movies currently playing with Windows Media Player Classic or other video players. It should also work for movies (wmv, mov, avi) embedded in a webpage.

[...]

4. Don't use Overlay

Akikaze (Quick Online Tips: [url=http://www.quickonlinetips.com/archives/2005/03/capture-images-from-windows-media-player/]How to Capture Screenshots from Windows Media Player[/url] » Comment #112) wrote:Well with the hint of the overlay, i test it in other players, and for de Media Player Classic (i know the thing of the Ctrl-8 but for my dont work and the Imp Pant dont work either) you go to View>Options>Playback>Output and change where say “Direct Show Video” to “VMR9 (windowed) if you have DirectX9 installed, i havent test if work changing in “VMR 7/9 & DirectX7/9″ to “Use regular offscreen plain surfaces”

Raphaël Quinet [url=http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg12307.html]Re: [Gimp-developer] 32bit BMP appear blank[/url]) wrote:I have not tried these programs supporting alpha channels in BMP but from their descriptions I could identify the following strategies when loading 32-bit BMP or ICO files:

1. Always ask the user if the alpha channel should be used or not
2. Use the alpha channel if and only if it contains at least one non-zero value.
3. Use the alpha channel if the file name ends in .ICO, ignore it if it is .BMP.

The second strategy seems like a good compromise and would probably work in most cases (i.e., match the user's expectations).

BMPs are such an antiquated format that I'm surprised they even have the capacity for an alpha channel. Unless you're making images for use within windows itself, or some ancient program, BMPs have no use what-so-ever. A PNG with a compression level of 1 saves just as quickly, is just as lossless as a BMP, yet makes a file that's less than half the size (with a photographic image, a logo or graphic image would wind up even smaller).

In any case, here's a few options I can think of:
1) Batch convert all those BMPs into BMPs. Yes that sounds pointless, but doing so should convert them from 32bit BMPs to 24bit BMPs, removing the alpha channel (which does nothing in those images anyway), but leaving them otherwise unchanged.
2) Leave the compose /w alpha/transparency option off, but then go into the read/write->read->PNG and turn on transparency for PNGs. There used to be an option to turn on transparency for GIFs, but I can't find it now.
3) If you set it to keep the settings in an ini file in the xnview folder, you can install multiple copies of xnview and have each use different settings. You could then use one installation for most of your images & leave the global transparency/alpha setting on, and use the other just for these BMPs, and leave the trans/alpha setting off.

I realize that none of those options are really solutions, but they should be pretty effective workarounds until the underlying problem gets fixed.

I'm using VMR9 (windowed) and the "Save image" option (not printscreen). So you're saying that the proper solution would be that the program would ignore the BMPs' alpha channel?

[quote=wikipedia]Images are generally stored with a color depth of 2 (1-bit), 16 (4-bit), 256 (8-bit), 65,536 (16-bit), or 16.7 million (24-bit) colors (the bits represent the bits per pixel). 8-bit images can also be greyscale instead of indexed color. An alpha channel (for transparency) may be stored in a separate file, where it is similar to a greyscale image. A 32-bit version with integrated alpha channel has been introduced with Windows XP and is used within its logon and theme system; it has yet to gain wide support in image editing software but has been supported in Adobe Photoshop since version 7 and Macromedia Flash since version MX 2004.[/quote]

Only windows XP and recent adobe products support an alpha channel in a BMP file. In practice, the BMPs shouldn't even have an alpha channel at all. (If they're going to try to improve the outdated BMP format, they need to work on compression first, long before worrying about adding fancy features. Doesn't do any good to add an alpha channel if no one will use the format because of it's insane filesize.)
Ideally, every program should handle every format without problems. However, ignoring the alpha channel should be perfectly acceptable in this case, since it doesn't perform any function (and may not even be an official addition to the format, it could very well just be something microsoft decided to just throw on for the heck of it).