I have Been taking the sdk for a spin. The Exposure tonemap example compiles & works perfectly and I've been able to replace the tonemapping code in MExpTmo::onTonemap with other code that works in Picturenaut. Cool!

[b][u]Question 1:[/u][/b]I've been running into problems in getting a dll file of my own to work with picturenaut. I started out by modifying the MExpTmo project, class & filenames & project properties to generate a different dll file.

However, it simply doesn't show up in Picturenaut Tonemapper's list. To trace what's happening, I added a bunch of printfs that show the function names in the plugin-class functions & captured what it wrote to STDOUT by re-directing to a text file

Here's the output i got in the sequence of functions as my DLL file loaded up in Picturenaut-

[b][u]Question 2:[/u] [/b]In the plugin code, I found a static global tonemapping plugin object called expTmoPlugIn getting created that doesn't seem to be referred to anywhere else in the code.Could you tell me what role does this object play & could it be related in any way to not being able to load a different dll? Here's the code...[code]static MExpTmoPlugIn expTmoPlugIn;[/code]

[b][u]Question 3:[/u][/b]In the poster, it's mentioned that "unless specified" picturenaut serves imagebuffers in tiles to enable multithreaded operation. Is there a way to turn this off & get the full image at a go?

[b][u]Potential addition to Documentatio[/u]n[/b]While compiling my dll, i found that the MExpTmo by default has the exported functions at these ordinals while mine didn't for some reason.

Specifying it in the def file like this seemed to solve the problem of having the functions at the right ordinals.[code] getPlugInHandles @1 getPlugInClass @3 getPlugInVersion @2[/code]

[b][u]Tonemap dialog feature request:[/u] [/b]It would be great to have a way for a tonemap plugin to specify default settings for things like "Automatic lum", "Automatic contrast" and "Gamma" that work best for the plugin. This would give a good "initial" picture to the user who could change it as he wants. I've seen this affect the "initial" picture from some of the existing plugins as well

1. The class name, for example 'PNExpTMO', is a unique name for a tonemap plug-in. If you build your own plug-in, you must specify a different name. Thats all.

I'll explain later in the SDK documentation the backgrounds.

2. Look in the file 'pnplugin.cpp' and the the 171 of the CTOR. All plug-ins are derived from 'PNPlugIn'. The CTOR connects 'this' to a list of plug-in instances. A plug-in list is local for one DLL. You can also see that it is possible to create multiple plug-ins for one DLL.

3. Yes, you can do it in this way But remember that the multi-core support is practically turned off when the whole image is given as a tile. In addition, support for large images is also disabled. Unless you have a 64-bit version of Picturenaut. But the 64-bit version is not yet there.

I thought I would hijack this thread rather than start a new one, as it already contains some of the information I'm after

I started playing with the tone mapping example last week.

What I am thinking of doing is porting a version of my bilateral filter/contrast enhancement algorithm to picturenaut. This takes HDR tiles as input and produces HDR output.

I'm not interested in tone mapping as such, as the output of the contrast enhancement process is passed to a global TM algorithm and you already have the main ones covered. You get more flexibility by just doing the contrast step.

I guess my question is which class do I derive from? The output of tone mapping plugins seem to be normalised after processing*, but I haven't found where yet.

Any tips, or maybe a general purpose filter example?

*determined by passing out some absurd values and seeing what happened.

You must derive from StandardPlugIn. Then the method 'getPlugInTypeName' must return the string "tonemap" or "filter". Sorry that I haven't any example code for now. The reason is that the actual SDK is too new to bring out many examples that do not work any more in the next SDK version.

For the comming SDK several things have changed. In particular the names of the classes have changed. They don't have any prefixes and there is only one namespace 'pnsdk'. Unicode 16 support was discarded. Because it's a Windows (tm) relict and has a lot of disadvantages I don't want list them all. The new SDK only supports UTF-8 because it is most flexible and most portable. To port existing code to the new SDK, it usually takes only a global name change for the SDK classes. And with the new SDK, there will be more examples.