I have fixed a couple of bugs, and added one interesting feature: fPic.displayImage(). It uses GLUT to open a window and OpenGL to draw the fPic. The code is crude in the sense that it’s mono-image only [create two fPic, display both and watch my code make a pig’s breakfast of your efforts], and doesn’t care much about checking your screen bounds vs the image’s. That’ll come in time. But it’s freaking fast. Like, very. Even on my tired TiBook, the most time-consuming task is creating the window. Copying bits to the buffer is something C code and PowerPC do well and fast.

I am not sure whether a command-line application [the intended target of fPic] is really in need of a GUI solution, even a limited one, but it sure comes in handy for me when checking the execution of new functions in fPic.

I have released a beta of fPic – on the RB-NUG and [unofficial] RB/FR lists and on RB Garage. Some feedback already from the French side of the programmosphere – despite the language barrier, as the docs are in English. We’ll see. I am to hand over an article – like three months late – that will tie in nicely, as it is the second part of Pictures and Dynamic Libraries: a poor man’s plugin, which introduces the basics of fPics. The second part will delve deeper in the mechanics of linking C code and RB code in an OOP fashion – hopefully.

From the docs:

fPic is a two-part project aiming at providing a replacement Picture class for command-line applications [which notoriously lack any graphic capabilities]. I say two-part because it is split into a dynamic library [manip.dylib] and an RB class, fPic. The dylib handles the heavy-lifting, while the fPic class provides a [more or less] seamless way for RB programmers to manipulate images in CLI applications. I hope to be able, in the end, to produce a library that will have zero dependencies, or at least zero exotic ones (like things usually installed via Fink), but for the moment, some things are necessary, as doing without them would either cripple fPic, or make it too hard to build from the get-go.

And of course, this is a Mac OS X only library. I am planning to make a Linux version, some day, when the Mac version is stabilized. The Linux version, however, would have fewer functionalities, as I can’t use the Accelerate [FreeRotate, ContrastStretch and Equalize] and CoreGraphics [PDF files] frameworks there.

I have provided a few sample programmes, which show some of the things that can be done:

* fPicTester
fPicTester showcases some of the capabilities of fPic. It requires the images included in the distribution folder. The resulting image, Result,jpg, is opened in Preview.

* jpeger
jpeger is a small utility that takes a file image, a destination folder or filename, and some options, and converts the source image to a JPEG image. On success, if only one page was converted [in the case of PDF files, you may request one or more pages], the converted JPEG is opened in Preview.

* OnDemandPDF
This is a combination of a command-line app and some PHP. Put this folder inside ~/Sites/ so that it is accessible from your localhost [you’ll need Apache and PHP up and running of course]. Put some PDFs inside the docs subfolder, and access it from your favourite browser:

http://localhost/~yourNick/OnDemandPDF/
Click on one of the links, to view a document, and read it “online”.

This is a very early beta version, although I do use it myself in a couple of projects, so far without major problems. There are issues yet to be solved, see the docs included in the distribution, and feedback would be appreciated.

You can get the current beta here

Arguably of little worth for the moment, but still: fp.Histogram(values(),colours()) gets you that. Under 0.4 second, too. The rest you can hack, I s’pose, mmm’kay?

I have partial PNG support in fPic (since I am writing the code from scratch, I still consider this as a success ). 8-bit PNGs with a colour palette seem to be the easiest to process. At least, without interlacing. *That* is going to be interesting… Adam7 me arse, right…

Added TIFF support via libtiff, which was easy enough. Is it just me, or TIFF is a dang bizarre format? Not only the byte order is way up the yahzoo scale (ABGR, wdf?), but in the end I had to rot180 and hMirror the image buffer in order to get a correct image… Damn weird. Lucky I had those fast square-angle rotation routines up and running already!

(lib)PNG is still escaping me, I am down now to producing my own. Grrr.