Cocoa port of PFSTMO

[Jon Brisbin]

Just wondering how difficult it would be to strip out only the parts of the pfstmo package that relate to the tonemapping implementations and provide a Cocoa port of them for OS X?

I've been looking through the code and although there is a heavy dependence on the array2d stuff, I can't see any major reason beyond sheer effort and willpower that these tonemapping algorithms couldn't be ported to Cocoa and used with CoreImage and the other fantastic tools Apple has given us for the Mac.

If there were a Cocoa framework of PFSTMO I could see a killer HDR app in the making! :)

If I were to start hacking on this, where would be a good place to start? Is there a simple algorithm it would make sense to start with?

Thanks!

Jon Brisbin

http://jbrisbin.com/

[rafm]

Hi Jon,

On Sep 4, 10:29 am, Jon Brisbin <jon.bris...@gmail.com> wrote:
> Just wondering how difficult it would be to strip out only the parts
> of the pfstmo package that relate to the tonemapping implementations
> and provide a Cocoa port of them for OS X?

pfstmo is half-way through transforming it into a library, which then
could be directly used in any software. For example, all tone-mapping
operators are internally in dependent from pfstools or pfslib.
Unfortunately Julian, who was working on that, has not managed to
finish his work. See also the other thread:

http://groups.google.com/group/pfstools/browse_thread/thread/4794cd064f5fd18e?hl=en

I am not familiar with Cocoa but I do not see any reason why you
cannot recompile software in any framework you want (as long as it can
compile C++).

But you also do not want to port the code each time a tone-mapper is
improved of bugs are fixed in pfstmo. Thus starting with a library
that could be general enough to be used in many applications makes
more sense to me.

Rafal

[Jon Brisbin]

This would be awesome to have all around. I'd like to see if it's feasible, though, to port the code to an OS X 10.6 Framework that utilizes the new parallelization features of Snow Leopard like OpenCL and Grand Central Dispatch. To use this, the code would have to allow for processing only slices of the image, rather than operating on the entire image in every operation.

I haven't make a full review of all the tonemappers yet, but I also wonder if it would be possible to implement part of the code as a CoreImage filter. Not all of the code could work that way, but some of it could, depending on the operator.

I'm not sure changes like these could easily be incorporated into a library. As a first start, though, I'd like to be able to pull out the important code and put it into a Cocoa framework. Is there a summary of what the code does somewhere? I'm not an academic, so the papers discussing the theory was over my head for the most part. I'd like to be able to come up with an interface/implementation design for tonemap operators that would make object-oriented sense. My idea was to have an AbstractTonemapOperator that each type could implement, with a little glue code for communication. 

jb

[rafm]

Hi,

On Sep 5, 4:19 pm, Jon Brisbin <jon.bris...@gmail.com> wrote:
> This would be awesome to have all around. I'd like to see if it's  
> feasible, though, to port the code to an OS X 10.6 Framework that  
> utilizes the new parallelization features of Snow Leopard like OpenCL  
> and Grand Central Dispatch. To use this, the code would have to allow  
> for processing only slices of the image, rather than operating on the  
> entire image in every operation.

I am afraid that is not going to work that well. Tiling is not
possible for the slower tmos, as their need to operate on the entire
image (e.g. mantiuk06, fattal02, durand02). Tiling could be possible
for simpler, or global tmos, but these are probably fast enough.

> I haven't make a full review of all the tonemappers yet, but I also  
> wonder if it would be possible to implement part of the code as a  
> CoreImage filter. Not all of the code could work that way, but some of  
> it could, depending on the operator.

You can always do it in your code (as long as you keep the GPL
license), but the code will not be portable anymore. I am always
reluctant to lock my code into one platform.

OpenCL is actually the best choice for performance improvements as it
can potentially give substantial gains and is cross-platform.

> I'm not sure changes like these could easily be incorporated into a  
> library. As a first start, though, I'd like to be able to pull out the  
> important code and put it into a Cocoa framework. Is there a summary  
> of what the code does somewhere?

You usually want to wrap exiting functions into classes / objects of
your framework, you do not want to change / rewrite code if it is not
necessary. Check documentation in *.h files for each tmo. It should be
sufficient to write your own wrapper if you need it.

Rafal