The Image2d type is not a guaranteed type because the underlying device must support it. Since I like to keep things as open as possible I opted to skip using Image2D in PhotoMonkee’s image filtering system and instead go with using int.

int?

Yeah, like 32 bits of colory goodness. Since Qt currently only supports 32 bit images there’s no need to deal with higher bit rates in the filter infrastructure. The tricky part (and maybe performance reducing part) is converting the integer into its component color parts so that we can modify it.

Let’s dig into an example to break things down. In this sample I’ll be showing you the kernel for image desaturation (i.e. converting to grayscale).

Passing image data to the kernel

As previously mentioned, PhotoMonkee uses Qt for holding image data. We use a combination of QPixmap and QImage, depending on the area. In this case, we’re using QImage for direct pixel access. The OpenCL memory buffer is populated with the contents inside of QImage::bits().

The Kernel

Because we’re working with 32bpp the kernel takes in int * as the source and destination buffer types.

In order to pick out the exact pixel we need from the buffer we simply need the GID which idexes directly to our source and destination pixel. With the GID in hand, we reach into the array and get back our int. One problem, we need RGBA components we can work with.

Enter: the bit shifter! 

This function, and its corresponding reversal function, will convert between the int and int4 data types.

Why not convert from an int into a char4? Some image manipulation operations will blow past the upper bounds (255) or lower bounds(0) of the color range. By using an int we allow for that to occur. Note: it’s up to the kernel to make sure the value gets properly clamped before returning! 

Now that we’ve got our RGBA color components we can modify the values.

Lastly, we convert back from int4 to int and then stash the result in the output buffer.

I’ve done every filter in PhotoMonkee using this method for accessing image data. While I don’t have any performance comparisons to using Image2D I’m happy with the rate at which the filters execute on both GPU and CPU-only accelerated platforms. The only downside I’ve seen from using this methodology is that reading or writing to buffers outside of their range is BAD! It causes all sorts of strange things to happen the most severe of which is watching the GPU driver crash. Not cool.

In summary: I thought this was a pretty cleaver workaround to the problem spotty Image2D support. Do you have a solution that you have used in your implementations? I’d love to hear about it. Drop a comment below or feel free to shoot me an email: admin at this website.

Thanks for reading!

In the latest PhotoMonkee build I cooked up some rulers to serve as a handy reference point when editing items on the canvas. I’m pretty happy with how they turned out. The feature took a little longer than planned due to some struggles with how I wanted to handle zooming. In the end I took a shortcut (violated some OOP “rules”) to quickly bypass the issues I was hitting.

So what do the new rulers look like?

Well, like rulers! In the above picture you’ll see both a horizontal and vertical ruler extending along the edge of the window. A blue hash mark shows the current position of the cursor. I went with the “quarters” type of ruler whereby major hash marks are shown with three quarter hash marks are drawn in between each major.

Scrolling the canvas (when zoomed in far enough to allow for scrolling) will force a redraw of the ruler to update the coordinates as needed. In addition, zooming the canvas will also force an update to the rulers so that they can account for the new scaling that is required.

Future enhancements I’ve got planned for the rulers include:

• Highlighting an area on the ruler when a selection is made via the marquee tool
• Allowing the user to select the unit type used in the ruler
• Allowing the user to turn the ruler on or off (it’s always on right now)
• Creating guides by dragging them “out” of the rulers (not really a ruler feature but it’ll be involved)

The Design

As with any Qt widget, the ruler widget (PMRuler was the class name I used) will be based off of the QWidget class. Rather than break out the horizontal and vertical drawing logic into separate classes I just created an orientation enum and tossed some conditionals into the drawing routines.

Here is the header file for PMRuler

What’s The Timer For?

Rather than have the ruler connect to another widget or have the parent window notify the ruler when the mouse moved I opted for polling the moue using QCursor::pos(). Right now I’ve got it set on a 50 millisecond polling interval.

Widget positioning

I found that by using the QGridLayout in the parent window allowed for easy positioning of the ruler widgets and the QScrollArea (which houses the canvas).

Drawing the Ruler

First rule of drawing rulers: cache drawing the ruler as often as possible. Right now we’re drawing major hash marks, quarter hash marks and numbers on the major hash lines. If we add in eighth or sixteenth hash marks things could get a little more expensive. Even without the other hash types, drawing everything each time the mouse moves (to update the blue mouse position indicator) is a huge waste of resources. We only redraw the ruler to a QPixmap cache when the zoom factor is updated or a scroll bar is dragged.

The painting handler

So what is the actual algorithm to draw the ruler? Well, I break it down into two passes: Drawing from 0 to end of the ruler and 0 to the start of the ruler. Each loop simply calls a function to perform drawing where it’s appropriate. The iMinorInterval variable determines the spacing, in real screen coordinates, for each hash marks. This is currently set to 25 pixels which means every 100 pixels we get a major hash mark. The iHashType variable is simply a counter. Inside DrawHash() we do a “ihashType % 4″ check to see if we’re on a major or minor hash.

The hashLine variable (a QLine object) is the current line we’re drawing. It’s a reference so DrawHash() will actually move the line to the next location for the next iteration (woops, did I just violate another OOP rule?)

Coordinate Conversion

During the initial implementation I tried to pass in the scale factor to the PMRuler object and have it convert from actual pixel coordinate space to canvas coordinate space. After a couple of nights of frustration I just punted. The ghetto hack? Have the PMRuler object ask its parent to convert a coordinate from actual pixel space to canvas coordinate space.

You see, when a horizontal PMRuler draws its first major hash mark it is at (100,0). If the canvas is currently set to 100% zoom then we are ALSO at (100,0) on the canvas. If the canvas is currently zoomed in to 110% then (100,0) is actually (110,0) on the canvas.

To perform the conversion I converted the PMRuler‘s local coordinates to global coordinates using mapToGlobal(). Then I take that global coordinate and map it to the QGraphicsView coordinate system using mapFromGlobal(). Lastly we go from widget space to canvas space by calling mapToScene().

Gotchas

Along the way I hit a couple of issues that took some time to resolve. The first was the failure to re-implement the sizeHint() and minimumSizeHint() functions in the PMRuler class. That means when Qt was trying to figure out the appropriate size for the rulers it would end up calling the default QWidget implementation. Who knows what that said the size should be…it definitely wasn’t right!

Readability of the code was also an issue that I took some time to address. Initially I had two methods in PMRuler to perform the drawing. One method was for drawing “forward” (zero to end of ruler) and the other was “backwards” (zero to the start of ruler). I’m glad I took the time to clean things up because while writing this feature. There are other sections of PhotoMonkee that have very messy code and I’m not looking forward to reacquainting myself with them

Conclusion

I’m pretty happy with how the control turned out. It serves as a great basis for some future enhancements and helps PhotoMonkee look a little more like a “real” image editing program. Granted, breaking away from the traditional mold of image editing wouldn’t be a bad thing.

If there are more features you’d like me to write about please drop a comment below or contact me directly: admin at photomonkee dot you know what! Until next time….stay thirsty my friends.

Back in CS101 (or was it CS201?) I was taught that if you plan on returning a value from a function you do it one place, at the end. 12 years have elapsed since that course and I’ve become a bit ignorant of that sage piece of coding advice. My ignorance finally came back to bite me in the ass this weekend. I couldn’t figure out why PhotoMonkee was crashing while working on the newly revamped free transformation tool. Behold…the offending function:

QCursor MoveTool::GetCursor() {

    switch(m_eState) {
    case None:
        return QCursor(Qt::ArrowCursor);
    case None_Moving_Cursor:
        return QCursor(Qt::SizeAllCursor);
    case OverHandle:
        return QCursor(Qt::OpenHandCursor);
    }
}

Two problems
One – no default statement. Woops…must have spaced that one. Two – there is no return statement at the end of the function! If the current state of the move tool is MoveTool::Resize then we are going to return…whatever the hell happens to be on the heap. Yeah, that’s bad. GCC would have bitched at me for this one but for whatever reason, Visual Studio let it slide. I’m sure there’s probably a warning somewhere in my compile logs (there are quite a few I admit I need to clean up) but this seems like a disaster waiting to happen.

So, young coding adventurer, heed the words of your instructor. He or she probably had a good reason for the twenty minute diatribe about why they…wah wah waaaahh wah wah wahhh wah wah.

I spend a full day at the office cranking away at my day job and then spend my evenings writing PhotoMonkee features. I’ll admit that I don’t cook up my best stuff during the hours when I’d rather be reading, vegging out playing video games or some other leisure activity. It’s during those ‘tired’ times when problem solving gets difficult and putting forth more effort is all for nothing. Chances are I’ll spend a solid hour fumbling around the problem and never really come up with a creative solution. Instinct and a desire to solve the problem say you should pour a cup of coffee and really buckle down. I say that’s when you pack it in. Yeah, that’s right: give up!

Chances are, if I get a good night’s rest, before I arrive at the office I’ll already have a potential solution come to mind without really “focusing” on the problem like I would sitting in front of my computer. Sometimes, trying harder just isn’t the answer.

What was the problem I was working on? Glad you asked!

PhotoMonkee uses Qt’s QGraphicsScene and QGraphicsView classes to manage drawing operations of the canvas. The handles used to transform the current selection “live” within the same scene. So if you want to click a handle and drag it outside of the canvas (i.e. stretch it a lot) you aren’t allowed because we can’t draw the handle.

My first idea (that I was pounding on last night) was to draw the resize item and its handles as custom QWidget items that were children of the current window. The major gotcha there? You can’t rotate windows. Back to square one.

The solution that came to mind this morning? Create an invisible “overlay canvas” that encompasses the entire window. Since the overlay scene covers the entire window we’ll be able to drag the handles anywhere within the confines of the window.

So, the next time you’re stuck on a problem. Try ‘backgrounding’ your brain and let a solution come to you!

Twelve years ago when I graduated from college coding was fun. I thought my passion for coding was enough to get a business up and running and in 2003, started a game development company. A short 8 months later we closed up shop and I was left wondering what the hell just happened. I pissed away my “dot com winnings”, put my family in quite a financial pickle and was really questioning my judgement.

It wasn’t lack of passion that was the problem – it was lack of experience and guidance. Let me qualify that last statement. By “experience” I don’t mean a corporate cube farm but rather the process of taking a project from inception to completion. Sometimes you make decisions to cut corners, skip functionality, enhance specific areas and make other “on the fly” judgement calls that only come from working on real-world projects.

In my professional career I’ve authored roughly a half dozen major projects from inception and each time gained valuable experience to improve my own personal process for the next iteration. PhotoMonkee has been a very interesting experience on that front. I’ve been able to, very quickly, learn new algorithms, turn out new feature and cycle through bugs. Most recently I completely changed the development environment from Qt Creator to Visual Studio in a couple of hours. No small feat but without years of Windows software development under my belt that quick turnaround would not have been possible.

Now, I’m not advocating everyone spend 12 years in a cube farm before finding your personal pet project and striking out on your own. However if that’s what it takes for you to perfect your own development cycle then so be it. If coding new features and the “debug cycle” doesn’t come easy to you then it’s worth taking a step back to think about your skill set before venturing out on your own.

PhotoMonkee is built using the (wonderful) Qt UI framework. Something that’s been on my TODO list for quite some time has been to customize the look of all the dialog boxes in the application. Qt allows an application to completely customize the look of any window control but doing a dialog is a bit tricky. The first thing I needed to do in order to fully customize the dialog box is to drop the entire window frame that the window manager encases the dialog in. That includes the title bar. One of the main features of a dialog box is the ability for the user to move it around on the screen by clicking on the title bar and dragging it.

Enter: Subclassing. I created a new class, PMDialog that is derived from the QDialog class. In it, I create a QLabel that always exists at the top of the dialog (32 pixels tall). It contains the nice gradient you see as well as the title of the dialog box. An event filter handles the magic of capturing the mouse when the user clicks on the header and drags the dialog around. Seriously…Qt has hooks for everything!

Another sweet feature is the ability to set a mask for any control to display non-rectangular shapes. In the case of PhotoMonkee’s dialog boxes I’m cooking up a 1bit QBitmap with QPainter::drawRoundedRect() and applying the result of that to dialog. Voila…curved edges.

After we get out of alpha I’d like to come back and animate the display and closure of dialog boxes. Now that all the functionality is wrapped up into a single base class it’s an “implement once and enjoy everywhere” feature!

Viva le Qt!