Mike Chaney's Tech Corner
November 29, 2020, 01:42:55 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Feb 2013: Qimage Ultimate Challenges... have fun and explore features!
  Home Help Search Login Register  

Download and develop photos from your flash cards with one click!
Get a trial of
FlashPipe today and stop fumbling with explorer windows to transfer photos and videos
  Show Posts
Pages: 1 [2]
16  Mike's Software / Qimage Ultimate / Re: On the subject of 16-bit/channel, internal workings on: May 03, 2014, 08:28:14 AM
Not to get off topic, but will the Beta RGB workingspace open in Photoshop?

Hi David,

Yes, should be no problem. Depending on your OS version, just make sure that Beta RGB (or pRGB, Printer RGB) is installed (right-click the profile and click Install, or copy/paste it) in the required location(s) so that Photoshop also picks it up, and it can also be embedded in a TIFF so it should be picked up by other systems.

17  Mike's Software / Qimage Ultimate / Re: On the subject of 16-bit/channel, internal workings on: April 30, 2014, 04:11:31 PM
BTW, what kind of gamma, 2.2 - 1.8 - x.x does it have?4, 600+ inkjet media white spectral plots.

Hi Ernst,

It has (16-bit) gamma 2.2 TRCs, just like BetaRGB and AdobeRGB. Oherwise it is somewhat similar in gamut trade-offs to BetaRGB.

18  Mike's Software / Qimage Ultimate / Re: On the subject of 16-bit/channel, internal workings on: April 29, 2014, 06:04:04 PM
Color space conversion is always done last.

Super. No cutting of corners for speed reasons, but rather quality, first and last.

You can also use pRGB which is included with Qimage Ultimate.  pRGB is a color space specifically designed to be able to encompass the gamut of any inkjet printer, even those with expanded inks.

Indeed, I forgot about that one.

The color gamut of pRGB is somewhere in between that of Adobe RGB and ProPhoto and it's small enough to be used with 8 bit/channel images without posterization.

Mike, thanks again.

19  Mike's Software / Qimage Ultimate / Re: On the subject of 16-bit/channel, internal workings on: April 29, 2014, 04:25:36 PM
Hi Bart,

To put it as simply as possible, all operations performed after the image is loaded are 8 bits/channel.  That means if you have a 16 bit/channel TIFF that you worked in PhotoShop or some other raw converter (for example), the moment it is opened in Qimage Ultimate, it is converted to 8 bits/channel to be compatible with Windows display and printer drivers and Windows graphics API's.

Hi Mike,

Thanks for clarifying that. It's pretty much what I expected, just wanted some confirmation.

Keep in mind that all operations performed in Qimage Ultimate's raw refine tool are 16 bits/channel and the raw refine tool never converts to 8 bits/channel.  This is because when in raw refine, you are working on the image as it stands before it is actually loaded by the main software code.  My suggestion when working on raws is to work your raws in Qimage Ultimate.  You'll get all the benefits of 16 bits/channel when working on white balance, exposure, fill light, and HDR in the QU refine window and you'll likely get better results much faster/easier than you would in another raw converter anyway because QU "sees" more of what is going on in the raw and automatically takes care of 95% of all editing that will be required in other software.

All understood, and it makes sense. Unfortunately, my workflow can get very complex (incl. Focus stacking, Exposure fusion, and Panostitching those).

That said, if you must manipulate the raw in other software and you plan on editing in 16 bits/channel, just be sure to complete your editing and don't leave any major editing left on the table.

Clear. Unfortunately, when multiple output profiles are needed (for different media), it is just too practical to use Qimage for also that last number crunching operation called colorspace conversion and resampling to the native printer driver resolution, which will then be in 8-bit/channel space. I assume colorspace is converted first, then resampling is done?  As said, rarely an issue, but it might be in some rare smooth gradient situations.

I'd also suggest using Adobe RGB even when saving in 16 bits/channel.  This is because ProPhoto is much larger than necessary while Adobe RGB is only very slightly smaller than your printer's gamut, with only a small peak in mostly the yellow and magenta areas that Adobe RGB can't reproduce.

Remember that your printer only needs to be able to reproduce the color gamut that both your camera sensor combined with your printer inks/paper can reproduce.  And that happens to match Adobe RGB pretty well so no need to go overboard and use a bloated gamut like ProPhoto RGB.

Yes, ProPhoto RGB is humongous, not only does it exceed any current output gamut capability, it is also revealing to know how little actual image data of the full output media's gamut is actually present in most images, except for the most saturated cases (like some flowers). That's why I often use the Beta RGB workingspace (http://www.brucelindbloom.com/index.html?BetaRGB.html) as a slightly more reasonable sized gamut colorspace. It's much less likely to cause quantization related issues, and still offers more color resolution than Adobe RGB does.

Thanks for your help.

20  Mike's Software / Qimage Ultimate / On the subject of 16-bit/channel, internal workings on: April 29, 2014, 08:28:36 AM
Hi folks,

I know about the general Qimage approach towards the handling of 16-b/ch file input. And Indeed, it is only in rare situations that a difference between 8-b/ch and 16-b/ch input, will lead to visible differences in output. Added to that is the difficulty to actually print through a 16-b/ch pipeline, due to operating system / printer driver limitations.

My question is more about the order of conversions, and probably only Mike is able to answer that but maybe I failed to find the post (I did search) where it was explained before.

Assuming we have an input file, coming from a competent (14-bit ADC or better) camera, which is Raw-converted and additionally worked on in a competent Photo-editing application, in a working-space that's a bit on the large size, say ProPhoto RGB, because a lot of image manipulation might push saturation beyond the limits of Adobe RGB. We now have a 16-bit/channel file with relatively large quantization steps to fill the ProPhoto RGB gamut for some colors, and largely unused space for other colors.

Now, what happens when we open such a file in Qimage?
1. Is it already truncated/rounded to 8-bit/channel upon opening, or does the original precision remain available (or is retrieved again when needed) until after later Color Space conversions?
2. When re-sampling (usually deferred until actual printing, unless the editor is used to interpolate first), is that based on the original 16-bit (possibly truncated/rounded) precision, but the result is in 8-b/ch precision?
3. The conversion to the output profile, is that done prior to up-sampling, or after up-sampling.

Number 1 may cause issues when we interpolate notably smooth gradient transitions, although the interpolation itself may be smooth. Number 2 would probably require re-reading the original data, when the moment arrives that it's needed, but the result could again be held as 8-bit/channel data. Number 3 is potentially the biggest issue, especially with large gamut original image data. Conversion from one colorspace to another can be considered a major image editing operation, and we know that large gamut colorspaces like ProPhoto RGB is best used in 16-bit/channel mode if major editing is yet to take place. That is because the huge quantization steps in a large gamut space, may not map nicely to a smaller quantization step size, especially when only 8-bits/channel are available. That's why perhaps dithering is required to hide the errors (does Qimage/LCMS apply dithering?).

So, I'm basically looking for the moment of 16-b/ch conversion to 8-b/ch, and the moment that the profile conversion is done, before or after 16-8-bit conversion. Any help and profound insight into the inner workings of Qimage would be appreciated.

Bart (A long time user of Qimage, since 2001)
Pages: 1 [2]
Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!