# White Balance/Color Space Questions on VueScan DNG & TIFF Files



## Replytoken (May 14, 2020)

After reading both the User's Guide and The VueScan Bible, I am now trying to set up VueScan to give me files that I can both use as digital masters and for any post-processing in LR.  The issue that I am trying to better understand is how VueScan's raw file in DNG format differs from an outputted TIFF file with respect to White Balance in LR.  The DNG raw file shows me the standard White Balance options for a raw file with the temperature scale displaying the color temperatures.  The TIFF file that was outputted shows me the scale that is used with jpeg files and displays a scale from -100 to +100.  This makes full sense to me if I was working with a raw and jpeg files from a camera, but I am a bit uncertain about what I am actually gaining from VueScan's DNG raw file format with respect to white balance.  Is this file more malleable (like a raw file) when it comes to setting white balance, or is it just displaying the color temperature scale because the file is in DNG format, and it doesn't actually offer me any more leeway that the TIFF output file?  I know that the Color Balance setting in VueScan on the Color Tab seems to impact one of the two files (the TIFF I am assuming) as they appear different.  I have no objections to working in the DNG format for the master file, but TIFF is a bit easier if I end up sharing the files with people.

Also, one related question regarding Output Color Space.  The usual choices are available (including sRBG, Adobe RGB and ProPhoto RGB).  I am normally used to working with raw camera files that have no assigned color space and I just assign a space to any derivative file on export, but I am not sure what would be a good color space to assign to these files.  I plan on processing them in LR, but they are also master files and it would be nice (but not absolutely necessary) if they were readable outside of LR should they be shared without any LR processing.

Any thoughts?

--Ken


----------



## clee01l (May 14, 2020)

I'm not sure what VueScan is creating as an output image file.  DNG can contain RAW data or it can Contain an RGB image in the data block.  RAW data has not color space since it in not RGB data and will not get a colorspaces assigned until converted to RGB.  With TIFF you will always have RGB data in the data block.   Further, the DNG standard is based on the TIFF/EP6 standard.   

An RGB image file must have a color space assigned and used to define the limits of the color pixels. IF your DNG output file requires a Color space choose the largest gamut available. 

Lightroom Classic will always use ProPhotoRGB and Photoshop can use ProPhotoRGB as a Working colorspace. 

For Exporting you need to create a derivative idol in the colorspace for the output medium.  For scree the generic sRGB color profile is used but more and more monitors are AdobeRGB capable.  However Browsers will often limit to sRGB on display.    For Prints,you should assign the generic AdobeRGB to a specific color profile to match the printer and the paper to be used.      You would always want to use. the widest gamut for the job  noting that any color pixels that fall outside of the color gamut of the media may not display well.


----------



## Johan Elzenga (May 14, 2020)

When we talk about ‘raw data’, we usually mean the kind of raw data that are produced by a camera with a Bayer filter, so data that still have to be demosaiced. A scanner does not produce that kind of data, because it uses a linear CCD with three rows of pixels, one row for each color. The CCD moves along the image, so the scan will contain full RGB data for each pixel. You can still have ‘raw’ data in this case, but these are like the ‘raw’ panorama DNG files that Lightroom can produce.


----------



## Replytoken (May 14, 2020)

clee01l said:


> IF your DNG output file requires a Color space choose the largest gamut available.
> 
> Lightroom Classic will always use ProPhotoRGB and Photoshop can use ProPhotoRGB as a Working colorspace.
> 
> For Exporting you need to create a derivative idol in the colorspace for the output medium.  For scree the generic sRGB color profile is used but more and more monitors are AdobeRGB capable.  However Browsers will often limit to sRGB on display.    For Prints,you should assign the generic AdobeRGB to a specific color profile to match the printer and the paper to be used.      You would always want to use. the widest gamut for the job  noting that any color pixels that fall outside of the color gamut of the media may not display well.



Hi Cletus,

I had considered saving the TIFF file with ProPhoto RBG as it is what LR uses, but as I almost always work with raw camera files that have no color space assigned, I did not if there was a file difference in data if VueScan saved the file in ProPhoto vs AdobeRGB, for example, or if the assignment of a space was just a matter of convenience.  I do export all derivatives into the appropriate color spaces (usually sRGB) so there is no confusion when they are used by others.

--Ken


----------



## Replytoken (May 14, 2020)

Johan Elzenga said:


> When we talk about ‘raw data’, we usually mean the kind of raw data that are produced by a camera with a Bayer filter, so data that still have to be demosaiced. A scanner does not produce that kind of data, because it uses a linear CCD with three rows of pixels, one row for each color. The CCD moves along the image, so the scan will contain full RGB data for each pixel. You can still have ‘raw’ data in this case, but these are like the ‘raw’ panorama DNG files that Lightroom can produce.


Hi Johan,

This is kind of what I was wondering.  In this case, does this "raw" DNG file actually then have a color space?  And is the really any difference in how the White Balance temperature reads with respect to IQ when making the adjustment?  For example, in a real camera raw file, the white balance temperature is not fixed and can be adjusted by the user using the color temperature scale.  With a jpeg, the white balance temperature is fixed, and while the image can be "adjusted" (-100 to +100), the user is not actually changing the white balance color temperature.  I may be "changing' the WB temperature on the DNG file because that is the scale that LR provides me, but in reality it is not different than if the other scale (-100 to +100) was provided and all I was doing was making an adjustment to the file like a jpeg since this is not raw data from a sensor.

--Ken


----------



## clee01l (May 14, 2020)

Replytoken said:


> Hi Cletus,
> 
> I had considered saving the TIFF file with ProPhoto RBG as it is what LR uses, but as I almost always work with raw camera files that have no color space assigned, I did not if there was a file difference in data if VueScan saved the file in ProPhoto vs AdobeRGB, for example, or if the assignment of a space was just a matter of convenience. I do export all derivatives into the appropriate color spaces (usually sRGB) so there is no confusion when they are used by others.
> 
> --Ken



I hope that you are not thinking that the DNG format from the VueScan is RAW photosite data. As Johan has indicated that it is RGB pixel data in a DNG wrapper. 


Sent from my iPad using Tapatalk


----------



## Replytoken (May 14, 2020)

clee01l said:


> I hope that you are not thinking that the DNG format from the VueScan is RAW photosite data. As Johan has indicated that it is RGB pixel data in a DNG wrapper.
> 
> 
> Sent from my iPad using Tapatalk


No, I know better than that.  But, I did not know if what "raw" data from a CCD sensor exactly looked like, and Ed Hamrick's explanations are not that helpful.  But, as I touched upon in my response to Johan, it does make me wonder what causes LR to offer up one white balance scale vs. the other.  I can understand a camera raw vs. a jpeg, but if one puts this scanner "raw" file (a TIFF) in a DNG wrapper, is that enought for LR to offer up the same temperature scale that it offers up with camera raw files?  And how does that scale and operation differ from the scale that it offers up for jpeg files?

In short, is there any benefit to outputting these DNG "raw" files rather than just plain TIFF files for post processing in LR, especially when it comes to correcting faded or shifted prints?  The White Balance dropper seems like the ideal tool to address this issue, but perhaps there is another method that I am not considering?

--Ken

P.S.  Bridge shows the DNG "raw" files as untagged.  And EXIFTool (GUI) says that these files are 16/16/16 linear raw.


----------



## Johan Elzenga (May 14, 2020)

I don’t know all the technical details, but these files could indeed be raw, meaning they are the pure sensor data. The fact that these data contain values for R, G and B does not make that impossible. Raw files from a Foveon/Sigma sensor also contain R, B and B values, and still they are raw. They will definitely be linear, because sensors are linear. I’m not sure what this means for the white balance, but panorama DNG files also do not seem to have a white balance yet.


----------



## BarrySchwartz (May 14, 2020)

Perhaps you already know this, but among the advantages of using DNG - like any RAW file - is that you can always start over from the beginning, with no losses (other than your settings, of course), since the files are never locked down.  I've gone back to images I took 15 years ago and improved them to an amazing degree.  LR and many kinds of software get better every year,  the computers get faster, and practice helps, too.

If you are comfortable with HDR, you can make virtual copies of a DNG, process them three different ways, and combine, in order to get a remarkable amount of dynamic range.   You can, of course, do this with any file, but DNGs allow a lot more latitude.

As for printing, I've printed many times directly from a DNG to my Canon printer with great results.  Both my monitor and printer have been profiled, which makes that possible.  For images that will be printed by someone else, I'll output as sRGB JPGs at 300 ppi and that works very well.


----------



## Johan Elzenga (May 14, 2020)

BarrySchwartz said:


> Perhaps you already know this, but among the advantages of using DNG - like any RAW file - is that you can always start over from the beginning, with no losses (other than your settings, of course), since the files are never locked down.


That is the same for any type of image in Lightroom. Lightroom edits are non-destructive, regardless of the file type.


----------



## Conrad Chavez (May 14, 2020)

The info below is not definitive, but just some of my conclusions from using VueScan for many years:

*VueScan raw:* Just to be clear, even though some VueScan users here might already know this, VueScan has a "raw" scan option that predates camera raw formats and is not the same. In VueScan terminology, a "raw" scan means no VueScan processing is applied, and it’s an RGB image since it’s a scan, not camera raw sensor data. The nice thing is you can reload a VueScan raw into VueScan and then apply its processing settings, as if you were scanning the original. So you can do things like scan to VueScan RGB raw + the infrared defect channel (4 channels total), walk away for a week, come back, load up that file, and process it including hardware-based defect removal without the scanner even being present. Basically, VueScan "raw" allows reprocessing without having to rescan.

*VueScan raw vs DNG:* VueScan raw is an RGB TIFF with no processing applied, VueScan TIFF DNG is a TIFF in a DNG wrapper. The TIFF will come into Lightroom Classic with White Balance defaulting to 0 (As Shot) like a JPEG, but the DNG shows a default white balance of Temp 6500K Tint +10, like a raw file. I do not know if that’s because I usually set VueScan white balance to Neutral because I want to make the adjustment in Lightroom Classic, but I interpret that as VueScan assuming a scan was shot with daylight balanced film. I am not technically sure if there is any difference in how white balance is recorded, but anecdotally, I've moved to DNG because I thought the white balance adjustments in Lightroom Classic looked better if I saved from VueScan as DNG, especially for old film with uneven fading that misleads white balancing algorithms. But this needs more objective testing.

*Color space:* By default I don’t think a VueScan scan has a color space, since a scanner sensor doesn’t match up with any of the standard ones like sRGB. I see the Output Color Space option in the Color tab as working like the Color Space option found in Lightroom Classic Export options or the Adobe Camera Raw Workflow/Save options. In other words, it is a profile assigned to and embedded into the final saved image file. (A VueScan scan _can_ have a default color space if you have profiled the scanner and loaded that profile  into VueScan using the Scanner ICC Profile option in the Color tab; in that case I believe VueScan would instead assign the scanner profile to the scan while you work on it in VueScan, and then convert the scan to the Output Color Space profile on the way out.)



Replytoken said:


> Also, one related question regarding Output Color Space...I am not sure what would be a good color space to assign to these files.  I plan on processing them in LR, but they are also master files and it would be nice (but not absolutely necessary) if they were readable outside of LR should they be shared without any LR processing.


Personally I set the Output Color Space to ProPhoto RGB because they’re film scans that I save as 16 bits per channel, because I want to get as much color quality as I can off the film. But it is possible that Adobe RGB would be just fine, especially if they were all scans of prints from a commercial (not pro) lab being saved as 8 bits per channel. In other words, it depends on the color range of the originals being scanned and the quality of the scanner’s sensor; if you think both can represent a wide color gamut you’re more likely to want to use ProPhoto RGB. Like if you were using a very good scanner on a pro lab print. But I haven’t looked into, for example, the potential color gamut of a Cibachrome vs. consumer Kodak print vs. color negative film like Portra.

If it’s a family archive mostly shot on consumer film and papers, and you want it to be immediately shareable, then sRGB would be fine. But to support being shareable by any family member using simple photo software, you would probably also want the scans saved as TIFF or JPEG rather than DNG. If you go that direction, then it follows that you want to get good at having VueScan process the scans to be acceptable quality without further processing, in case they get shared as is outside of Lightroom.


----------



## Johan Elzenga (May 14, 2020)

BarrySchwartz said:


> If you are comfortable with HDR, you can make virtual copies of a DNG, process them three different ways, and combine, in order to get a remarkable amount of dynamic range. You can, of course, do this with any file, but DNGs allow a lot more latitude.


The data inside the DNG determine the dynamic range, not the DNG wrapper.


----------



## Conrad Chavez (May 14, 2020)

BarrySchwartz said:


> Perhaps you already know this, but among the advantages of using DNG - like any RAW file - is that you can always start over from the beginning, with no losses (other than your settings, of course), since the files are never locked down.


While true, that doesn’t apply to a VueScan+Lightroom discussion because DNG is not necessary to be able to start over with that workflow.

As stated above, if you wanted to be able to "re-scan" in the future, possibly with different settings, without actually having to rescan, you use VueScan raw format, and you now have nondestructive reprocessing. And with Lightroom, any format gets nondestructive processing, so you can also start over at any time from that perspective. The question we’re working through here is, what difference does DNG make specifically within a scanning workflow involving VueScan going to Lightroom?


----------



## Replytoken (May 14, 2020)

Johan Elzenga said:


> I don’t know all the technical details, but these files could indeed be raw, meaning they are the pure sensor data. The fact that these data contain values for R, G and B does not make that impossible. Raw files from a Foveon/Sigma sensor also contain R, B and B values, and still they are raw. They will definitely be linear, because sensors are linear. I’m not sure what this means for the white balance, but panorama DNG files also do not seem to have a white balance yet.


I am still researching this and have come across a number of discussions about VueScan's "raw" file options.  I am not nearly done with the reading, but a theme is starting to appear.  The advice being offered is to just save a standard 48-bit TIFF file in ProPhotoRGB.  Unless you are planning to run the raw files back through VueScan, which was probably the primary point of the file format so a physical re-scan is not needed, then the value in a program like LR sounds quite limited.

More to the point about LR, it does make me want to know more about the different modes of White Balance and how they differ, or if they differ at all (I.e. just the scale changes from color temperature to -100/+100, but the file type drives the results, not a change in the behavior of LR).

--Ken


----------



## Replytoken (May 14, 2020)

Conrad Chavez said:


> While true, that doesn’t apply to a VueScan+Lightroom discussion because DNG is not necessary to be able to start over with that workflow.
> 
> As stated above, if you wanted to be able to "re-scan" in the future, possibly with different settings, without actually having to rescan, you use VueScan raw format, and you now have nondestructive reprocessing. And with Lightroom, any format gets nondestructive processing, so you can also start over at any time from that perspective. The question we’re working through here is, what difference does DNG make specifically within a scanning workflow involving VueScan going to Lightroom?


Bingo!

--Ken


----------



## Conrad Chavez (May 14, 2020)

I forgot to mention that in the VueScan Help page for the Color tab, the description for the Output Color Space says:


> The Output color space is used when writing images to JPEG, TIFF, PDF and Index files.


If that’s up to date, then it means no color space is assigned to a VueScan DNG file, I guess? So Lightroom Classic would just bring it in, assume the color is “mystery meat” (color management technical term for an untagged image  ), and assign its internal color space (Melissa RGB) for editing.


----------



## BarrySchwartz (May 14, 2020)

While it is true that Lightroom editing is always non-destructive, if you want to re-process an image from the beginning in any other editor - and there are a large number of other ones, and growing, then having a DNG at your disposal enable this.  As a professional photographer, it is super important that I maintain flexibility in my images, including, in particular, my legacy images, since they may be used for secondary licensing, or even simply printing or posting on my portfolio website.  Having read this, I do approximately 80% of my work in LR, and have often delivered DNGs that were exported as JPGs without ever leaving LR.

As for HDR processing using 3 copies of the same image, images can get really ugly trying to push a single image around, where working on highlights and shadows in copies or virtual images on "either side" of the original image can make all the difference.  And it's super easy to do.  This of course does not work using LR HDR, but works great using plugins, such as Enfuse.  Again, as a professional, I have to deliver a good image no matter what, and anything that increases my capabilities is a good thing.  The clients don't care how I get there, they just want what they are paying for.


----------



## Johan Elzenga (May 14, 2020)

Barry, if working this way gives you an advantage, then by all means do that. But don’t believe in micracles. Merging three edits of the same raw image does not increase the dynamic range. The resulting ‘HDR’ will have the exact same dynamic range as the original.


----------



## BarrySchwartz (May 14, 2020)

There's no miracle here.  It works for me because the primary plugin I use, Enfuse, allows me to do extreme editing on each image and still blend them together.  For instance, I can use a brush to change anything, change the temperature and clarity and noise reduction globally, all kinds of things, and get results that otherwise would require me to export three TIFs, then reimport them back into LR, and then do HDR.  This way, I can quickly blend three images and get a good result.  Typically, I don't have work on copies of the same image, since I typically bracket my shots, but if there are plants or trees and any wind at all, I'm going to have big problem getting blends using any HDR software of any kind.

While mostly shoot architecture, I also do documentary work and portraits, often cannot light, and those subjects are not stock-still, meaning I cannot bracket, so this process is critical to getting a good result.

Time is money (and can equal emotional stress!). Even more, I can make multiple attempts to get a good image without leaving LR until I get it right.  No less, you can push around the pixels in a RAW file in ways that won't work as well in a TIF or PSD (which is what I  process my architectural images in).   I shoot a 5D S R, which produces a 50 MGB file, which is reasonably large.  Even using my late-model, jacked-up MacBook Pro and viewing on a monitor, when the DNG is exported as as TIF or PSD, I'm looking at 300-400 MGB 16-bit file, so working with a smaller file is a lot easier and faster.  This workflow may not work for everyone, but I do virtually all my own post, so it works for me.


----------



## Johan Elzenga (May 14, 2020)

I’m sure this workflow suits you, and I have no comment on the workflow itself. But it has nothing to do with DNG. DNG is just a wrapper. It’s like an envelope. What matters is the letter inside, not the envelope. A JPEG that is exported from Lightroom as a DNG is still 8 bit data, wrapped in DNG. Same for anything else you wrap in DNG.


----------



## Replytoken (May 15, 2020)

Conrad Chavez said:


> I forgot to mention that in the VueScan Help page for the Color tab, the description for the Output Color Space says:
> 
> If that’s up to date, then it means no color space is assigned to a VueScan DNG file, I guess? So Lightroom Classic would just bring it in, assume the color is “mystery meat” (color management technical term for an untagged image  ), and assign its internal color space (Melissa RGB) for editing.


I am thinking that we may need to establish a new RGB in your honor called CCMMRGB (Conrad Chavez's Mystery Meat RGB) for those special occasions! 

I did do more research, but first your post does raise the question of how much color gradation is lost if I decide to use a regular TIFF format and assign a color space like AdobeRGB instead of ProPhotoRGB if my exported derivatives will mostly be sRGB jpeg files?

I did finish reading all of the materials that I decided to look at and I think that this thread best sums up the discussion at hand on the various VueScan file formats - Vuescan File Formats: "RAW DNG" vs. "TIFF DNG" - Rangefinderforum.com .  It is quite an interesting read, and it leaves me leaning toward outputting a plain, 48-bit TIFF file.  My assumptions are that regardless of which LR White Balance scales I get (color temp vs -100/+100), the impact is going to be the same regardless of VueScan's TIFF/Raw/DNG options because this is not a true raw file.  And, I am not really interested in reprocessing the file in VueScan later so keeping it in a file format for that purpose has very little value to me.

But, that does raise the final question of whether I should let VueScan set both the Black/White points and the color balance before generating the TIFF file.  I would prefer to do this work in LR, but I am not sure if it is better to do these upstream.

--Ken


----------



## PhilBurton (May 15, 2020)

BarrySchwartz said:


> Perhaps you already know this, but among the advantages of using DNG - like any RAW file - is that you can always start over from the beginning, with no losses (other than your settings, of course), since the files are never locked down.  I've gone back to images I took 15 years ago and improved them to an amazing degree.  LR and many kinds of software get better every year,  the computers get faster, and practice helps, too.


Is it also possible to treat a scanner TIFF file as the "negative" and perform non-destructive edits?

To generalize my question, how much additional value is there for a scanner RAW file as opposed to a scanner TIFF file?



> If you are comfortable with HDR, you can make virtual copies of a DNG, process them three different ways, and combine, in order to get a remarkable amount of dynamic range.   You can, of course, do this with any file, but DNGs allow a lot more latitude.
> 
> As for printing, I've printed many times directly from a DNG to my Canon printer with great results.  Both my monitor and printer have been profiled, which makes that possible.  For images that will be printed by someone else, I'll output as sRGB JPGs at 300 ppi and that works very well.


----------



## LouieSherwin (May 15, 2020)

Conrad Chavez said:


> Personally I set the Output Color Space to ProPhoto RGB because they’re film scans that I save as 16 bits per channel, b



Scanners are like any other RBG device in that the color measurements are unique to each device. So in order to get the most accurate color rendition from you scans you will need to create a device specific color profile. This is possible only for color pictures (reflective) or slides (positive film). 

There are a number of scan targets available from places like Chromix.com that can be used for this purpose. Using any of these  will be better than simply assigning a random color space. If I were to simply assign a color space I would be inclined to use either sRBG or Adobe RGB as the gamut is going to be closer to the gamut of the scanner.

Unfortunately it is not possible to profile color negative film due to the orange mask. This is why for example VueScan includes an extensive library of "Film Types" that help make appropriate corrections. 

-louie


----------



## Replytoken (May 15, 2020)

LouieSherwin said:


> Scanners are like any other RBG device in that the color measurements are unique to each device. So in order to get the most accurate color rendition from you scans you will need to create a device specific color profile. This is possible only for color pictures (reflective) or slides (positive film).
> 
> There are a number of scan targets available from places like Chromix.com that can be used for this purpose. Using any of these  will be better than simply assigning a random color space. If I were to simply assign a color space I would be inclined to use either sRBG or Adobe RGB as the gamut is going to be closer to the gamut of the scanner.
> 
> ...


Color fidelity can truly be the rabbit hole of rabbit holes at times!  I would never deny color fidelity's importance, although I admit to being slow at re-calibrating my monitors sometimes, but some days it seems like the choices and options never seem to end.  I had assumed, and I believe that Cletus also suggested, that it would be advisable to select a large color space like ProPhoto as a working color space for the files I am creating since they will be processed in LR.  But, I am not sure how to reconcile that with your suggestion to pick a color space as close to the gamut of the scanner, which also seems advisable.

I have spent the better part of the past few months trying to establish a reasonable work flow for this project, and it seems like every time I think that I have all of the boards nailed down, one seems to either pop up or appear loose.  What is completely ironic is that while I believe in trying to achieve the best color fidelity possible, I am also struggling with how I should be presenting the photos that I have scanned.  Some have faded, some are tinted, some may need color restoration and some are a combination of all of these issues.  I keep looking at the B/W test image I am using which has a very slight sepia tone to it (most likely from aging), and I cannot decide if it is better to present it as such or use use white balance tools to make it look white (again?).  In short, unlike an image that I shot and know what it should look like, or what I want it to look like, I am having to make decisions about images that I have no knowledge of with respect to color fidelity.

I was hoping to do the best I could given the materials I am working with (as there are limits to what can be extracted from old photos) to make some digital master files for the family, without regretting my technical choices in the future, but I am starting to wonder which decisions will prove to be more material than others.  This situation reminds me of an expression that a wise person once shared with me - ignorance is bliss, no wait, I meant to say that ignorance was bliss.  I am not ignorant of color fidelity, nor do I wish to be, but being aware of all of the possible choices for this project is anything but blissful.

--Ken


----------



## Replytoken (May 15, 2020)

LouieSherwin said:


> Scanners are like any other RBG device in that the color measurements are unique to each device. So in order to get the most accurate color rendition from you scans you will need to create a device specific color profile. This is possible only for color pictures (reflective) or slides (positive film).
> 
> There are a number of scan targets available from places like Chromix.com that can be used for this purpose. Using any of these will be better than simply assigning a random color space. If I were to simply assign a color space I would be inclined to use either sRBG or Adobe RGB as the gamut is going to be closer to the gamut of the scanner.


I was thinking more about this after my post.  VueScan asks you to set a scanner space color (either Default or a custom ICC profile) as well as set the output color space, so if my thinking is correct, then it should not necessarily be a bad idea to export into a large color space as VueScan does have some point of reference as to the scanner's working color space before it assigns the export profile.  Ideally it would great if I created my own ICC profile, but assuming the Default that VueScan offers is reasonable, is there something that I am not considering here?

--Ken


----------



## Replytoken (May 14, 2020)

After reading both the User's Guide and The VueScan Bible, I am now trying to set up VueScan to give me files that I can both use as digital masters and for any post-processing in LR.  The issue that I am trying to better understand is how VueScan's raw file in DNG format differs from an outputted TIFF file with respect to White Balance in LR.  The DNG raw file shows me the standard White Balance options for a raw file with the temperature scale displaying the color temperatures.  The TIFF file that was outputted shows me the scale that is used with jpeg files and displays a scale from -100 to +100.  This makes full sense to me if I was working with a raw and jpeg files from a camera, but I am a bit uncertain about what I am actually gaining from VueScan's DNG raw file format with respect to white balance.  Is this file more malleable (like a raw file) when it comes to setting white balance, or is it just displaying the color temperature scale because the file is in DNG format, and it doesn't actually offer me any more leeway that the TIFF output file?  I know that the Color Balance setting in VueScan on the Color Tab seems to impact one of the two files (the TIFF I am assuming) as they appear different.  I have no objections to working in the DNG format for the master file, but TIFF is a bit easier if I end up sharing the files with people.

Also, one related question regarding Output Color Space.  The usual choices are available (including sRBG, Adobe RGB and ProPhoto RGB).  I am normally used to working with raw camera files that have no assigned color space and I just assign a space to any derivative file on export, but I am not sure what would be a good color space to assign to these files.  I plan on processing them in LR, but they are also master files and it would be nice (but not absolutely necessary) if they were readable outside of LR should they be shared without any LR processing.

Any thoughts?

--Ken


----------



## LouieSherwin (May 16, 2020)

Hi Ken,

Yes it sounds like the  VueScan  Default Scanner color space is making a best guess of what an "average scanner" colors would be. So exporting the scan into another color space Pro Photo RGB for example would carry forward that "best guess" in to Pro Photo RGB. That is a big difference than simply assigning Pro Photo RBG to the resulting scan which would probably produce all sorts of undesired color shifts. 

So if using the generic VueScan scanner input profile (the default) is producing acceptable results no need to pursue a custom profile. 

I would be inclined to try to profile my scanner for reflective scans if I had an IT8 target. Good inexpensive ones are available from here Targets coloraid.de. However, they are not currently shipping to US due to COVID-19 postal restrictions. <sigh>

-louie


----------



## Replytoken (May 16, 2020)

LouieSherwin said:


> Hi Ken,
> 
> Yes it sounds like the  VueScan  Default Scanner color space is making a best guess of what an "average scanner" colors would be. So exporting the scan into another color space Pro Photo RGB for example would carry forward that "best guess" in to Pro Photo RGB. That is a big difference than simply assigning Pro Photo RBG to the resulting scan which would probably produce all sorts of undesired color shifts.
> 
> ...


I agree.  I would like normally profile a scanner, but as this model is very inexpensive and is only being used for this project, I may end up buying an IT8 profile when I can, scan this unit, and then have the IT8 for when/if I upgrade to something like a V600 or V800.

Thanks,

--Ken


----------



## BarrySchwartz (May 26, 2020)

PhilBurton said:


> Is it also possible to treat a scanner TIFF file as the "negative" and perform non-destructive edits?
> 
> To generalize my question, how much additional value is there for a scanner RAW file as opposed to a scanner TIFF file?



Sorry for the late reply.  (Time seems to operate differently these days...)  As long as the image is in LR, it's non-destructive, so in that sense it's the same as a TIFF - but it's also a lot bigger, and does not contain the same capabilities as a RAW file for re-processing, since so much of the data is now locked down.  This also applies to a scanner as a RAW or TIFF.


----------



## BarrySchwartz (May 26, 2020)

Regarding color space: RAW files don't have a color space, so it's not a concern.  The converted files (JPG, TIF, PSD) need color spaces, and those depend on the eventual uses.  For the web, it should be sRGB JPGs at 72 ppi; that's current best-practice.  For sending to outside printers, sRGB is generally fine, but if the printer needs a wide color gamut, then Adobe RGB is the standard.  For your own printer, anything will work (with a caveat, following).  For processing further in Photoshop, for instance, ProPhoto at 16-bits, either as a TIF or PSD, gives the best results in terms of how much you can chew on image; roughly speaking, those color spaces at 16-bit allow for the best changes across tone and contrast.

For all these issues to work correctly, you have to calibrate your screen; that is 90% of color management.  It's easy and not terribly expensive to do.  If you do your own printing, it's best to calibrate or profile you printer; this will save a lot of money and time, not to mention emotional distress after looking at prints that don't resemble what you see on your screen.


----------



## Johan Elzenga (May 26, 2020)

BarrySchwartz said:


> For the web, it should be sRGB JPGs at 72 ppi


Forget the 72ppi. That is one of the most persistent misunderstandings. Resolution in ppi is irrelevant on the web.


----------



## BarrySchwartz (May 26, 2020)

Respectfully, I have to disagree. While it is absolutely true that images will render OK at other resolutions, there are two reasons why I stick with 72ppi.  The first, and most important for me as a professional, is that 72ppi limits how my images can used if they are stolen, and this is common for me and other professionals - a stolen image is a free image, and I like to choose who gets to use my images for free, since over time "free" is a very poor business model.    72ppi will not print well at anything other than a small size, whereas 300 ppi, which is what I deliver to clients will print well at that resolution, or even at half that resolution, if someone knows what they are doing.

The second reason is how web developers code for the best professional presentation of images, whether for an ad, or for a portfolio, which is that image files should load as fast as possible and look their best at whatever sizes they are supposed to render at. Advertisers also are sensitive to not having images they have paid to license be ripped off.

Any developer will admit that the 72 ppi standard is a legacy of the early web, but that's just the way things turned out, so they code for that, and the better portfolio sites also strongly suggest that's the best. Even Instagram suggests 72 ppi, if I'm not mistaken. So while 72ppi is not, strictly speaking, necessary, it is the standard for good and practical reasons.

So for non-professionals who don't have the kinds of considerations I have, or that advertisers have, any resolution will do - but sRGB as a color space applies for web presentation no matter what, if you want images to render as accurately as possible.


----------



## prbimages (May 27, 2020)

BarrySchwartz said:


> Respectfully, I have to disagree.


Respectfully, I have to disagree with your disagreement. Johan is (as usual) correct - the PPI setting is totally irrelevant. In your example, what will stop the photo thief from stealing your 72ppi image, loading it into Photoshop, and changing the PPI setting to 300? If all the pixels are there, then all the pixels are there and available to the thief, regardless of whether you've inserted the number "72" or any other number into the file (which is all you are doing when making that setting).

This is, however, off topic to this thread ...


----------



## BarrySchwartz (May 28, 2020)

My position on resolution is based on the practicalities of how images are used.

For instance, the images on my professional portfolio site are mostly 2000 pixels wide, each of them sRGB 72 ppi.  

2000 pixels wide at 72 ppi  = 27.7 inches.

If I convert that file to 300 ppi = 6.7 inches wide.

If the image was going to be used for print, this makes the print not very usable for anything above a postcard size; 300 ppi being the standard for delivering images files for commercial and fine art printing, and sometimes for editorial printing.  Of course the image could be printed larger than 6.7 inches, but if the photo is, for instance, a landscape or a building, with lots of high-frequency detail, the print detail will break down and it will not be an attractive print.  Even skin tones can get unpleasantly blocky.

If the image is only going to be seen on the web, all this is less of an issue.  But print is still a viable medium for fine art and commercial and editorial uses.  Those uses are not defined by myself, but by the contractual demands of my clients.  For commercial use - which can range from large posters to brochures, the size of the file - and the resolution - directly affects quality.  In editorial uses, whether the image is printed or appears online, the quality of the image is also important, because in both cases there is money on the line.

Money is one of the factors setting the standard for best practices, which is one of the reasons Adobe and other vendors pay attention to the professional market.  For which I'm very grateful!

So, for instance, if someone who sells images at an art fair steals one of my images off my portfolio site and tries to print it at anything larger than 6.7 inches, they are going to have a hard time making any money - which is exactly the result I hope for.  And that hope is based on industry standards designed to protect images that are stolen from being able to be monetized by people who do not pay a license to use that image, or by people who do not own the copyright, such as myself.

Obviously, for people who do not make a living from their photography, none of this matters, so I will admit it's a moot point as to how resolution affects image quality.


----------



## Johan Elzenga (May 28, 2020)

BarrySchwartz said:


> My position on resolution is based on the practicalities of how images are used.
> 
> For instance, the images on my professional portfolio site are mostly 2000 pixels wide, each of them sRGB 72 ppi.
> 
> ...


The point is that this is determined by the *2000 pixels image width*, not by the 72 ppi resolution. An image of 2000 pixels width @72 ppi is exactly the same as an image of 2000 pixels width @ 300 ppi or an image of 2000 pixels width @ 1,000,000 ppi. And internet browsers ignore the ppi value and show the three above mentioned images at exactly the same size. That is why ppi is totally irrelevant for the internet, period.

And if you do not believe me (you apparently don’t): The 72 PPI Web Image Myth - Photo Cascadia


----------



## BarrySchwartz (May 31, 2020)

Again, I do agree with you, as I stated earlier; mostly, resolution is not an issue on the web.   Where things are different is in the UX, or User Experience, for the intended audience.  

For instance, my portfolio host (PhotoFolio), is run by designers and developers who are focused on being up-to-date with best practices for posting photos on the web, so however they tell me  to format images, that's what I'll do.  And there is a good reason for that: those developers know that my audience are art buyers from advertising agencies and photo editors at publications who spend all day looking at hundreds of image every day, so their viewing experience better be first-rate.  If it's not, I am less likely to get hired (and so will the many other photographers on the site), with the result the developers will be out of a job - these are commercial considerations.  So, when they tell me my images need to be sRGB 72ppi, it's not because they don't know the reference above from Photo Cascade - which is an argument all professional photographers are well aware of - it is because their job as developers and designers is to optimize the viewing experience for people whose job is to scan large images in large numbers that render very fast one after the other that look as good  as possible. This is where resolution does make a difference, but it is situational.  I am not an engineer, but they are, and their reasoning is based on testing and industry best-practices.  I'm happy to take my lead from them.

Obviously, for most people, resolution, as you write, does not matter, and images posted at other resolutions than 72 ppi will look OK, but when you're in business of showing your images to potential buyers - as I am - these subtleties make a lot of difference.  It's a fine distinction, I will happily admit, but it is a distinction for good reasons.


----------



## Johan Elzenga (May 31, 2020)

Barry, the situation is simple. This is what you said earlier:



BarrySchwartz said:


> The first, and most important for me as a professional, is that 72ppi limits how my images can used if they are stolen, and this is common for me and other professionals - a stolen image is a free image, and I like to choose who gets to use my images for free, since over time "free" is a very poor business model. 72ppi will not print well at anything other than a small size, whereas 300 ppi, which is what I deliver to clients will print well at that resolution, or even at half that resolution, if someone knows what they are doing.



Maybe you now have found another reason to use 72 ppi and maybe that reason is even legitimate (I doubt it), but the above quote is what I reacted to. And that is why I said that this is a persistent myth. Setting the ppi value to 72 does not protect your images on the web any better that setting it to 1 ppi or 1,000,000 ppi. I am not going to add anything more to this discussion, because I would only repeat what I already said.


----------



## BarrySchwartz (May 31, 2020)

Johan Elzenga said:


> Barry, the situation is simple. This is what you said earlier:
> 
> Maybe you now have found another reason to use 72 ppi and maybe that reason is even legitimate (I doubt it), but the above quote is what I reacted to. And that is why I said that this is a persistent myth. Setting the ppi value to 72 does not protect your images on the web any better that setting it to 1 ppi or 1,000,000 ppi. I am not going to add anything more to this discussion, because I would only repeat what I already said.



I agree, I think we've about wrung this subject dry.  I will say that in my earlier responses I mentioned both printing issues as well as web-developer best practices. 

My larger point is not that technical realities don't matter - they are important to understand - it's more that technical aspects of photography or, really, any kind of image production, ultimately reflect of how images are processed and presented.

For instance, for me, one of the most thrilling aspects of digital photography has been the ability to process and print color images.  Black & white images were easy to produce when film was dominant, but color was expensive and could not easily or cheaply be processed and printed in a home office (or bedroom!).   Digital not only changed photography, it changed how commercial printing works; it is directly connected to the amazing proliferation of images on the web (which did not exist when film was dominant); it brought high quality photography to everyday products such as phones and point-and-shoots; and made high-quality printing possible for anyone to achieve.  Any of these uses of digital imagery requires different kinds of processing and different levels of quality.  There is no one-size-fits-all.    

But without a handle on some of the basics, there is only trouble and frustration.  Forums like this one, and the better books and teachers, have been invaluable to me as I learned how to learn, and learned what mattered and what does not, and why.


----------



## prbimages (Jun 1, 2020)

Well, thinking of people who may read this thread in the future, I hate to leave misinformation lying around - especially on one of the most respected and authorative informational websites on the internet. So:

Going back to your example of an image 2000 pixels wide, let's assume for the sake of argument that it's also 2000 pixels in height. So there are 4 million pixels in that image file (2000 x 2000). The _quality _of the image is determined solely by the quality (informational content) of the data in those 4 million pixels. Also contained in the image file will be some extra information about the image: possibly a copyright notice, possible camera metadata, etc., and possibly a DPI/PPI "resolution" setting. That resolution setting is just a single number tacked on to the rest of the data in the file. It is used as a _hint _(and it is really no more than a hint) in some scenarios to other programs that might want to process the file later on. You can set that DPI/PPI number to 72 or 300 or whatever you like when you export the file from Lightroom or Photoshop. But it has _exactly zero_ effect on the 4 million pixels of image data which is exported and stored in the file at the same time.

A web site and browser combination which wants to display your image will simply ignore that DPI/PPI number. All that a web server and browser want to know is what size of an image to produce to fit on your screen. If they determine that your image needs to be 1000 pixels square to fit on your screen, they will simply convert your 2000-pixel image down to a 1000-pixel image. This is a mathematical downscaling, by a factor of two. There is no need to know, or care about, the DPI/PPI setting, because it's _irrelevant_. Likewise your hypothetical image thief. If the thief can download your 2000-pixel image, then they've got your 4 million pixels of image information, exactly as you uploaded it. Just having the number "72" tacked on the end does nothing one way or the other. _All the relevant information is in the pixels_.

I don't understand how any of your discussion has any bearing on this _mathematical _outcome.



BarrySchwartz said:


> mostly, resolution is not an issue on the web


Resolution is _never _an issue on the web.


BarrySchwartz said:


> Where things are different is in the UX ...


Things are NOT different in the UX. If you think they are, you need to explain how.


BarrySchwartz said:


> This is where resolution does make a difference, but it is situational


Resolution does NOT make a difference. If you think it does, you need to explain how.


BarrySchwartz said:


> images posted at other resolutions than 72 ppi will look OK


Images posted at other resolutions will look exactly the same (see test images below).


BarrySchwartz said:


> these subtleties make a lot of difference. It's a fine distinction, I will happily admit, but it is a distinction for good reasons.


This "subtlety" makes no difference. What are these "good reasons" to which you refer?

*Here's a test.* Two images, both exported as JPGs from Lightroom at 600 pixels square, color space sRGB, compression factor 80. One of them exported with a resolution of 10 pixels per inch, the other at 1000 pixels per inch. Should be a big difference, wouldn't you think? I'm not telling you which is which. Can you _see _any difference? Download both files and open them in Photoshop. You can verify the PPI settings with the "_File Info ..._" facility. You will note that the files are _exactly _the same size on disk. In Photoshop, put one of the images on top of the other as a new layer, then set the blend mode of the uppermost layer to "Difference". This will highlight any differences between the two images. There will be none (this will be indicated by a completely black screen). The files are _identical _apart from the fact that one contains the number 10 and one contains the number 1000 in the PPI field.

Image A:



Image B:




You seem to put a lot of store in the recommendations of the PhotoFolio website. That's fair enough, as a general rule. I this case, I think they have just been lazy - when exporting, you need to put _some _number in the resolution box, so they probably figured "72 is as good as anything else, so let's just write that down so we don't get people contacting us all the time asking 'What PPI should I use?'"

Also worth noting is that web site recommendations, even on well-known photo sites, are sometimes wrong because they tend to be written by web designers who themselves do not understand the issues. Web designers are usually not computer scientists or engineers, they simply do things a certain way (probably the way they were taught) and repeat misinformation without thinking about it too deeply.


----------



## Replytoken (Jun 1, 2020)

I wish Adobe would have just left the Resolution box off the Export Dialog window in LR.  It is information that is mostly used by legacy software (for convenience) and is confusing at best, as in this discussion.  It s value as an instruction seems dated, especially in this era for 4k monitors.  If you are concerned about fast load times, then resize your images before posting.  If you are concerned about quality on high resolution monitors, then post high resolution images and encourage your viewers to use sites/software than does not compress the files.

Having looked at the Photofolio site and searched for the help/support pages, I found this: Batch Resize Images in Lightroom .  Note the following:



> Our normal image suggestions are 1860x1140px, but you can adjust the resolution or dimensions to fit your needs. We typically suggest keeping the file sizes in the 250 - 550 kb range, but you can use larger files. Keep in mind, the larger the file size, the slower the image will load on slower internet connections. Finally, select "Export" to resize & save the images.



--Ken


----------



## Johan Elzenga (Jun 1, 2020)

prbimages said:


> You seem to put a lot of store in the recommendations of the PhotoFolio website. That's fair enough, as a general rule. I this case, I think they have just been lazy - when exporting, you need to put _some _number in the resolution box, so they probably figured "72 is as good as anything else, so let's just write that down so we don't get people contacting us all the time asking 'What PPI should I use?'"


That was my idea too. Or they just believe the same myth. They would not be the first, or the last.


----------



## Philippe Coudé du Foresto (Jun 1, 2020)

> I wish Adobe would have just left the Resolution box off the Export Dialog window in LR.  It is information that is mostly used by legacy software (for convenience) and is confusing at best


I agree with you. However, if you set the image size in length unit (cm or inches), the PPI will be used by LR to calculate the image size (in pixels) of the exported image. Note that I don't see this useful either! Fixing the image size in length unit might be useful if you want to print it later. But in this case, It's better in my opinion to send the image full size and let the print service do the downsizing according to their printer capabilities...


----------



## Replytoken (Jun 1, 2020)

Philippe Coudé du Foresto said:


> I agree with you. However, if you set the image size in length unit (cm or inches), the PPI will be used by LR to calculate the image size (in pixels) of the exported image. Note that I don't see this useful either! Fixing the image size in length unit might be useful if you want to print it later. But in this case, It's better in my opinion to send the image full size and let the print service do the downsizing according to their printer capabilities...


I did not know that LR uses the resolution box input to calculate if you set the measurement of an exported file in a unit length.  I guess I did not know because, like you, I always send as much resolution as I can or as is needed.  Or, I resize based on pixels rather than inches or centimeters and the input is not needed.  I still think that it could be better labeled if it is going to be used for that purpose.  Perhaps "Desired Print PPI"?  Now that makes me wonder what happens if the native file does not have the needed resolution?  Does LR scale up?

--Ken


----------



## Jim Wilde (Jun 1, 2020)

Replytoken said:


> Perhaps "Desired Print PPI"?  Now that makes me wonder what happens if the native file does not have the needed resolution?  Does LR scale up?


Yes, if you leave the "Don't Enlarge" box *unchecked*. But if you check that box, and the file doesn't have the required resolution, then you end up with an exported file which doesn't have enough pixels to print the required size at the required PPI setting. That could be an obscure bug, of course.


----------

