Hi all:

I am encountering a problem with QI where it appears that QI is converting my images to 8-bit (and possibly also the same colorspace).  This is not good.

My workflow setup: files -> Qimage -> RIP software -> Designjet Z2100

How I discovered this: I am printing up some images for a class I will be teaching on advanced printing.  I have 6 images I put together from the same HDR original: ProPhoto, AdobeRGB and sRGB in both 8-bit and 16 (all uncompressed TIFF files).  When I process/print these directly from my RIP (bypassing QI entirely), I get the variances that I would expect - the 8 bit output files are roughly half the size of the 16 bit and all the output file sizes are different.  When QI is introduced into the equation, the RIP reports the files all as 8-bit and all the output file sizes are the same.

This leads me to believe that QI is making bitdepth and colorspace decisions for me - which is VERY bad for my business and for this class I will be teaching.

Can someone confirm (or refute) this behavior for me with QI?  Is there any setting I can set where QI won't change these things on me?

Thanks!

Ron

Terry already covered it nicely but just to confirm...  QU is a windows printing application so the final stage is always to convert to 24 bit color (8 bits/channel) because all Windows printer drivers are 8 bits/channel.  QU does not, however, just "lop off" the lower 8 bits: it uses them.  The final print (or conversion) will still be 8 bit but in the case of raw photos or 16 bit TIFFs, it uses the full 16 bits to dither the colors between the 16.7 million colors provided by the 8 bits, creating a resulting 8 bit final image that is very close to 16 bit output when printed.  In this way, you can still print more than 8 bits of color shades to the standard 8 bit Windows printer drivers without the need for specialized print plugins or RIPs.  If you are going for full 16 bit output though, that requires special plugins or RIPs so if you just want to print 16 bits/channel for testing or some special purpose, you need to stay in the RIP or 16 bit print plugin and not insert QU into the loop.

Regards,
Mike

XPS drivers consist of two modules: a printer driver and an XPS document interpretter.  The printer driver is like any other Windows driver (8 bits/channel).  The XPS part is basically an interpretter that takes the XPS document format and creates a print job based on what amounts to XML (text) commands.  You can think of XPS as a sort of frontend to a RIP.  The XPS module can print 16 bits/channel but it is not a "printer driver" in the usual sense.  If you use any program to access the normal Windows "File", "Print" command, you are getting a standard printer driver that has nothing to do with the XPS part.  The XPS module is accessed via special plugins beyond the driver.

Mike

QI is a wonderful program for printing, but I also use it as a front-end RAW (NEF) processor / developer for other photo editing programs when more complicated editing is desired. It would be really nice if the option to save / convert an image as a 16 bit uncompressed TIF file was available.  Considering that the backend of QI is already a 16 bit process, it sounds as if this would be doable.

Thank you, Charlie

ProPhoto is just too large to be useful on any currently available output device and is only really needed when starting with linear or "raw" data for editing, so I would use 16 bit in DDI color space or even Adobe RGB when saving developed/final photos.  That's why I like just developing the raw in QU: it uses the color space of the camera (sensor) and there's no need to convert to an intermediate "image space".  You can use the full range of the camera's sensor without needing to save in 16 bits because you're not trying to fit all cameras/sensors into one big general "bucket".  When you convert a raw to a TIFF in QU, you get an 8 bit/channel TIFF but it is one that is not converted: it is simply tagged with the camera's color space so it makes maximum use of the 8 bits/channel by having a "bit bucket" just big enough to hold the specific color space dictated by the camera sensor's response curves.  By maintaining the camera sensor's color space, you don't need 16 bits/channel because you didn't have to save it in a bucket that was much bigger than it needed to be, i.e. ProPhoto RGB.

But if you use software that doesn't have camera profiles (Lightroom), you should be fine using Adobe RGB or the dRGB or pRGB that comes with QU if you want something just a little bigger than Adobe RGB.

Mike