Porting Violet to Java

[dougal2]

ok solution 2 works
It also had the benefit of moving the thread-check-wait loop out of the XTonemapper subclasses and into the Tonemapper superclass.

[dougal2]

program output, forcing 4 threads:

Code: Select all

Header read OK, starting data read...
pixelData size: 17280000
Image stats:
        Width: 1600
        Height: 900
        Num samples: 3170000
...data read finished
Image loaded
R:\indigo\old_versions\indigo_v09_test4\renders\im1188991340.igi
Resources allocated
Display Image allocated
Starting ImageThread 1/4
ImageThread 1 started
Starting ImageThread 2/4
Starting ImageThread 3/4
ImageThread 2 started
ImageThread 3 started
Starting ImageThread 4/4
Thread #2 waiting for luminance
Thread #2 waiting for luminance
Thread #1 waiting for luminance
ImageThread 4 started
Thread #2 waiting for luminance
Thread #3 waiting for luminance
Thread #2 waiting for luminance
Thread #1 waiting for luminance
Thread #4 calculating final luminance
Thread #3 waiting for luminance
Thread #2 waiting for luminance
Thread #1 waiting for luminance
Updating display image part 4/4...
Updating display image part 2/4...
Updating display image part 1/4...
Updating display image part 3/4...
... update done
ImageThread 4 complete
... update done
ImageThread 2 complete
... update done
ImageThread 3 complete
... update done
ImageThread 1 complete

[eman7613]

you could make life easy and just keep the IndigoImage outside of the GUI alltogether, and give it a method "createBufferedImage". ie:

Code: Select all

//About to regenerate image
SwingUtilities.invokeLater(new Runnable()
         {
                      public void run()
                      {
                              ImageOutput.intermediate();
                      }
         }); 

/** do stuff **/
SwingUtilities.invokeLater(new Runnable()
         {
                      public void run()
                      {
                             ImageOutput.setImage(indigoIm.createBufferedImage());
                      }
         }); 

[dougal2]

I don't follow you eman - is this based on what's written already? or an idea you have? I need an idea of the bigger picture of what you're trying to get across.

[eman7613]

just an idea i had, haven't looked at any of the functioning code (been writing the UI classes).

Basicaly, what im saying is keep all the actual work and logic outside of the UI, so if you read in the igi, you dont put the igi in the viewport for the user to see. Instead you create a copy of the igi and display the copy instead. This way you can go back and calculate luminance at a later point (or anything else) without reducing UI speed. [b/c if you calculate the luminance when you first read in the igi, your going to be waisting the user's time before he ever even sees the image displayed]

IE:

GUI classes ---> start separate thread to run PostProc & get values from GUI api ---> do work --> send an updated copy back to UI and unlock controls.

[dougal2]

ok, i see. This is already happening though to a certain extent. Certainly the main processing thread is entirely separate.
I'll have another look at exactly what I have in the GUI event handlers and try to move as much as I can into more general classes.

[ViennaLinux]

OOP rules the world and the brains here *g*

[dougal2]

I've done a bit of tidying tonight. the GUI events now pretty much defer entirely to methods of IndigoImage for read() and process().

I had a stab at copying over gaussianFilter, but it's producing incorrect results at the minute and Image.addImage() doesn't seem to work.

Also, despite firing off threads and runnables all over the place, the GUI still seems to block when the main ImageThread is active... ? i can't explain that.

I guess we'll both plod forward for now and finish the bits we're doing and then tie it up.

[dougal2]

fixed Image.addImage(); gaussianFilter is now working

[dougal2]

I've finished adding all the image filtering routines. the following all work:
Median filter,
Oog filter,
Chiu filter,
chromatic aberration,
Gaussian bloom,
Glare.

I started to add in the airyDisk functions for Diffraction limited bloom, but I have a feeling it might be better to re-implement this using native Java stuff than to try and copy each of the c++ routines.

Anyway, apart from that and the histogram computation, it's just about as functional as the original.

[Kram1032]

The Airy Disk part is slightly more complex, yeah...
Though, with this already being computed directly in Indigo, even with better results, that might not be needed any more anyway

[dougal2]

slightly more complex

haha, you have no idea.

Most of the filters can be implemented with simple iterations over the image with multiply and add operations. Easy-peasy.

The airy disk stuff requires FFT operations with complex numbers. That's another 2 complete, complicated classes to implement (and somehow test) before I can even start on the diffraction bloom algorithms.

[neepneep]

How about camera tonemapping? Any chance of sticking that in?

Also, are you going to use the same controls to control linear tonemapping (exposure/contrast) and reinhard tonemapping (that weird exponential way) ?

[dougal2]

The controls are the same in this port, because it's, erm, a port; an exact (ish) copy.
I'm doing as much copying as I can so that I can check the results with the c++ version to make sure that the Java code is doing what it ought to.

I agree the exponential type controls are a bit weird, and not the same as the exporter controls in most cases. I'll have a look at the older, standard code I have and see if I can put in an option to switch between the two types.

[neepneep]

Glad to hear, and keep up the good work sir!