The final has been graded. I may not be able to post a key before Christmas.

Scores ranged from 43-119 (out of 130). The mean was 80, the median was 81.

We curved to a B average, such that 27 out of the 45 people got a B or better for the exam.

Final grades were given such that the class mean was 3.38. The median was an AB (of 45 people, we gave 11 As and 16 ABs, which is a lot for an undergrad class).

Specific details will be sent to individuals, although I might not get to do it before Christmas.

Happy holidays.

As mentioned in class: The final WILL BE CUMMULATIVE. The end of the class built on the beginning, so it really has to be.

We will send out unofficial exam scores and final grades to you CS email accounts a few days after the exam.

The games class will be held in B240 at 1:00 Thursday. Some computers will be free, but you may have to move off the one you're using. And you'll probably find it distracting. But if you need to, you can still work in there.

The writeup is due when you demo. Bring a hard copy of your writeup, and also hand in the .txt file to your handin folder. This has changed, you don't need to hand it in by Tuesday, but you should be thinking about it.

Your project itself is due at your demo timeslot. Handin .cpp, and .h, .vcproj files to your handin directory. Hand in texture files. Handin everything we'll need if we run your program later.

Hand in 3 still shots from your town (by the day of your demo). Follow the naming guidelines given.

If you don't have a demo time yet, go sign up, outside the graphics lab.

The exam for 559 will be Wednesday, December 17 at 7:45 AM (yes, that's really early) in 1221 CS. (at least its not in some hard to find place).

I am not happy about the dawn exam time, but its set by the university, not by me.

Project 3 will not be due this week.

The writeup (as a web page) will be due on Tuesday, December 9th, before class. Details will be available on Tuesday, December 2nd.

Your project itself will be due at your demo timeslot. Students who turned their earlier projects in on time will be given the first opportunities to sign up for demos. The demos will be from the 9th to the 12th.

In order to use the texture manager, you need to add some includes to Texture.H and Texture.cpp. I didn't need these for my project since I had them in the precompiled headers.

A version of the 3DGL demo with texures is in p:/course/cs559-gleicher/public/GL3D.

The things to add to Texture.h (do this BEFORE the line "class Texture"): @@ #ifndef __gl_h_ #include <windows.h> #include <GL/gl.h> #endif @@

The things to add to Texture.cpp (the "Texture.H" is already there, some lines go before, some lines after): @@ #include <stdlib.h> #include <stdio.h> #include "Texture.H" #include "libtarga.h" #include <GL/glu.h> @@

I know that several people are having problems with using the texture manager in their own code. I am trying to figure this out, but have not been able to reproduce the problem (yet). I will put together something this afternoon (after class).

Sorry for the frustration this has been causing people.

a student wrote:

> If we start with your project,I know we have to do X number of things to
> make it better. If we start from scratch, is there a lower expectation of
> getting things to be really good? Also, when starting from scratch, does
> that mean that we cannot use any of your code, or can we use ideas of how
> you structure things to set up our world?
>
> Thanks,

i don't think its a black and white decision.

some things are obvious - for example, if you use my camera code, and your camera interface is no better than mine, its hard to say that you learned anything about making a camera UI, which is what I care about

if you refer to my code for ideas, but then design and implement things yourself, you get the best of both worlds: the experience of trying to understand someone else's code and the experience of having to design and implement this project.

Some people have had problems building the Graphics Town Example for project 3. (you don't need to build it, since the executable is now online).

You will probably notice that the files GraphicsTownUI.H and GraphicsTownUI.cxx are not in the ZIP archive. These files are created automatically using FlTk's automatic user interface construction tool, FLUID. The fluid file (GraphicsTownUI.fl) is "compiled" into the .H and .cxx files.

The Visual Studio project is set up to automatically run fluid to compile the interface. It has a hard-coded path to the compiler, which might be wrong.

If you use my code as a starting point for your own project, you will probably want to understand how to use fluid so you can add to the interface.

You do not need to turn in assignments 9 and 10.

For assignment 9, texture mapping, you merely need to turn in Project 3 (which includes texture mapping).

For assignment 10, which asks you to think about compositing, we'll make sure that you do the work by asking you questions about compositing on the exam.

We will be passing back exams, collecting homework, and having demo sign ups.

If you do not come to class, you can turn in your homework to my mail box before 7:00 pm on Tuesday. Mail boxes are on the fifth floor, same building class is in, outside the adminstation's offices. My box is labeled "Irene Ong / Elizabeth Osten".

The demo signup sheets will be posted outside the graphics lab after class, where they were last time.

If you're interested in coming to the talk tomorrow (given by myself and Prof. Garet Lahvis of Surgery) here are the details. We are looking for people to work on this project, so if you're interested in getting involved in graphics research, this is a good way to find out about one of the things we do.

Computation and Informatics in Biology and Medicine

Michael L. Gleicher, Ph.D. and Garet P. Lahvis, Ph.D.

Imaging and Visualizing Micro-Vascular Architectures

Tuesday, November 11th
4:00 p.m.
Genetics/Biotechnology Center Auditorium
425 Henry Mall

Its linked to the calendar and to the written assignments page.

It was pointed out to me that there was no late policy posted.

Last year, the official stated policy was "at most 1/2 letter grade per day." To be honest, I never charged people that much. I would say that again as an upper bound on the penalty.

(by 1/2 letter grade I mean that an A becomes and AB)

To pick something more specific: if you do not have a grace period (e.g. you turned in P1 late), the penalty will be 1/2 a letter grade for the first day, 1/2 letter grade for the next 2 (e.g. Friday at 5pm is 1 letter grade off), and another 1/2 per weekend day.

If you do have the grace period, its 1/2 grade per weekend day.

All deadlines will be at 5pm EXCEPT the day of class (when things are due before class)

You may notice some changes to the calendar.

On Tuesday (the 4th), I will talk about subdivision surfaces. Its OK if you do the readings after class rather than before. (the readings are the parts of Shirley Chapter 13 that you haven't read yet, as well as an online article from Game Developer magazine).

On Thursday (the 6th) we'll talk about texture mapping. The main reading is Shirley Chapter 10. I'm also going to put a chapter from a different book on the web (haven't done it yet) that will be optional.

Next Tuesday (the 11th), I will be giving a talk about our work on visualizing blood vessels in a mouse brain. (this is the project that Liz works on when she's not a TA). The talk may be of interest to graphics students, but is optional for class.

Class next Tuesday (the 11th) will be short and optional.

A student wrote:
> Can I get a hint on the proper way to make parallel rails? I have tried
> every which way to sunday and had no luck.

the "proper" way is actually kindof tricky, since there are some catches in getting it exactly right.

the easiest way i know: define a coorinate system at every point along the curve. one of the directions will be "right" (as opposed to "forward" and "up") - you need this frame to draw the train anyway

from the point on the curve, move a little bit to the right to find the corresponding point on the "right rail" and a little bit to the left to get the "left rail".

this actually has problems (for example, the rails will cross if the curve makes a sharp enough turn), but should work well enough in practice.

to work up to this, i'd recommend making sure you have a consistent coordinate frame at every point along the track (important to get your train oriented correctly). then try drawing railroad ties (which get the track position right), then try making sure the railroad ties are evenly spaced (which requites arc-length parameterization). after that, it should be easy to connect the end of the rail ties to make parallel tracks.

We were quite happy with how well people did, and assigned grades accordingly.

More than 25% of the class got As. 90% got a B or better. The average grade was 3.35, and the median was a 3.5.

You should have gotten a cryptic email message with your P1 grade. Sorry for the bad formatting (shell scripting problem)

To interpret it...

Somewhere (after your name) is says "letter grade,N" where N is a number between 0-4 (4 is an A, 3 is a B, ...).

At the end, there is a number that is your "score" - this is a number between 29 and 70

The other things are various things we checked, and the various points (approximately):
(0-8 pts)
Makes Black and White 2
Thresholding 4
Leaking Floyd Steinberg 5
Ordered Dither 6
Working FS 10

on halving: (0-6 pts)
no filter 2
average or simple filter (or wrong filter) 4
correct filter 6

on doubling (0-4 pts)
pixel doubling 2
interpolation 4

(0-2)
larger scales up 2

(0-4)
larger sc2ales down - fixed filter 2
variable sized average 4
good filtering on larger scales down 6

(0-6) arbitrary or non-uniform
arbitrary scaling (non-integer) or NU 2
area filtering 4
correct 6


. (0-8pts)
something painted 2
fixed brush 4
automatic 5
variable brush 6
something more interesting 10

4. (0-10 pts)
does something 4
correctly finds red 6
dims 8
fancier 10

5. (0-6 pts)
readable code 2
could identify filter 4
extra nice code 6

(penalties)
code attribution -4
no readme -5


6. (0-8pts)
Q1
Q2
Q3
Q4

7. UI Bonus 2pts

I checked all of these homeworks. I sent an email to everyone who got credit for it, to your cs account. If you turned it in but didn't get an email, let me (Liz) know.

We will accept late projects until Sunday, November 9 at 5pm.

There will be a 74 1/2 hour grace period for handing in assignments. That is, if you turn in your project before Friday, November 7 at 5pm there will be no penalty, providing that you turned in project 1 on time.

Also, lots of students have been curious about grading. I added a comment in the project. Generally, to get an A you must have most/all of the advanced features.

A student pointed out that the periodic cubic B-Spline matrix in my notes is "backwards." (the order of the rows and columns are reversed - it assumes that the U vector is [u^3 u^2 u 1] rather than [1 u u^2 u^3].

This maybe be an issue for you if you try to make a B-Spline train track.

Let me (Liz) know if you didn't get an email telling you whether or not you got credit for programming assignments 3 and/or 4.

The link to the curves notes should now be not broken. So, if you didn't get a copy in class you can get the pdf from the navigation bar to the left.

The signup sheet is posted on door 1346 outside the graphics lab.

If you can't find 1346: Stand outside the class room, 1325, have the photo board on your right. Walk straight, past the UPL, and the graphics lab is on your right.

I have posted the "GL Survivial Kit" (look at the navigation bar on the left) and Programming Assignments 3 and 4 (look at the assignments page).

The debug preprocessor definition should be 'WIN32;_DEBUG;_CONSOLE;FL_DLL' and the release one should be 'WIN32;NDEBUG;_CONSOLE;FL_DLL.'

The problem is with how the tutorial instructs you to create the project files. When you set anything using 'All Configurations', it overrides any configurations that were originally different between the two configurations, (eg Preprocessor). Setting FL_DLL overrides the WIN32 preprocessor definition (because NDEBUG/_DEBUG differ).

The previously posted fix for this problem puts $(FLTKHOME)/FL in the include path, which means you can't use any standard libraries that have the same names as anything in there (math.h for example).

I hesitate to tell people about these because they are filled with wrong information, and common misconceptions. However, you might find them useful in understanding how to use filters. Beware though, they misuse a lot of terminology.

A Student wrote:
> After class today you said if I emailed you links to what I found online you
> would post it on the webpage. I don't know how relevant you think they are
> so you can decide if you want to post them, but I found them useful in
> connecting the kind of abstract idea of filters to actual code.
>
> http://www.gamedev.net/reference/programming/features/edf/default.asp
> http://www.gamedev.net/reference/programming/features/imagefil/

As the deadline grows near, I hesitate to give too many hints because its kindof unfair to those who started early. However, since we are getting lots of questions, here are a few hints:

Even though the assignment doesn't ask you to implement convolution/filtering/blurring, i recommend that you do it first - its a good intermediate step towards some of the bigger pieces.

The spike chain + reconstruction filter approach in my notes isn't the only way to scale up an image. You can actually peform the interpolation on each pixel.

Interpolating in one dimension then in the other works for linear interpolation (at least). Please don't ask me to prove why.

You might want to experiment a little to decide what filters work best for scaling down an image by varying factors.

A student asked...
> Are we going to be showing the testing of our project on large
> images? In other words, do I need to put scroll bars on the
> windows holding the images so that if the image is really big
> (bigger than say half the screen), the main window stays the
> size of the screen and the image window has a scroll bar?

don't worry about displaying really big images - implementing scroll bars for images is a pain (i know - i've done it), and not very instructive.

in fact, displaying the images isn't really that important (except if your program requires user interaction). it is crucial that you write out images (so we can look at them in photoshop). if your program displays images, that's helpful, but its not part of your grade.

the safest thing is to make sure your program doesn't crash on an image that's too big. maybe if an image is too big to draw, give an error message and allow the user to write it out so they can view it in photoshop.

mg

There are some sample targa images with red eyes for you to reduce in p:/course/cs559-gleicher/public/SampleData/RedEyes.

A student asked...
> When you grade project 1 are you going to take into account how
> compact the code is, or how fast it takes, or how well we know c++?
> asssume the code is well documentated. I was just wondering...

good question...

short answer: no
long answer: indirectly.

• what's more important (especially on this project) is that your program works correctly
• if you write bad code, you will have a hard time getting it to work reliably and test it. you will spend more time getting bad code to work than it would take to write good code.
• efficiency doesn't matter within reason. if it takes a few seconds to process a small image, that's ok. if it takes several minutes to process a small image, then you have a problem. of course, if your program is that slow, you won't be able to test it thoroughly, and you'll spend a lot of time waiting for it.
• on using C++ - clearly, you need to use C++ well enough to make sure your program compiles and runs. we will not care if you use fancy c++ features (in fact, i don't recommend it). we won't even check to see if your program leaks memory or stuff like that. again, its to your best interest to not have silly programming problems since its harder to make the program work with these issues.
• when we "read" your code, our checklist will have things like "can we identify where in the code you do X and what algorithm you used for it."
• occassional crashes are a form of not really working

Because our eyes are more sensitive to green, an equally bright green, blue, and red will not appear equally bright. This means that if you are converting between color and grayscale, the color red (255,0,0) should not turn into the same brightness as the color green (0,255,0).

The exact ratios vary. One simple one is to say that green is twice as sensitive as red is twice as sensitive as blue, which gives the rations for R,G,B as 2/7, 4/7, 1/7, or .28, .57, .14. I have also seen systems that use r = 0.212671, g = 0.715160, b = 0.072169.

The closest thing to an "official" standard is what is used in NTSC (the North American video standard) to compute brightness from colors. That's: Y = 0.30R + 0.59G + 0.11B.

There were some changes made to written assignment 2.

There is one question that was poorly worded, and another question that you should just skip.

(this actually only got put on the web Wednesday morning at 11:15am - sorry!)

Project 1 has been added to the website. Look at the navigation bar to the left!

As I mentioned the first week, in the past we've had "extra meetings" of 559 to discuss material that is beyond what we can talk about in class.

We'll have one of these on Monday, September 29th at 4pm. Tentatively scheduled for 1325 CS. The topic will be painterly rendering. The required reading will be a paper or two on the subject. For this meeting, a graphics graduate student will lead the discussion.

This week, the topic of discussion will be painterly rendering (to help you do something cool for Project 1). There are two papers to read in /afs/cs.wisc.edu/p/course/cs559-gleicher/public/ExtraReader

There's a nasty bug in ZoomerWindow that will cause your program to crash after you do a save. Finding it is actually good practice in trying to understand why its important to make some software engineering decisions correctly, especially dealing with shared data.

The problem is that the "writeTarga" method of TargaWindow uses reverseRows, which is destructive (it moves the image data to a new place). This would be OK, since the TargaWindow is updated appropriately. However, since the Zoomer Window keeps a pointer to the data, this pointer will be dangling after the TargaWindow gets updated.

I have fixed the bug (albeit in a non-elegant way), and put a warning into the header file.

There are various fixes for this. The easiest is to change the standard include directories to be $(FLTKHOME);$(FLTKHOME)/FL;

filename.h does a #include "dirent.h" and it can't find that in the include directory list.

We just looked over the second written assignment and decided to make question 1 easier. If you've already printed it out, you should do so again. Sorry for the inconvenience!

The second written homework assignment (imaging math) has been posted. This assignment is good practice for doing the project.

Someone found a bug (thanks!) - it's been fixed.

The link to the web page about the reader was broken. It's fixed now

I tend to describe things by the author, so "Foley and van Dam" is the Chapter in the Reader entitled "Achromatic and Chromatic" light.

On thursday, we'll talk about sampling some more, talk about quantization, dithering, and error diffusion, and hopefully get to color systems.

I just put up a new demo FlTk/LibTarga program. (there's links from the web page). It's a slightly more interesting demo. Understanding it may help you make a better Project 1 (which is coming soon)

I will not have my office hour on September 16th. Trust me, what I will be doing is even less fun than office hours.

You make have noticed some wierdness with LibTarga on the CS559 website. I think it all has been corrected.

It seems that the version of FlTk built for the CSL machines does not have JPEG support. You won't need it. But if you think you want it, beware, since its not there

If you want to read/write images, you should look at libtarga. Actually, you will want to read images soon (libtarga is part of next weeks programming assignment.)

(hint - if you can't find libtarga, look to the left of this window)

Some of you may have had a problem linking your program with fltk. The symptom will be a cryptic error message involved a "public static" such as:
LNK2001: unresolved external symbol "public: static int Fl::e_keysym" (?e_keysym@Fl@@2HA)

The problem is that we forgot to tell you in the tutorial to define the symbol FL_DLL. I will update the tutorial now, but the fix is to add the symbol FL_DLL to your "Preprocessor Definitions" on the C++/Preprocessor tab of the Property pages of your project.

The original version of the tutorial did not tell you to add FlTk to your PATH environment variable. This is important in order to get your program to run. The tutorial has been updated.

As we mentioned in Monday's announcement, the CSL is having problems getting the Visual Studio compiler to work. We do not know when the problem will be corrected.

The problem seems to arrise from an attempt to put debugging information onto AFS.

The workaround for this problem is to do all of the work from the local disk of the machine (e.g. put your files into C:/TEMP or on the desktop).

Working on the local disk is preferable because it is much faster than accessing files over the network. However, do not forget to copy your files back to your home directory - Files you leave on the machine will be cleaned out when you log off.

There will be a session to go over the FLTK tutorial in B240 on Thursday, 9/11, at 4:00, after class.

The CSL will not have the computers in B240 properly configured to use FLTK until Wednesday or Thursday this week. This assignment is not due until Tuesday, 9/16. Liz (the TA) will also be down in B240 on Monday 9/15 11:00-12:00.

Someone has pointed out that on question 4, in the degenerate case (when the vectors are co-linear, or one or more of them is zero), this problem is much more difficult.

You may assume that the two vectors in question 4 are not co-linear, and that they both have non-zero magnitude.

I am putting papers that you might be interested in in the afs directory /p/course/cs559-gleicher/public/Readings.

Today, I put two additional papers about human vision (one is specifically about the psychology of watching movies). These are what I'm reading to prepare for lectures. Of course, these readings are optional, but in case you are interested I'll make them available

Some of the course reader papers will be available in this directory as well. Please do not print the files - it is actually more economical for you to buy the reader from DOIT (somebody actually pays for the printing we do on the department printers). I am putting the files there only if you are interested in saving a tree or two.