So far I've written a program that reads IGI files...
...though it doesn't do anything with the data yet.
Any Java programmers here?
thats certainly odd... i see, it just seems to apply to the == operator though, the others work (the == operator seems to work that way for every primitive Object type) <= and >= still seem to work as expected though. this goes against everything my teacher just taught us about java.
a shiny monkey is a happy monkey
@oodmb (your name + dyslexia = hard to spell)
thats because he didnt teach you what those operators are doing! Since java dosent support overloading operators (the one thing i realy wish it did, but usualy inst a problem) all operators do the same thing. int stores a value, so it works fine. Integer and String store locations of data, not actual values, so your comparing arbitrary numbers. When you say String A = "bob", and then say A = "bob" + ""; you create a new string object with a new location, which is why my previous example creates a false "false". You also can run into bugs with >= and such with strings, instead you should use compareTo() method. (Java 1.5+ you can do Integer == or >= becasue of autoboxing though).
@dougal2
heh, reading is always the easier part ;p
hint: when reading files use a class called StringBuffer, otherwise you get a lot of overhead.
thats because he didnt teach you what those operators are doing! Since java dosent support overloading operators (the one thing i realy wish it did, but usualy inst a problem) all operators do the same thing. int stores a value, so it works fine. Integer and String store locations of data, not actual values, so your comparing arbitrary numbers. When you say String A = "bob", and then say A = "bob" + ""; you create a new string object with a new location, which is why my previous example creates a false "false". You also can run into bugs with >= and such with strings, instead you should use compareTo() method. (Java 1.5+ you can do Integer == or >= becasue of autoboxing though).
@dougal2
heh, reading is always the easier part ;p
hint: when reading files use a class called StringBuffer, otherwise you get a lot of overhead.
Yes i know, my spelling sucks
eman: I'm using ByteBuffer because of the necessary endian-ness conversion.
Code: Select all
data_in = DataInputStream( new FileInputStream ( myFile ) );
byte[] bArr = new byte[4];
data_in.readFully( bArr );
myInt = ByteBuffer.wrap ( bArr ).order ( ByteBuffer.LITTLE_ENDIAN ).getInt();
My primary goal is to learn Java.
Second to that, I want to understand a bit better some of the algorithms used in tonemapping and filtering. (I already know a bit about 1-dimensional convolution theory from studying DSP, but have very little practical knowledge of how to apply this thoery - and no experience in doing 2D processing)
Violet seems like a useful launchpad to get me started, as all the c++ source is available, works and is fairly easy to read.
If I can get jViolet to a state where it does the same as the existing Violet, and test it on other platforms, perhaps it'll be useful too to the community here. Everyone wil have gained something
Second to that, I want to understand a bit better some of the algorithms used in tonemapping and filtering. (I already know a bit about 1-dimensional convolution theory from studying DSP, but have very little practical knowledge of how to apply this thoery - and no experience in doing 2D processing)
Violet seems like a useful launchpad to get me started, as all the c++ source is available, works and is fairly easy to read.
If I can get jViolet to a state where it does the same as the existing Violet, and test it on other platforms, perhaps it'll be useful too to the community here. Everyone wil have gained something
OK, so today I have managed to implement (erm, copy from c++ ) XYZ->RGB conversion with whitepoint settings, Linear tonemapping (buggy) and Reinhard tonemapping.
There's something wrong with my Lienar tonemapping though because my image is brighter than it should be.
) XYZ->RGB conversion with whitepoint settings, Linear tonemapping (buggy) and Reinhard tonemapping.There's something wrong with my Lienar tonemapping though because my image is brighter than it should be.
- Attachments
-
- jViolet Linear tonemapping
- jV - linear(-0.5, 1.2).png (509.09 KiB) Viewed 3714 times
-
- C++ Violet Reinhard tonemapping
- cV - reinh(-1.0,1.0,4.5).png (412.9 KiB) Viewed 3714 times
-
- jViolet Reinhard tonemapping
- jV - reinh(-1.0,1.0,4.5).png (545.17 KiB) Viewed 3714 times
-
- C++ Violet, Linear tonemapping
- cV - linear(-0.5, 1.2).png (338.27 KiB) Viewed 3715 times
I have a UI that shows the image in a scrollPanel, and a single button to fire off my methods.
All the controls for the linear and reinhard could be built to make those functions useable. Figuring out file choosers would then make the app useable.
The basic gaussian/median etc filtering should be fairly straightforward... the diffraction limited bloom stuff I'm not sure about yet, as I don't really know how it works.
All the controls for the linear and reinhard could be built to make those functions useable. Figuring out file choosers would then make the app useable.
The basic gaussian/median etc filtering should be fairly straightforward... the diffraction limited bloom stuff I'm not sure about yet, as I don't really know how it works.
Cool project idea Dougal
Most of the advice you've been given is great. Watch out for the String == thing... the reason that...
... works is because the Java compiler recognises the string literals are the same and re-uses the same object again. Use string1.equals(string2) to be sure. Be aware that Strings use TONS of memory (24 bytes before you even put anything in it) so think about using char[] instead where you can.
I'd advise buying a book on Java... seems like a silly outlay but they're usually a good thing to read for 30 mins before beddy-byes every night and quicker than Google for reference purposes most of the time.
For what you're doing, it's not so much of a consideration but, in general, Java memory usage sucks so beware of creating objects all the time, especially if you care about performance. Modern JVMs do a cracking job of escape analysis (determining that an object is only used within a single method call and binning it immediately, saving the garbage collector loads of time) but still... if you can re-use objects, do it. Many Java evangelists claim that the garbage collector is soooo good, but in some cases, it's a pain.
On this note... Java 1.5+ does auto-boxing for you (converting Integer to int) but that will result in object creation. Try to stick to primitives where possible. If you want a list of ints and are forced to use Integer in the Collections classes, try writing your own version that uses the primitive.
If you think of a useful class and find yourself thinking "hey, that's a cool, generic utility type thing" then check to see if it already exists in the standard libraries. You'll be surprised how much is in there and how easy it can make your job (but DO check the library's source code to make sure it's not a performance hog... if it is, subclass it).
Use static inner classes for simple, class-local things... it'll avoid code clutter. Be aware that non-static inner classes use more memory than static ones.
Avoid synchronization unless you know for a fact you need it. It's amazing how much can be achieved through use of the members of the
java.util.concurrent package (e.g. AtomicInteger), especially for keeping counters that are accessed by multiple threads.
Learn how to hand-code Swing... it's the best thing about Java
Reflection is also one of the best things about Java. It's worth learning and isn't as slow (for most things) as many people say.
Get your code working before optimising too much. I know this is a general saying for most languages but the JVM is soooo clever nowadays that sometimes premature optimisation makes your programs run slower rather than faster.
Always, always use the -server option when running java.exe. It can double performance for maths-intensive apps, sometimes more. Recent JVMs detect whether your box has 2Gb+ and 2+ cores and will use -server automatically but bung it on the command line just to be sure. I've found BEA JRockit is the fastest JVM for maths-heavy stuff but it might very well be architecture/configuration dependent.
That was all just a brain dump... there will be loads more, and better qualified wisdom in books on the subject
I personally use Netbeans for my IDE. It's come on a lot since v4.0 but it's very much a preference thing. In particular, the profiler is bloody excellent for finding memory leaks and sussing out performance bottlenecks. Eclipse is also mighty fine.
Ian.
Most of the advice you've been given is great. Watch out for the String == thing... the reason that...
Code: Select all
foo = "hello";
foo2 = "hello";
if (foo == foo2) System.out.println("foo and foo2 are equal");
I'd advise buying a book on Java... seems like a silly outlay but they're usually a good thing to read for 30 mins before beddy-byes every night and quicker than Google for reference purposes most of the time.
For what you're doing, it's not so much of a consideration but, in general, Java memory usage sucks so beware of creating objects all the time, especially if you care about performance. Modern JVMs do a cracking job of escape analysis (determining that an object is only used within a single method call and binning it immediately, saving the garbage collector loads of time) but still... if you can re-use objects, do it. Many Java evangelists claim that the garbage collector is soooo good, but in some cases, it's a pain.
On this note... Java 1.5+ does auto-boxing for you (converting Integer to int) but that will result in object creation. Try to stick to primitives where possible. If you want a list of ints and are forced to use Integer in the Collections classes, try writing your own version that uses the primitive.
If you think of a useful class and find yourself thinking "hey, that's a cool, generic utility type thing" then check to see if it already exists in the standard libraries. You'll be surprised how much is in there and how easy it can make your job (but DO check the library's source code to make sure it's not a performance hog... if it is, subclass it).
Use static inner classes for simple, class-local things... it'll avoid code clutter. Be aware that non-static inner classes use more memory than static ones.
Avoid synchronization unless you know for a fact you need it. It's amazing how much can be achieved through use of the members of the
java.util.concurrent package (e.g. AtomicInteger), especially for keeping counters that are accessed by multiple threads.
Learn how to hand-code Swing... it's the best thing about Java
Reflection is also one of the best things about Java. It's worth learning and isn't as slow (for most things) as many people say.
Get your code working before optimising too much. I know this is a general saying for most languages but the JVM is soooo clever nowadays that sometimes premature optimisation makes your programs run slower rather than faster.
Always, always use the -server option when running java.exe. It can double performance for maths-intensive apps, sometimes more. Recent JVMs detect whether your box has 2Gb+ and 2+ cores and will use -server automatically but bung it on the command line just to be sure. I've found BEA JRockit is the fastest JVM for maths-heavy stuff but it might very well be architecture/configuration dependent.
That was all just a brain dump... there will be loads more, and better qualified wisdom in books on the subject
I personally use Netbeans for my IDE. It's come on a lot since v4.0 but it's very much a preference thing. In particular, the profiler is bloody excellent for finding memory leaks and sussing out performance bottlenecks. Eclipse is also mighty fine.
Ian.
Thanks Ian, some nice tips there.
I've also found the profiler in netbeans to provide some useful info - I'll be working on how to optimise certain routines at some point, but as you say getting it working first is always a good idea
BTW, I've started a thread in the Development forum to keep track of my progress on this project.
I've also found the profiler in netbeans to provide some useful info - I'll be working on how to optimise certain routines at some point, but as you say getting it working first is always a good idea
BTW, I've started a thread in the Development forum to keep track of my progress on this project.
Who is online
Users browsing this forum: No registered users and 80 guests