Interview with Pavel Kanzelsberger, Creator of Pixel
One of the applications that we Linuxers have long longed to have natively on our beloved platform is Adobe Photoshop. Although nearly all of us have turned to the trusty GIMP for our image manipulation needs, The GIMP's limitations, such as lack of support for the CMYK color model, keep it from fully replacing Photoshop. Luckily in our community, if there's a hole in the application portfolio, there is a scrappy, innovative dot-org or developer striving to fill it. A prime case in point is Pavel Kanzelsberger, the Slovakia-based developer of Pixel, an up-and-coming and very multiplatform image manipulation program. If Kanzelsberger's ambitions are realized, his handiwork may one day even out-Photoshop Photoshop. We recently caught up with Pavel to find out more about Pixel.
LJ: Thank you for agreeing to speak with us, Pavel. First of all, how does Pixel compare to Photoshop? And, do you aim for compatibility in file formats and the same or a similar feature set?
PK: Well, frankly, Pixel tries to be comparable with Photoshop in terms of features. But, on the other hand, it tries to be smaller and have lower hardware requirements. I wouldn't compare it to Photoshop yet, because Pixel is still in beta. My goal is to catch up with the industry-standard Photoshop and then bring in more innovative and better features. Pixel will support import and export to Photoshop file formats, but it is utilizing its own file format, because there already are some unique features not present in Photoshop.
LJ: What features of Pixel are you most proud of?
PK: Those features unique to Pixel, such as multiple-color managed clipboards and color management in general. The live effects feature was quite difficult to do as well, and I think that it is already better than Photoshop. In Photoshop, you can use an effect only once, and you cannot control the effect's order.
LJ: What are your customers asking for regarding changes or improvements?
PK: I'm getting a lot of requests and ideas from users. I think they like to influence development in a way that is not possible for bigger commercial projects.
LJ: Are you finding a large number of Linux users who say they cannot live without Photoshop but then find Pixel to be a good alternative?
PK: Yes, most Linux customers are using Pixel for this reason. Many users won't migrate from Windows to Linux because they're missing applications like Photoshop. There also are users who like a familiar interface. As far I know, Pixel is the only application supporting CMYK and proper color management on Linux.
LJ: Can you compare Pixel and The GIMP for us?
PK: Sure. Compared to Pixel, GIMP is missing a lot of important features, such as CMYK support, color management, layer adjustments, layer effects and so on. Also, a lot of people complain about GIMP's user interface. Such an approach is very common on Mac OS X (have a look at Photoshop), but people find it strange on Linux and Windows. Otherwise, it is a nice open-source effort and will do just fine for basic editing.
LJ: If I am a graphic designer, will I have any production difficulties with prepress, printing companies and so forth if I use Pixel vs. more mainstream graphics tools?
PK: I wouldn't recommend it right now, as it's in a beta state, but when it's finished I think it will be perfectly usable in such environments. All tools needed for prepress and printing will be ready in the final release.
LJ: You seem to have nearly every OS imaginable covered, including Linux, FreeBSD, Windows, BeOS, OS/2 and many others. How and why did Pixel become so multiplatform?
PK: Pixel started as a DOS application in 1997, and then it was ported to Windows because everybody already was using Windows by that time. Pixel's “multiplatformness” started with a request from Be Inc., the former BeOS developer. They donated all the tools and help for porting Pixel to BeOS. After that, I discovered Linux and decided to rewrite Pixel from scratch and make it less platform-dependent, so it could be ported to new operating systems or architectures easily. All of the other exotic platforms came mostly by community requests and OS fans.
LJ: How many customers do you have, and what platforms are the most popular?
PK: Right now, without any marketing and with an unfinished product, you can count them in the hundreds. I hope it gets better when Pixel is finished. The most popular platforms are Windows, Linux and Mac OS X—in that order. Windows is doing 50% of all downloads; Mac OS X and Linux together make around 40%.
LJ: I see that you charge $38 US for Pixel. Are you finding resistance among Linux and FreeBSD people to pay for their software?
PK: Yes, quite often even with requests to open-source Pixel. But, I'm trying to explain to them the licensing scheme. I'm not charging money for the Linux version of Pixel, but I'm charging for Pixel itself. It doesn't matter which operating system you are using—the license allows you to use any or all of them.
LJ: Can you tell us a little bit about the development process? For example, how much work do you do yourself vs. others on your development team, if you have one?
PK: The Pixel development team consists of one person, and that is me. So everything is done by me, including development, Web site management, bug tracking, support and so on.
LJ: We would like to know more about you too, Pavel. Is the Pixel project a full-time job for you, or do you have another day job so you can pay your bills?
PK: I've had full-time jobs in the past, but since early 2006, Pixel is the only job I've got. It is a very important project for me, so I decided to quit my job and focus on Pixel alone. When I saw Pixel was selling and earning enough money monthly, I decided to quit my job and live off Pixel. For now it works, and I hope it gets better in the future, but you know this place on earth where I am [Slovakia] is quite cheap to live.
LJ: Do you have sponsors who help pay the bills?
PK: I don't have a sponsorship of any kind, but I'm getting offers from time to time.
LJ: What other things have you done in your career?
PK: I worked in different environments, mostly with Linux servers, SQL databases and Web-based applications. I made a few corporate information systems and even led a team of multimedia developers in Asia.
LJ: Where did you work in Asia?
PK: I worked in Seoul, Korea, for about a year in 2005. However, the photo I sent you for this interview is from Tokyo, Japan, where I spent only week or so. I was using Linux there, and because of that, they treated me like I was an exotic dude. They use Windows so much.
LJ: What inspired you to create Pixel?
PK: When I learned programming, I had a really prehistoric computer called IBM PC XT with a CPU at 4.77MHz and a CGA graphics card. My plan was to make some games, but as you need graphics for games, I started by making an image editor. The first version I made was called GFX Studio, which was running in DOS in 320x200 resolution and four colors! It already had a windowed interface and that gradually evolved into what you see today.
LJ: What tools do you use to develop Pixel?
PK: Most of the time I'm developing on Gentoo Linux with the GNOME desktop. I don't like over-complicated IDEs, so I'm using a simple text editor with syntax highlighting and a set of command-line tools to compile and debug Pixel. A few of them are fpc compiler, gcc, binutils, gdb and valgrind.
LJ: I understand that you live in Slovakia. What can you tell us about the Linux-related activity in your country compared to the rest of Europe? Are there other interesting projects or developments there that are worth mentioning?
PK: From what I've seen on the Internet, Linux is becoming very popular here, mostly in schools. There are many communities trying to help Linux newcomers, translating various Linux programs and so on. I know some very clever software developers in my country, but they're mostly involved in the gaming industry and in other commercial 3-D projects.
LJ: What future features should we look for in Pixel?
PK: In the near future, I'm planning to improve PSD import and to add full support for Photoshop plugins. I also might push for Wine support for the Linux version.
LJ: What are your interests besides taking care of Pixel?
PK: My family and my one-year-old son are the top priority right now. Otherwise, I like sports cars and driving. When I find some extra time, I like to play tennis or visit our beautiful natural areas.
LJ: Thank you, Pavel, and good luck to you with Pixel!
James Gray is Products Editor for Linux Journal.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- My +1 Sword of Productivity
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide