Thanks qole, I was shocked when I saw a moderator take the time and make a lengthy reply to my thread. I know you guys have enough to do, and I appreciate that. To address some of your points at length:

Yes this is a bug. It can be missing a few (1-10)verticle lines on the left side. I noticed that it only happens to landscape images with certain dimensions. The fitting algorithm seems to fail with landscape images that are between 4:3 and 1:1, "widescreen" 16:9 shots seem to fit without cropping, please post a full-resolution image (or at least the numeric resolution) that you're specifically having problems with and I'll try to see what it "breaks"

This is a architecture issue. I'll describe it here in a bit of detail so other's can see what is happening as well, sort of a code review.

I have three objects in memory that we'll call state, curPhoto and undoList and two objects in the GUI let's call them GUI.FullPhoto and GUI.Thumb.

The Last two match to what you'd think they are, but the GUI.FullPhoto is actually the full photo 5Meg Resolution scaled in Qt to fit the screen for display only, whereas the GUI.Thumb is pixel-for-pixel displayed in the editor (approx 35K, 250x? or ?x250 in order to fit landscape or portrait here lies the issue above described in point 1.).

state has in it the values that you have set in the GUI such as the location of the current photo on disk, the values of all the sliders, the selected BW conversion, orientation of the photo, etc.

curPhoto has the pixmap of the current-real-image curPhoto.Full, a thumbnail of the pixmap of the current-real-image curPhoto.Thumb, and the appropriate sizes and location of each for display in the GUI as GUI.Thumb and GUI.Full.

undoList is an ordered dictionary of curPhoto objects.

When you first select a photo from the photoBrowser a curPhoto is created and undoList[0] is populated with this object. state is reset to default (or 0) values and and the Entire GUI is updated with that state information.
(This will allow for future filters to be created and saved by the user, or as you mentioned: Warmify, might be an increase in Brightness+3, Red+3, Blue-1, Sharpness-2)

as you interact with the GUI, say by changing the Brightness slider to +1, the state object gets updated, in this case state.bright =1. This triggers an signal to regenerate the GUI.Thumb, specifically for Brightness. It'll take curPhoto.Thumbnail apply a brightness multiplier of 10% and display the results in GUI.Thumb which is a relatively fast process. (~0.1sec)
and the user can see what the change would achieve.

When the user clicks Apply, GUI.Full needs to be updated, state is passed to the appropriate filter routine based on the currently selected tab, and any non-zero changes available in that tab are applied (i.e. Brightness+1 & Contrast+4) to curPhoto.Full and saved to a new curPhoto, this curPhoto is then stored in undoList[1], The GUI.Full/Thumb are updated as described above.

Note: Undo uses the undoList[] by repopulating curPhoto back to the selected undo state.

So as the current architecture stands, If you modify the Contrast slider and then Brightness, it does not re-gen the GUI.Thumb with information on Contrast. So, if you Apply a Contrast change then Apply a Brightness change, the GUI.Full/Thumb will be updated correctly.

But as you mentioned if you change Contrast, and Change Brightness the GUI.Thumb will show the Brightness change only, But when you click, Apply it will apply all changes present in that tab (namely Both Brightness and Contrast) updating the GUI.Full and GUI.Thumb as expected.

I think that there needs to be a bit of an architecture change on my side to rectify this. Thought the outstanding problem is that settings like Brightness and Contrast are not commutative. Brightness->then->Contrast will create a final image that is different than a Contrast->then->Brightness filter.

It works before you adjust the image, afterwards, it seems that the histogram data is appended to the current values, but overflows the chart, thus you see no data and no changes. I'll look into it.
Hey, that's a great idea! Not sure how to implement that in a filter, but it seems like a fun math problem to attack.
This is what the S, M, L, buttons would do, once they are implemented.
I agree. I used Picasa and Gimp, while developing to get some of my ideas. I'd like this application to be closer to Picasa then to Photoshop. Simple tools, simple fixes, with a "bit" of user control; but not to the extent that gimp/Photoshop provides.

Thanks again for your comments and thoughts.