XnView Software

nintendomaniac64 wrote: Fri Jul 09, 2021 6:28 amI've attached an example of one of the offending PNGs

We're dealing with a truecolor PNG with a (single color) tRNS chunk.

I was able to batch-convert 0.png using Greenfish Icon Editor Pro v3.6 (Windows + Linux) to XnView-compatible 32-bit BMP, PNG, TGA and TIF. Transparency was retained.

XnTriq wrote: Fri Jul 09, 2021 2:30 pm I was able to batch-convert 0.png using Greenfish Icon Editor Pro v3.6 (Windows + Linux) to XnView-compatible 32-bit BMP, PNG, TGA and TIF. Transparency was retained.

On both Linux and Windows, the batch conversion function does not allow me to select folders which is a big part of the issue here - the source PNGs are already sorted into a slew of folders and subfolders, and I'd really prefer to retain that folder arrangement as manually recreating that arrangement would be a major pain due to just how many folders and subfolders there are (I'm dealing with thousands of images here).

I've included a second "1.png" problematic image (note that it looks similar, but if you more directly compare it to 0.png then you'll see that it is different) inside of the attached ZIP archive that contains the following simplified version of folder arrangement that I'm dealing with:

/images/folder_a/0.png
/images/folder_b/1.png

So from there I need to be able to simply select the "images" folder and be able to not only batch-convert 0.png and 1.png but have the resulting images be output to the same folder arrangement and/or to the source folders, once again resulting in something like:

/images/folder_a/0.tif
/images/folder_b/1.tif

@Pierre: Is there any chance you'll implement this function?

http://www.libpng.org/pub/png/libpng-1.2.5-manual.html#section-3.7 wrote:The following code transforms grayscale images of less than 8 to 8 bits, changes paletted images to RGB, and adds a full alpha channel if there is transparency information in a tRNS chunk. This is most useful on grayscale images with bit depths of 2 or 4 or if there is a multiple-image viewing application that wishes to treat all images in the same way.

Code: Select all

if (color_type == PNG_COLOR_TYPE_PALETTE)
	png_set_palette_to_rgb(png_ptr);

if (color_type == PNG_COLOR_TYPE_GRAY && bit_depth < 8)
	png_set_gray_1_2_4_to_8(png_ptr);

if (png_get_valid(png_ptr, info_ptr, PNG_INFO_tRNS))
	png_set_tRNS_to_alpha(png_ptr);

These three functions are actually aliases for png_set_expand(), added in libpng version 1.0.4, with the function names expanded to improve code readability. In some future version they may actually do different things.

XnTriq wrote: Sat Jul 10, 2021 1:30 am @Pierre: Is there any chance you'll implement this function?

Thanks to your detailed description I can reproduce the problem.

xnview wrote: Mon Jul 12, 2021 9:36 am Thanks to your detailed description I can reproduce the problem.

Looking forward to v0.98.5

In the meantime, my Linux guru friend at least came up with the following command to effectively do the same, albeit in a single-threaded manner (though in my case I have two main folders, so I was able to at least saturate two cores by running one instance per folder):

That however makes the resulting images end in .png.webp rather than just .webp so to achieve that instead there's also the following alternate command (note that it requires one to first install the "parallel" package through your package manager and/or "apt get" or the like):

Interestingly, despite the lossless compression being set to maximum (6), the resulting file sizes are still a bit larger than what XnView MP creates when similarly set to lossless maximum compression, and this was tested with a 24bit image without transparency. So it's not quite as ideal then, but it'll at least work for me as a stop-gap solution in the meantime.

XnTriq wrote: Fri Jun 18, 2021 3:45 amDue to a limitation in XnView's library, an additional action (Image → Change color depth → 32 bits) is neccessary during batch conversion (prior to Image → Resize) when you're dealing with “cheap alpha”. This extra step will ensure that transparency is preserved in all input files upon resizing.

This workaround is no longer needed in the latest release (v0.99.0)

Tested on Windows 10 Pro 20H2 64-bit with these files:


There's still a problem with binary+tRNS.png, though:

Hi All! I think i'm still having a problem with this issue. First off, I'm using XnviewMP 1.3.1 oct11 64bit on Win 10.

So this is the original image I'm trying to resize:


When I resize it, the background goes green and alpha is gone. I saw info in this thread about converting to 32bit to save alpha first. When I try that, the background goes green and I lose alpha again?


How can I resize this image and not lose alpha?

drylightn wrote: Tue Nov 15, 2022 8:00 pm How can I resize this image and not lose alpha?

You can use Batch convert
- Change color depth - 32bits
- Transparent color - 71/112/76
- Resize

Thanks for responding! Is there a way to do this in the main Xnview window without using batch convert? I guess export it and use the select transparent color method?

Thanks to your detailed description I can reproduce the problem.

This problem is supposed to be fixed in XnView MP 1.5.0 beta. Please check and confirm the bug fix here.

Thanks! I just used my test above and resized it, looks like that fixed it!