Bug in 8bf plugin support (and crash)

[brodriguez]

Hello

I've found that the 8bf plugin support don't take into account the valid image modes of each plugin.
XNView call the plugin even if the image mode is not accepted by the plugin.
Itest that with my own plugins (Ximagic Denoiser & Quantizer) with Harry's filters and with Flaming Pear Tachyon.

Fortunately the imageMode which xnview report to the plugin is OK (in filterRecord) and I can put a guard using it and avoid the problem.
The last version of my plugins show a message if the image mode is grayscale and avoid crashing.

But if someone try to use Harry's filters or Tachyon, with a grayscale image, xnview crash.

I suspect guarding against this problem is not usual, and if so there are a lot of plugins that could crash xnview used with grayscale images.

In Phostoshop, GIMP+PSPI and PhotoPaint the plugins which don't accept the image mode are disabled.

In IrfanView, grayscale and even RGB indexed images are send to the plugin as RGB color, which is not correct but avoid crashes.

Regards
Blas Rodriguez Somoza

[XnTriq]

Unexpected results when applying plug-in filters

[brodriguez]

Hello XnTriq.

I've done some work on the 32 bit problem you point. Is it not related with the grayscale crash.

The band that show the samples you point, and which I detect also in my plugins are due to a bug in the plugins.

When a host call a plugin, it tells to the plugin the number of planes available, but the plugin can request only some of the planes.
A RGBA has four planes, if the plugin only work on 3 it should tell it to the host, if the plugin don't do that it receives 4 bytes for each pixel.

Suppose an rgba image with 600 pixels per row, the host send 2400 bytes, but the plugin expects and process 1800 and the 600 final bytes remain unaltered (the band in the samples).

There are two methods a plugin can use to process rgba images.
A.- Take all the data and process only the rgb bytes. (the safest)
B.- Tell the host to send only the rga data. (the riskiest)

I've found another XNView bug here. If the plugin use method B (asks only for the rga data) XNview answers as it has take it into account, but it don't do.

So, the resume of my previous post and the 32 bit processing you point, is that there are two different XnView bugs:
1.- XN don't take into account image modes accepted by the plugin. In grayscale mode, the plugin expects more information than the one it receives and the aplication crash.
2.- If the plugin request only some planes of the image data, XN initially give the correct answer but then sends all the information and the result is wrong .
And one plugin Bug
3.- If the plugin don't take into account the planes reported by the host and the image has four planes the result will be wrong and show an unprocessed band at the right side.

I don't give a more detailed information intentionally, if someone needs it to deal with the bugs I'll be pleased to help.

Here is a sample image, two buggy outputs and the expected output, with Ximagic Denoiser using median 4x4 (I'll publish the patched version today).



The second image is the output if the plugin don't ask for 3 planes (plugin bug) and the third is what happen if the plugin asks for only 3 planes and Xnview give 4 planes (XnView bug).

Regards
Blas Rodriguez Somoza

[XnTriq]

Hi brodriguez

Thanks a lot for your detailed analysis. I'm glad someone is taking a closer look at these issues from an 8BF developer's perspective. Let's hope this can be fixed.

To me XnView's plug-in manager is a true hidden gem. If you don't have Plugin Commander, Plugin Manager or Plug-In Switch, working with Photoshop compatible plug-ins can be a real headache, because most (all?) major image editors make you meander through multiple levels of cascading menus to get to the filter you're looking for.

[brodriguez]

Hi

Thanks a lot for your detailed analysis. I'm glad someone is taking a closer look at these issues from an 8BF developer's perspective. Let's hope this can be fixed.

Lets hope

I've found another bug and I think it is better to maintain the bugs I've found in one thread.

This one is in displayPixelsProc. This procedure is provided by the plugin host and is usually used by the plugin to display previews.

The information is provided to this procedure using a PSPixelMap struct. When this information is in RGB colorspace, the R,G,B planes can be interleaved or not (interleaved when the bytes are ordered RGBRGBRGB.. and not when RRR..GGG..BBB..)

XNView fails when the information comes non interleaved.

There are 3 values used to give the format to the plugin host rowBytes, colBytes and planeBytes.

F.i. if the preview has dimensions = width * height
Interleaved format

Code: Select all

rowBytes = width * 3;
colBytes = 3
planeBytes = 1;

Non interleaved

Code: Select all

rowBytes = width;
colBytes = 1;
planeBytes = width * height;

Hope it helps

[brodriguez]

Another 8bf bug

When a plugin try to get information from a Grayscale image with width larger than 13224 pixels, the information is wrong.

Can be tested with Harry's filters or Ximagic GrayDither.

I've found this bug testing a user image of 13225x8851 pixels, and I've tested it with several images with varying width and fixed height of 1000 pixels.

With an image of 13224x1000 the plugins work OK and with one with 13225x1000 the information get from XNView is wrong, as the preview show.

If the 13225x1000 grayscale image which give wrong results is converted to True Color, then the plugins works OK.

I've not tested if the same limit is applicable to the height.