XnView Software

But it seems there is zero documentation and one barely functioning example. So...Is there actually a "freely available" plugin interface or is this a myth?

I've been searching and hacking all day and I cannot make the one example I found (a plugin sdk circa version 1.65) work if I modify it, even in trivial ways. (xnview stops recognizing the dll after I add a few functions to it).

Is there a real plugin sdk that works with 1.80 and/or some hidden cache of documentation or examples I havent found yet?

xnview seems ideal for my application (biological imaging research) in all respects except its lack of support for certain flavors of TIFF that I happen to use.

d-b

destructuring-bind wrote:But it seems there is zero documentation and one barely functioning example. So...Is there actually a "freely available" plugin interface or is this a myth?

I've been searching and hacking all day and I cannot make the one example I found (a plugin sdk circa version 1.65) work if I modify it, even in trivial ways. (xnview stops recognizing the dll after I add a few functions to it).

Is there a real plugin sdk that works with 1.80 and/or some hidden cache of documentation or examples I havent found yet?

xnview seems ideal for my application (biological imaging research) in all respects except its lack of support for certain flavors of TIFF that I happen to use.

d-b

Do you have the Plugin SDK? What is the plugin circa??

I have _a_ Plugin SDK. In the comments at the top of Xuser.c it says it works with xnview version >= 1.65. This isnt strictly true, as I gather dlls need to be renamed to .usr and moved to /Plugins rather than /PluginsEx. I hope there is a more recent version of the SDK that I havent been able to dig up.

Again, the simple example works but even trivial modifications cause it to cease to be recognized. I dont know how xnview decides which libraries to load, and I dont understand why replacing the contents of a single function should cause the library not to be loaded at all.

d-b

destructuring-bind wrote:I have _a_ Plugin SDK. In the comments at the top of Xuser.c it says it works with xnview version >= 1.65. This isnt strictly true, as I gather dlls need to be renamed to .usr and moved to /Plugins rather than /PluginsEx. I hope there is a more recent version of the SDK that I havent been able to dig up.

Again, the simple example works but even trivial modifications cause it to cease to be recognized. I dont know how xnview decides which libraries to load, and I dont understand why replacing the contents of a single function should cause the library not to be loaded at all.

Strange, perhaps try to remove [Plugins] entries in xnview.ini

The problem turned out to be silent failure to load the dll due to an outdated libtiff.dll I was using.

I still need either a) some documentation or b) some extensions to the GFL plugin api. Here is the problem:

Our lab generates copious numbers of TIFF images in single-channel, 16bit signed integer or 32bit floating point formats. The actual signal may lie in any small range though usually centered around zero. I would like gfl and xnview to be aware that I can supply (at least) 16bit per channel so that the contrast and brightness adjust operations can actually be used. Otherwise I have to prescale the data before I give it to gfl/xnview squashed into just 8 bits and just hope the range is ok.

GFL appears to support 1-channel, 16-bit greyscale images internally, but the plugin API example in the Plugins SDK does not. What can I do to fix this?

Another problem is that my xnview thinks it knows how to open my original tiff files, but fails to do so in a useful way. How do I override the default tiff loader to have it try my plugin first?

Thanks,

d-b

destructuring-bind wrote:The problem turned out to be silent failure to load the dll due to an outdated libtiff.dll I was using.

I still need either a) some documentation or b) some extensions to the GFL plugin api. Here is the problem:

Our lab generates copious numbers of TIFF images in single-channel, 16bit signed integer or 32bit floating point formats. The actual signal may lie in any small range though usually centered around zero. I would like gfl and xnview to be aware that I can supply (at least) 16bit per channel so that the contrast and brightness adjust operations can actually be used. Otherwise I have to prescale the data before I give it to gfl/xnview squashed into just 8 bits and just hope the range is ok.

GFL appears to support 1-channel, 16-bit greyscale images internally, but the plugin API example in the Plugins SDK does not. What can I do to fix this?

Yes, GFL support 16bits but plugin SDK doesn't support it yet.

Another problem is that my xnview thinks it knows how to open my original tiff files, but fails to do so in a useful way. How do I override the default tiff loader to have it try my plugin first?

Currently not possible to override default tiff loader.

Ok, how can I help get these implemented?

d-b

destructuring-bind wrote:Ok, how can I help get these implemented?

Perhaps it would be better to contact me viw email

Pierre-

I sent you an email about this at <removed> last week but I'm not sure you saw it. If there is a better way to contact you please let me know.

Thanks

Daniel

<Mail address has been removed by moderator - please see Rules and Guidelines>

destructuring-bind wrote:Pierre-

I sent you an email about this at <removed> last week but I'm not sure you saw it. If there is a better way to contact you please let me know.

I have it, but currently a little busy...