So, what has been developed in the last 8 months? I couldn't resist trying to add FLTK and wxWidgets versions. FLTK is quite strange, since its Fl_Pack resizing only works properly once everything has been explicitly positioned first! I also saw a review of the latest Haiku beta version and remembered that I had tried it briefly some years ago (still has no official out-of-the-box samba though.)

GTK3 and gtkmm2 'release build' versions for win32 and win64 platforms.
Slightly re-jigged grid layouts, but still following hard-coded widget positions and sizes for most things.

Uploaded win32 release version.

Still persevering with the GTK+ version. I've managed to use the prebuilt binaries provided by TARNYKO for windows. Have a small problem with Vista64 as a build platform though (moved to a Win7 PC to build)...the provided exe's just hang (as does the MSYS2 pacman ... but that's nothing to do with the prebuilt binaries.) Anyway, there's still a bug with my 'list-widget' klass (sic.) Just like Qt, I would like to be able to create something best described as a (Gtk)ListWidgetItem. My solution involves creating a temporary GtkListStore for items that are created and populated with apt. data, but not actually assigned to any widget...so I'm still debugging this. Also, the linux (Xubuntu) version didn't work, but that's another story.

I have been working on a GTK+ wrapped implementation, with the aim of hopefully reducing the dependency 'mass'. I am not sure how much it wil help.
I have also started to install Lubuntu on a few PCs/VMs and will look at LXDE vs LXQt. Hopefully GTK+ won't die completely in the near future.

Lots of little Voyager bug fixes, including but not limited to: * Image view window now shows image at top-left instead of centralised (ignore color space not working yet). * List/Tree view correctly resizes when main window is resized. * ColorTab should now work (best to try rgbf32 format first!) * OutputMode tabs now work, and PixelType combos are populated.

Uploaded latest build for linux 64bit platform. Requires gtkmm 2.4. Built on Xubuntu 14.04, tested only on same.

Slightly updated gtkmm binary releases for both win32 and win64. As before, dependencies bundled in the zip file. The .txt 'ui' files are not needed since equivalent definitions are stored in the exe. The latter, however, will be overridden if the apt ui file exists on disk. In addition, the exe saves a copy of any ui form (either internal or loaded) to a ui file named .temp.<ui filename=""> in the programs cwd. Also reinstated 'color24' format since I have not got around to completely replacing it with the more generic 3u8+RGB-color-space+b-g-r-order format. In fact the specification of channel order is not even shown/editable.</ui>

The gtkmm folder contains all the files required for running Voyager gtkmm on windows 32 platforms. The dll dependencies are bundled in the .zip file.

Using gtkmm 2.22.0-2 prebuilt binary package. Everything works so far apart from DnD issues: * Windows 32 exe (running on vista64): The connected signal_drag_motion() signal is not issued when urls are dropped onto (i) a Gtk::Image and (ii) a Gtk::TreeView. The latter I can understand as there is some extra DnD functionality built in. With regard to the former, various required signals, e.g. signal_drag_data_received(), signal_drag_drop(), are sent. I tried omitting Gtk::DEST_DEFAULT_MOTION from the call to drag_dest_set() but it made no difference. I'll have to try building on one of my Xubuntu distros instead...I want to process the 'motion' signal at least on first occurrence to determibne whether one or more of the URLs refer to image files that voyager thinks it can open and display...
BTW, has anyone tried to build Gtkmm from source ... Glib was easy (needed libintl source package in the 'right' place), but good grief, building Gtk+ as the next stepping stone...I gave up -- too many versions, don't know which versions to choose (zlib, libpng, cairo, pango...)! To be fair, building Qt 4.x from source needs lots of decisions on what to include/exclude but at least its ONE SOURCE PACKAGE! The prebuilt gtkmm binary package I am using is fine, but without the sources, how can one really debug and find out if issues are bugs in the library packages, work-around-able or not, or just bad client code! Ok, just like blaming faulty hardware, I get it...but it could be a bug in gtkmm!

Hmmm, I've now managed to drag and drop urls/strings from windows explorer to the Gtk::Image and Gtk::TreeView widgets in voyager-gtkmm. Because drag/drop message handling was hastily implemented in the original Qt voyager using the event handler callback for the parent window, the logic was bundled into one or two heavily Qt-laden methods. It needs some more logical ordering, so I'm in the process of doing this. Currently viewing a page at pygtk.org showing how to drag/drop from a TreeView using strings...let's see if it works.

Slowly the abstracted GUI is taking shape. I can now build the entire main window and several dialogs from a rather clunky text description loaded from a file (in Gtkmm). During the struggle between Qt and Gtkmm I broke the parser for reading my gui config file formats with Qt, which is a shame, but still the main Qt design exists in the .ui files originally created. I just didn't want to redo the whole thing with Glade. I have to use Embarcadero XE2 for my current 'works' project, so I'm getting a little over-exposed to GUI editors :-).Sigh, whatever happened to the command line -- Oh I know its for sys admins and people who learned to program (code!) in the 1970's and 80's. Anyway when its reasonably stable I will endeavour to release the various versions (hopefully, I will not be sidetracked by FLTK before then...).
I have yet to properly abstract the Drag and Drop functionalities of Gtkmm and Qt.

I am seriously doubting that this will ever be finished. Here is a list of troubles:
1) Upgrade Mandriva 2010.2 to Mageia appeared to work ok, then Konsole would not respond to the keyboard. Found 1 www post that was no use. Managed to install xterm on 586 version only, couldn't manage it on x64 platform.
2) Back-tracking to Mandriva, all the update links are dead, so could urpmi the gtk+ development stuff.
3) Gave up and went with Xubuntu 14.04. This is the same version as used for ARM (tf-701t).
4) My playstation3 (YDL 6.2) has locked for 1/2 a day trying to compile just 1 file! The yellow HDD led is flickering so its still working. Seriously thinking about getting an old Powermac g5 quad just to compile for ppc.
5) Haven't quite aligned Gtkmm and Qt yet within the context of my application. I can build a pretty good approximation of the original Qt app by parsing a text file representation that's a nasty compromise of the two. The idea is to have one text file that can generate the same apparent widget hierarchy in Qt and GTKmm (and FLTK for that matter.) I think it would be easier to have bespoke syntaxes, one for Qt (citing 'central widget', and one for GTKmm (with a vbox to layout the menubar, main window client area, and status bar.)
6) Oh, and my file server was locking up through overheating because it uses a poorly cooled x38 mobo (southbridge, esp.) and an even worse gigabyte 8400gs gpu card that appears to hit up to 120 degrees C (all mounted in an old case without fans!)

• Just uploaded the latest win32 version (tested on a vista64 i7 platform, but not on windows10)
• ppc32 (linux ps3/powerpc) and arm32 (linux) built and will be uploaded shortly.
• Lots of things not working properly, but progressing ok. Most of the 'no creator' msgs can be ignored!

+New templated features for signal/slot abstraction and object properties now compile with gcc (what a fuss! Microsoft makes things so simple...) Linux dev platform is transitioning from Mandriva 2010.2 to Mageia (for what it's worth)
-Not all dialogs are fully ported to the 'abstract toolkit', there are some non-functioning widgets, and the imgcore lib has some issues with not supporting various pixel types, or at least making it difficult to copy from one image to another (usually RGB->L*a*b* where the types and levels differ.).
+Some image copy methods now check to see if the biases/offsets match and try to perform a cast instead, Hopefully this will make some things faster as image sizes get bigger.
+Hope to release an arm/linux version soon--I have used 'Trel725's' github page, etc., to boot linux natively on my tf701t, and apart from looking at Xfce 2560x1600 on a 10" display, its good--really good--until the display goes blank. And to think I've got a U3014 and a U3011 sitting on my desk...
+Updated to Qt4.8.6 for some platforms, and have tried msvc 2012/2013 on Windows 10 with 32 and 64 bit builds.
?Looking at FLTK, GTK+ for an alternative. Has anyone ever really ported from Qt?
...and I'm currently building a 32 bit voyager on my PS3 running YDL 6.2 with Qt 4.8.6.

Ok, so when I said 90% it was more like 75%. Menu actions, drag and drop, etc., are now abstracted and recast signals and event messages to common templated interface objects that redirect somewhere outside of 'Qt'land'. Now, here is where more trouble starts...and I guess I could've looked at this earlier, but browsing images, etc, for FLTK, GTK and anything else that touts itself as a 'Gui' or 'Widget' toolkit, I have found nothing that looks like it could fill-in for a 'QListWidget' with icons+text. Now maybe its all quite simple...once one has the secret knowledge! Clearly, its possible, its just a bit rich that I'd have to implement it with a little bit more work and effort than I'm actually prepared to put in. I mean, as a 'net consumer' (pardon the pun) that's what the internet is for, isn't it? I mean if I have to work for everything I want in this world then I thik it's a damn cheek!

90% of the abstraction has been completed. TODO list = { menu actions , some drag+drop , dialogs .} Once I am satisified that the absraction is complete, I will release the Qt version and then look at alternative implementations purely for the sake of it. I might also find time to improve the botched color-space conversions.

• I have spent a while making a complete hash of my Voyager project. I decided to abstract absolutely everything so that Qt dependecy is minimised to a core set of classes which are wrapped by apt classes that implement a non-Qt interface. It is not as straightforward as originally envisaged, made all the more diffiicult by lack of design documentation--well what's new in the world, eh?

I've been working abroad for a few weeks, so I have not made as much progress as I would have liked.

The basic mechanism for specifying colo(u)r-space is in place and most conversions work, e.g. YCbCr <-> RGB <-> XYZ.

The single 'fly in the ointment' is L*a*b*. This is because L* is scaled to a natural level of [0..100] and not [0..1], whilst an integer-format image storage uses [0..255]--giving a scale of 2.55 and not an intuitive (expected?) nice 'uint8_t' friendly 255, or [0..4095] / 4.095 / 4095, etc.. Also, I quickly hacked in a CIE U*V*W* 1964 color space before realising its chromatic component is taken from 1960 'UCS' which uses a color model based on 10 degree field of view experiments (as opposed to the earlier CIE 1931 2 degree experiments.) I haven't made available the time to identify the implications of this, and whether there is a reasonable conversion to 2-degree field of view based color space models. Also, the achromatic component seems arbitrary--i.e. The 1964 color model does not have appear to a specification for the achromatic component (given my brief survey.)... read more

• The existing strongly-typed library has reached its practical limits. It is no longer feasible to represent both color model, native type of each channel, and additional channels (always one or more alpha channels) with a separate data type for each permutation. This was practical until I considered supporting non-RGB color spaces. The current direction is to remove the color model element and specify the 'photometric interpretation', or variant thereof, for each channel using an enumerated approach. This is proving a challenge, but things are at least progressing, albeit in fits and starts. Once the new model is in place the library will be able to handle, e.g. L*a*b* images in unsigned 16 bit/channel format natively. This will be combined with the existing 'Levels' idea so that almost any arbitrary range of scaling and offsets can exist for each image channel. One issue I face is that all color models are generally tri-chromatic, be they somewhat RGB-related (e.g. YCbCr, YCgCo or, shock, horror: IHS/HSL/HSV), or CIE XYZ-related (CIE L*u*v*, LMS, etc): in this I wish to be flexible so as to aid support of multi-spectral image data and also CMYK (very little 'proper' info on this--but I've found a web page giving standard profiles related to L*a*b*). I am trying to minimise the class count, whilst maximising flexibility...:-)

• I have completed the latest implementation--all types now have an additional and modifiable set of bias (offset) and scale values for each channel.
• 12 bit images are now presented as 16 bits/sample images with zero offset and 4095 scale (e.g. expanded from 12 bps jpeg-in-tiff.)
• The extra and also floating point computations are noticeably slower than previous...I now need to consider the case when some or all of the extra computations can be omitted (e.g. when scale is unity and offset is zero, or when scales are equal. In the former case a cast can be used if the color space is not changing.)
• I have not yet updated the file formats (.tiff and my own .pic) to save the extra information. Also, I am toying with the idea of presenting the scale/bias data in companion files where the file format does not support it.
• The IYU2 and UYVY image formats convert to/from RGB using ITU-R BT.601 with implicit (0.5,0.5) scaling for U (Cb) and V (Cr). The only currently available types for YCbCr are 8 bits/sample as implied by the FOURCC names above. 'Studio swing' levels are default, but can be changed to 'Full swing' via the 'SetLevels' tab which is located on the 'AnyBlt' tab (it would be more at home on the 'Attributes Tab').

• I have now implemented a linear rescaling/biasing method that works for equivalent color space types and for some inter-space type pairs. So a jpeg can be decoded to an rgb image with 16 bits/channel with [0..4095] set as the scaled limits; a YCbCr image (e.g. IYU2 8-bit 4:4:4 format pixels) can be selected to have jfif-jpeg scaling (0..255) with 128 biasing for Cb/Cr or video scaling (16..219) etc.. BT-2020 levels may also be set for higher bit depth image types. The user has the choice to decide if footroom/headroom is left blank or if it may be used for outside-gamut colors.
• Fixed a bug with CIE XYZ/Luv/Lab where data was not being copied when converting to RGB.
• I will endeavour to make a new release shortly.

• I am making progress with the per-channel linear transformation to be used when an operation uses separate source and destination images.
• I have also considered including optional pre-conversion linearization of gamma-corrected images and post-conversion non-linearization according to gamma/lut characteristics. This does somewhat go against my early ideas of providing the low-level tools to do all this one's self, but I realize that its an awful lot of faffing around if one knows conceptually what steps are required, but must perform a sequence of basic tasks (clicky-clicky-clicky...argh my wrist hurts) to complete a conpound operation. What this means of course is that I, the designer, and developer, must provide composite as well as basic tools on each tab, thus requiring the use of check-boxes, etc., that shall perhaps confound ease of use for the newcomer. Additionally, all this extra info is not catered for in many image file formats (perhaps they have latent defaults). My thought is to provide meta-data in the form of an additional file as required, so that it may be saved (for posterity :-) ?).

• The next release will include a linear mapping scheme so that there will be a specific relationship between pixel values stored using different pixel types, e.g. it will be possible to store values [0..4095] in packed 16 bit word arrays. This will provide basic tools necessary for handling BT.2020 10+ bit pixel levels where footroom and headroom are reserved.
• I found a bug affecting 'notDst' (and by extension 'dstCopy', and MathTab's 'auto-' functions) operations on Memory-resident images. A non-zero horizontal offset for an AOI was effectively added twice, producing incorrect results, and also possibly corrupting the heap.

• Voyager now loads bitmap, targa and sgi rle images and automatically decompresses them. Also, automatic recompression occurs when such an image is saved.
• Bug-fix for tiff where null pointer exception was raised when creating in-place tiff image on disk.