Mike Chaney's Tech Corner

Hello all,

I apologise for such a long first-posting.

I've added my query below, but as this is my first posting I'll offer you some background about me, and about my intended use (at least in the short-term) for my happily installed and working Qimage Ultimate (QU).

I'm new to Qimage, although I've known about it since my days on the ImageKind Forum (circa 2006 and later) where it was cited many times as the "essential & definitive" printing tool.  I'm still discovering wonderful new QU subtleties every time I consult its excellent built-in Help, and I've watched 22 of the 33 superb video tutorials  :)

My setup here is: Windows 7, 8GB RAM and acres of free disk space, with a superb NEC colour-calibrated monitor, hopefully to do justice to my Nikon D700 photography. I "went digital" in 2005, and I use Capture NX2 and/or (as needed by the image) DxO Optics Pro for all my editing. (I have no plans ever to buy PhotoShop.)  I've already used QU to take a handful of photos completely through from .NEF to 'final product', and I look forward to learning and employing QU's strengths on those photos that simply must be printed!

The majority of my photos exist only as digital images, so I can't (yet) justify the cost and enlarged desk-space needed for a fully-specified colour printer.  When I do need to print something I'll use an online printing service - and Qimage's ability to Print to File was the key feature that tipped the scales on my decision to buy it.

For my occasional "arty" work on high quality papers I'll send my photos to my preferred "serious" printing-company in south Wales (UK). For less demanding stuff such as 10 x 8's or A4 prints for my camera club competitions etc., I'll (typically) use the fast and cheap PhotoBox UK, and suffer their small colour inconsistencies. And finally for "office" type work I've got a 4-ink-only "utility" printer (an HP OfficeJet), which I don't plan on using for any serious photo printing.

The great news is that - once I've tapped into it's huge potential - I can use QU to improve all three of these printing scenarios :)

Now to my query, and sorry for the long preamble  ...

I've noticed that all of the EXIF and IPTC data has been stripped from my QU Printed to File images. EXIF gone! IPTC fields empty!  Yes, I can understand that the only metadata that my online print-company actually needs from me is the image's embedded ICC colour profile (which is still comfortably in place), but Drat! I don't want to send my images off to any 'external' agency without at least some of my carefully managed metadata on-board!

If I'm doing something wrong then please help me fix it, thanks - or, if this is by design in QU, then please Mike, re-interpret this "lost metadata" query as a new "feature request" :)

(Qimage reports that the files do still contain their embedded ICC colour profiles, but because the QU Printed to File images appeared so bereft of metadata when checked with ExifTool, or with my copy of Picture Information Extractor (version 6.40), I took the liberty of verifying that the ICC profile was really 'intact' by using the excellent GNU-licensed Argyll CMS (http://www.argyllcms.com/) utility called "extracticc".)

I've got a long-established workflow based around my Imatch database, and I can use IMatch to re-inject the EXIF and IPTC metadata into my QU Printed to File images, but this would become awfully tedious for more than a few images at a time.

I tried this Forum's Search facility to see if this (lost metadata) has been mentioned or 'acknowledged' previously, but on the contrary, the vibe that I'm picking up is that Qimage strives to protect and to propagate all metadata in the files that it processes. So I really hope that I'm goofing somewhere, or that I've met another "Windows 7" quirk!

Thanks in anticipation.
Colin P.

Hi Colin,
I am going to make a calculated guess here. We can ask Mike later when he wakes up.
An image is a file! The file usually has a header which we hope contains reference data.
When we print to file, it usually means we have put together multiple images into a new single file. 
You can readily see that the resolution  alone is something you select, no longer the one from the camera.  Same goes for the Aperture and shutter etc; no longer relevant.
So first question: with multiple images, which data should we/could we assign from which image to the newly created file?  This is a new file with a new header.
Read the EXIF from the new file and you see a new resolution, the date and time it was created, and the new profile that is embedded.

Second question would be: Asking why are you using Print to File?
Answer:  You have a collage of images on one sheet or some floating text that has to stay with the image. (Maybe I missed something, so fill me in please)
Otherwise, if you are presenting a file to the outside printing service of a beautiful image you shot, and it contains *one* image, why Print to File?

Simply convert to a TIF, embedding the profile that the service requires, and you are done.  The EXIF is retained.

If I am off target, and you have other reasons for a Print to File, you still have the original images which never get altered or stripped in any way. You just hover the mouse over the thumb, and it reads in the hot bar.

Hope some of this works for you.
I seem to remember you Colin from the Qimage Groups from years ago! Am I remembering right?

Best,
Fred

Thanks Fred,


Ah! An excellent point!! And I admit that - because my use of QU so far has been to operate on one image at a time - I hadn't considered this! I now see that some key elements of the original EXIF cannot logically (nor legitimately!) be 'passed on' to the new image!  I also know from other contexts (such as in ExifTool's amazing complexity for example, and in the sparsity of EXIF data provided by most film scanners) how difficult it can be programmatically to regenerate and inject new EXIF data into "new" images!

So I accept that the EXIF data can't survive the Print-to-File operations, but - I wonder if Mike would consider giving us an option in some future QU version to let us "copy across" the IPTC info from the original image (such as my Copyright string and my Keywords) for when I know that they're still relevant to the "File" version of the image?


Hmmm! I'm intrigued by your question, and I notice that you'd asked the same "why print to file" question in another post (on a different topic). Given my inexperience with QU, I wonder what I've misunderstood from the "Online Printing" (http://www.youtube.com/watch_popup?v=REHC1_K93os&vq=hd720) Tutorial video? (That's the link to the 720p video, or here's the 480p (http://www.youtube.com/watch_popup?v=REHC1_K93os&vq=large) version.)  I'm intrigued because this enhancement for "Online Printing" is (I think!) one of the QU features I expected to use the most in the short term! But maybe I've got it wrong?  See also my reply to your next point ...


Yep! This is how I've been working for years with my online print services, namely, sending them high-quality .TIFs in AdobeRGB colour space (for the arty pictures), or sending first-time-saved / max quality .JPGs in sRGB colour space for everything else.  I've spent a lot of time and money having test prints made through some of these companies, with varying degrees of sharpening applied to my test images. And then, in order to negotiate their presumed PPI values and the dimensions of the non-printed borders around my (essentially bespoke) 'arty' prints, I've held many long telephone conversations with (for example) the helpful people at The Dot Foundry (http://www.thedotfoundry.co.uk/) or at Digitalarte (http://www.digitalarte.co.uk/) - just two of the services I've used.  In all these cases I've crossed my fingers and hoped that I'd "guessed" a good-enough degree of sharpening, and that I wouldn't need to cut yet another new cardboard mat to fit my (too often mis-calculated) 'final' printed area on my new prints ...

But now ... by using Qimage's Print to File feature (if I understand it correctly?!) - after a bit of normal trial-and-error - I hope to be able to send off repeatable, reliable, correctly dimensioned and "bordered" final-versions of my images, with an appropriate ICC profile embeded, and always optimally sharpened (thankyou 'Fusion'!) - and to save money on cardboard mats too!

Is one of us up a "Print to File" gum-tree Fred  :)  ???


I've very likely skulked around on a Qimage-related Group  :)  but I've never registered on one until this "Home Port" for Qimage.  Perhaps we've metaphorically met in one of my other much-enjoyed photo-Forums - ImageKind? Nikonians? RedBubble?, or Luminous Landscape (hardly been there recently), or even the hugely inspirational Martin Bailey Photography? (which again I've neglected recently.)  I'm on some others (e.g. IMatch) but those are the ones where I'm registered as "KolinP".

Thanks again for your feedback Fred, and I'll watch out for some nudges about my Print to File presumptions!

Colin P.

You are correct in your estimate of where to best use Print to File.
It is a way of setting a print size on a paer size with a print profile embedded all in one file.  Some printing services cannot cope with requests that are not common standards.
For example, if you shoot panoramas, the resulting print will have no common size. You have to decide.
So what do you tell the print company?

By using Print to File, you solve that question, and send them a file that cannot be misprinted.

That having been said, back to your original complaint of no EXIF carried forward. There is no chance of that because you are creating a NEW FILE from scratch, with your own parameters, and if something like this were to be implemented, which EXIF of the 6 images in a collage would be copied.?
Not workable!.
As I said before, the new file will show its own proper EXIF information.

The IPTC is carried over. If you place some keywords in to the image IPTC before you do your Print to File, you can retrieve the file with an IPTC search for the key word.
I just tried it twice, with a single image P2F and a double image P2F.
Works fine, so I think your troubles are over.

Fred

Hi Colin,
your original post:
If you really need to have EXIF data on a PTF created image it is possible by using ExiftoolGUI: http://freeweb.siol.net/hrastni3/foto/exif/exiftoolgui.htm
This uses Exiftool: a command line program http://www.sno.phy.queensu.ca/~phil/exiftool/ which you will have to download and copy into the ExiftoolGUI program folder.
With ExiftoolGUI you can copy EXIF data etc. from one image to another and edit many of the fields.
See screen shot attached below.
ExiftoolGUI is now "frozen" but Exiftool is regularly updated for new cameras etc.
Terry

I just did some more experiments with IPTC.
I  took 4 images and added various text to various fields in the IPTC  set. I can insert what I need: Location, date, F stop Shutter Time of day....

Besides that, how about Annotated Text in the Page editor. Simple and easy.... type in what you want and it appears in small type just below the print.

Fred

Thanks again Fred,


Thanks for the reassurance. I was afraid I'd missed a key point somewhere.


Not exactly a "complaint" ... rather, I'd hoped it was a pragmatically-presented question   :)  but I probably over-egged my query - as I'm inclined to do!!


Now we're hitting the nub of my original question, because (as I'd mentioned) my Printed-to-File (P2F) images contain absolutely no EXIF or IPTC data.  So - based on what you say - I'm now deducing that there's something askew on my system that's (apparently) blocking QU's intended "metadata" behaviour.  In my P2F images there is no new EXIF data relating to the (new) file's genesis in the P2F stage of QU ...


... and - to paraphrase my original query - none of my existing IPTC data has been carried across.  (I populate a set of IPTC fields in all of my images as I extract them from my camera or memory cards.)


I tried it multiple times too, but (of course) my results don't match yours, so I'll detour here and compile a quick matrix showing the files, the formats and the different pre-QU steps that I've used in my tests, and I'll report back.


I'm an optimist too Fred  :)  but clearly our "mileages" differ here  :)

Thanks for your help so far, and I'll come back soon.
Colin P.

Thankyou Terry,

I do have those excellent tools in my armoury, and I keep my ExifTool.exe up to date when I (regularly) run my copy of GeoSetter, which (as you may know) checks for and downloads each ExifTool-update each time it (GeoSetter) is launched.  Then, before I run ExifToolGUI (which I use much less often), I trigger a quick batch file which copies the latest-GeoSetter-updated copy of ExifTool.exe from my (Windows 7) "C:\Users\Colin\AppData\Roaming\GeoSetter\tools\" folder, into ExifToolGUI's working folder.

These are indeed superb programs, and we can only hope that ExifToolGUI's very useful though no-longer-maintained life is a long one!

But on your main point about restoring EXIF and IPTC data into my images when necessary and as appropriate, I already use the tightly standards-compliant tools included my IMatch (http://www.photools.com/) database program.

(Drifting off-topic briefly - It's ironic that - because I'm one of those pedantically-anti-Adobe-upgrade-bandwagon / non-Photoshop users - the only "flaw" with using IMatch to maintain my metadata is that Adobe keeps re-inventing the "standards", so I still need to tweak one "Photoshop-specific" XMP field that's not readily settable in IMatch, before I can send a photo into my Picture Library.  This is in spite of the continuing efforts by IMatch's author Mario, to keep up to date with Adobe's arguably conceited disregard for "standards".)(End of rant! Sorry.)

Thanks again.
Colin P.

Here is a screen snap of the NEW EXIF that Qimage writes to its new file

I did misspeak on the IPTC though. I forgot I had the original JPGS lounging around in the same folder. That is not carried through.
Sorry,
Fred

No problem, ta. I mis-spoke also when I said earlier that "there is no new EXIF data relating to the (new) file's genesis in the P2F stage of QU ..." - because I do now see some EXIF data, but only in .TIFs created by QU's P2F phase!

I'll be posting another reply in an hour or so (I gotta break for a meal!) showing the full results of my tests today, but for now, can I offer you a peek at what I understand to be the new EXIF data in the P2F .TIFs ...


Thanks for that snap, but (ummm...) how do I say ... that QU Info Panel - for that file - is showing some file data, but it's not actually the EXIF data!  Here's a short series of snaps from here, showing what I mean, and the Info Panel snaps include Qimage's EXIF Hot Bar along their bottom edges - (sorry the shrunken-quality is so low) -

i. Qimage's Info' Panel showing the portions of EXIF data drawn (by QU) from an 'original' sample file. The sample file's thumbnail is 'Selected' in QU's browser pane, and I've highlighted the QU-extracted EXIF data in yellow.

ii. A snip from EXIFToolGUI that shows the newly embedded EXIF data in the .TIF version of a QU Printed-to-File image. The specific file (called _C7P3473{ViaJPG-Q-P}.tif) is highlighted (selected) in the left-hand pane and (of course) its embedded sub-set of EXIF fields appears on the right.

iii. Qimage's Info' Panel showing that the newly embedded EXIF data is not revealed (by QU), even when that file has been 'printed' as a .TIF.

iv. Qimage's Info' Panel showing the still-absent EXIF data from that same sample file, after it has been 'printed' as a .JPG.

(Sorry I haven't included a snap here to support my assertion that - when examined in EXIFToolGUI for example - the .JPG-emitted QU-Printed-to-File images do not carry any new or old EXIF data.  I'd be very glad to know if (or that) my setup here is amiss somehow, so I'll welcome any news that refutes this.)

Colin P.

Hello again.

As promised, here are some results from tests I made on a collection of what I hope are representative images. I attach a one-page PDF-rendering of my hurriedly-made spreadsheet, showing my tabulated results (so far). The table in the PDF/spreadsheet shows a number of permutations of original .JPGs and RAW files from different cameras, and the editing steps I took on them prior to asking Qimage Ultimate to make Print to File versions of them.

I admit the test results will only interest someone (if anyone at all!) who asked themselves this same question about retention of EXIF or IPTC data in QU's Print to File process!

On my setup here (on Windows 7 etc.), I see a clear pattern for when Quimage Ultimate (version 2012-221) embeds the EXIF metadata into the new files it creates in the Print to File (P2F) phase, and a quick summary of my results would be -

1. When QU makes a new P2F image in .TIF format, then in addition to the standard .TIF header information plus the User-specified ICC profile, QU embeds a small and logical sub-set of EXIF data relating to that file's creation by QU.

... however, on my setup here, so far ...

2. None of the .JPG files made by QU's P2F phase contain any EXIF metadata. They contain only the standard JPEG header information plus (again) the User-specified ICC profile.

So I was wrong when I said earlier in a previous post that "there is no new EXIF data relating to the (new) file's genesis in the P2F stage of QU ...". I'm sorry for that. I simply hadn't looked close enough at the one or two .TIF files that I'd "Printed-to-File" at the time.

On the principle that I'm aiming just to "get to know my tools" while I work with QU, I'd be glad to know whether this is "simply how it is" in QU ... at least in this version   :)

Best regards for now.
Colin P.