为什么软件可以比JPEG更准确地校正RAW文件的白平衡?


11

为什么后处理JPEG白平衡校正的精度不如Raw的白平衡?

我的理解是,在拍摄jpeg时,相机内部执行以下步骤:

  1. 使用(去马赛克/去拜耳)算法转换原始传感器数据。
  2. 转换为线性空间

    一种。使用查找表将原始值映射到线性空间

    b。然后计算并减去每个像素的黑电平。

    C。然后使用Whitelevel将每个像素的值重新缩放为0.0到1.0

    d。重新缩放的值将被裁剪为0.0到1.0逻辑范围。

  3. 通过白平衡调整将相机色彩空间映射到CIE XYZ空间

    一种。使用CameraToXYZ_D50 = Chromatic_adapatation_matrix * CameraToXYZ_matrix转换为XYZ(D50)

  4. 将CIE XYZ转换为sRGB

    一种。使用CIE XYZ将线性RGB计算为线性RGB矩阵

    b。在线性RGB上使用伽玛曲线变换计算Rec709 sRGB

  5. 将sRGB转换为8位并使用JPEG压缩

如果这个方法正确,我不明白为什么Jpeg不能像Raw一样对白平衡进行校正!

仅仅是因为JPEG和32位tiff文件的有损压缩会不会出现此问题吗?

在此处输入图片说明


1
是什么让您认为JPEG WB不如原始的准确?准确是什么意思?您是说照相机通常不像使用原始转换应用程序的熟练人员那样猜测吗?或者是其他东西?
Michael C,

我的意思是,如果我告诉我的相机保存同一张图片的原始副本和jpeg副本,然后在lightroom中打开它们,并尝试通过使用图像选择器通过单击图像中完全相同的位置来进行白平衡校正,完美,而jpeg仍然具有怪异的颜色。
skyde

2
这是一个非常不同的问题。我将编辑标题以反映我认为您实际上要问的问题……
请阅读我的资料,

5
第一张图片不是“原始原始文件”。它是原始转换应用程序生成并以8位显示在屏幕上的原始数据的无限可能的解释之一。
Michael C

2
可能不是最重要的一点,但是您的步骤2实际上是两个截然不同的步骤,并且它们可能不会按照显示它们的顺序执行(这是将WB“烘焙”为最终JPEG的另一种方式)颜色)。
junkyardsparkle

Answers:


9

为什么软件可以比JPEG更准确地校正RAW文件的白平衡?

与使用8位jpeg处理整个原始信息相比,使用实际的原始数据生成对原始数据的解释与对屏幕上看到的原始文件的初始8位解释有根本的区别。该文件就是您在屏幕上看到的。

当您在“原始”文件上使用白色答题器时,您并没有校正屏幕上显示的图像(这是类似jpeg的8位渲染,这是对原始图像文件中数据的许多可能解释之一)。您要告诉原始转换应用程序返回并使用一组不同的颜色通道倍增器将原始文件中的数据转换为可显示的图像。

您正在使用用于创建屏幕上看到的第一个版本的原始数据创建另一个图像。但是该应用程序将一直追溯到开始,并使用原始文件中的所有数据,根据您对数据应如何处理的不同说明,对原始数据创建第二种不同的解释。它不是从屏幕上显示的有限信息开始并进行更正。如果这样做的话,您将获得与使用jpeg时相同的结果。¹

原始文件包含的信息比“打开”原始文件时显示器上显示的信息更多。原始图像文件包含足够的数据,可为该数据创建几乎无限数量的不同解释,这些解释将适合8位jpeg文件。²

任何时候打开原始文件并在屏幕上查看它时,您都不会查看“ THE Raw file”。³您正在查看的原始文件中的数据解释数不胜数。原始数据本身包含每个像素孔的单个(单色)亮度值度量。使用拜耳遮罩式摄像头传感器(绝大多数彩色数码相机使用拜耳滤镜),每个像素孔前面都具有一个“红色”,“绿色”或“蓝色”(实际的“颜色”)滤色镜。大部分拜耳口罩中的滤光片的颜色从略黄绿色到橙黄色(对于“红色”),略蓝绿色(对于“绿色”)和略蓝紫色(对于“蓝色”)-这些颜色或多或少地对应于我们视网膜中三种视锥细胞的敏感中心。要更全面地讨论我们如何从每个像素处测得的单个亮度值中获取颜色信息,请参阅RAW文件每个像素存储3种颜色,或仅存储一种?

当您更改原始文件的白平衡时,您并未更改在屏幕上看到的原始文件的8位解释,而是在更改线性14位单色原始数据的解释方式,然后以更新的白平衡显示在屏幕上。也就是说,您正在利用原始文件为每个像素包含的16384个离散单色线性步长的全部优势,而不是在8位屏幕上看到的每个像素在三个颜色通道中的256个离散伽玛校正步长,它们分别是该原始文件的表示形式。您还可以利用原始图像数据中包含的所有其他信息,包括诸如蒙版像素之类的东西以及将文件转换为8位格式以显示在屏幕上时丢弃的其他信息。

打开原始文件时,您在监视器上看到的图像的外观取决于您用来打开文件的应用程序如何解释文件中的原始数据以生成可见图像。但这不是显示“原始原始文件”的“唯一”方法。这只是您的应用程序(或在原始文件上生成jpeg预览的相机)处理原始文件中的信息以将其显示在屏幕上的方式。

每个应用程序都有自己的一组默认参数,这些参数确定如何处理原始数据。最重要的参数之一是如何选择用于转换原始数据的白平衡。大多数应用程序具有用户可以选择的许多不同参数集,然后用户可以自由更改用于初始解释原始文件中数据的指令集内的各个设置。在拍摄照片时,许多应用程序将使用相机估计的白平衡/色彩通道倍增(使用相机中的AWB时)或用户输入(使用相机中的CT + WB校正时)。但这不是唯一可以用来解释原始数据的合法白平衡。

对于14位原始文件,在0(纯黑色)和1(纯白色)之间有16,384个离散值。这允许每个值之间的步长很小。但是这些是单色亮度值。对数据进行去马赛克后,将应用伽玛曲线,并完成到特定颜色空间的转换,通常将WB转换乘数应用于这14位值。该过程的最后一步是在进行有损文件压缩之前将结果值重新映射为8位。8位仅允许256个介于0(纯黑色)和1(纯白色)之间的离散值。因此,值之间的每个步长比14位大64倍。

然后,如果我们尝试用这么多的渐变来更改WB,则尝试扩展的区域将推动我们正在使用的数据中的每个步骤,而不是将结果文件中的单个步骤推向更远的位置。因此,这些区域的层次变得更加粗糙。我们缩小的区域将这些步骤中的每一步都比生成文件中的单个步骤占用的空间小。但是,所有这些步骤都将重新调整以适合“ 0”和“ 1”之间的256步渐变。这通常导致条带化或后代化,而不是平滑的过渡。

¹为了更快,更省资源,某些原始处理应用程序将具有“快速”模式,当您移动设置滑块时,该模式实际上会修改屏幕上现有的8位表示。这通常会导致出现条带或其他不想要的伪影,例如您在问题中已变色的jpeg中看到的紫色。不过,这仅适用于您正在查看的预览。转换并保存(导出)文件时,实际上会对原始数据执行相同的指令,即对其进行重新处理,并且看不到条带或其他伪像(或不那么严重)。

²当然,您可以拍摄在整个视场中包含单一纯色的照片。但大多数照片的色相,色彩和亮度水平差异很大。

³请参阅:如果尚未进行去拜耳处理,为什么我的RAW图像已经彩色了?

这可以解释由于精度降低而导致的图像中的条纹或后代现象,但是仍然应该可以将白点移动到正确的位置。

您可以在一定程度上更改jpeg的颜色,但是生成原始数据可以产生的所有颜色所需的大多数信息不再存在。在转换为RGB并在压缩减少为8位的过程中将其丢弃。您剩下要做的唯一事情就是这三个颜色通道中每个像素的值。可以重新绘制这些通道中每个通道的响应曲线,但所做的只是提高或降低每个图像像素中该颜色通道的值。它不会返回并基于新的通道倍增器重做去马赛克,因为该信息未保留在JPEG中。

重要的是要理解,在添加到问题的示例图像中,第二个图像不是从第一个图像派生的。两者的第一和第二图像是完全一样的原始数据的两种不同的解释。两者都不比另一个更原始。就原始文件中包含的数据的有效表示而言,没有一个比另一个更“正确”。它们都是使用原始文件中的数据生成8位图像的完全合法的方法。第一种是原始转换应用程序和/或相机中生成的jpeg预览选择解释数据的方式。第二种是原始转换应用程序在告诉您要将哪些原始传感器值转换为灰色/白色后解释数据的方式。当您单击jpeg图像的同一部分时,将图像校正为看起来像原始文件的第二版本所需的许多颜色信息不再存在,因此无法使用。

仅仅是因为JPEG和32位tiff文件的有损压缩会不会出现此问题吗?

不会,尽管有损压缩是其中很大一部分。减少到8位也是如此,这使得“ 0”(纯黑色)和“ 1”(完全饱和)之间的每个步长达到14位原始文件的64倍。但这超出了jpeg压缩的范围。

这个答案RAW到TIFF或PSD 16bit的几段内容丢失了颜色深度

一旦将原始文件中的数据转换为经去马赛克,伽玛校正的TIFF文件,该过程将不可逆。

TIFF文件将所有这些处理步骤“嵌入”到它们包含的信息中。尽管由于每个文件存储数据的方式不同,未压缩的16位TIFF文件要比从中获取原始文件的典型原始文件大得多,但它不包含反转转换并重现相同精确数据所需的所有信息。包含在原始文件中。在原始文件的像素级数据中,几乎有无数个不同的值可以用于生成特定的TIFF。同样,根据有关如何处理原始数据以生成TIFF的决定,可以从原始图像文件中的数据生成几乎无限数量的TIFF文件。

与8位TIFF相比,16位TIFF的优势在于,图像中每个颜色通道的最暗值和最亮值之间的步数。这些更精细的步骤允许在最终转换为8位格式之前进行更多其他操作,而不会在色调渐变区域中产生诸如条带之类的伪影。

但是,仅仅因为16位TIFF在“ 0”和“ 65,535”之间具有比12位(0-4095)或14位(0-16383)原始文件更多的步长,并不意味着TIFF文件显示亮度范围相同或更大。当将14位原始文件中的数据转换为TIFF文件时,黑点可能已选择为2048等值。原始文件中任何值小于2048的像素都将被分配为0在TIFF中。同样,如果将白点设置为8191,则原始文件中任何高于8191的值都将设置为65535,并且原始文件中最亮的光阑将不可避免地丢失。原始文件中所有比所选白点更亮的内容在TIFF中都具有相同的值,因此不会保留任何细节。

这里有很多现有的问题都涉及相同的方面。以下是其中一些可能会有所帮助的信息:

RAW文件每个像素存储3种颜色,或仅一种?
RAW至TIFF或PSD 16位会丢失色彩深度
如何在Lightroom中从相机内JPEG设置开始?
在Darktable中从“ lighttable”切换到“ darkroom”时,为什么RAW文件的外观会发生变化?
尼康d810手动白平衡与Lightroom中的“按拍摄”不一样?
为什么在编辑程序中RAW图像看起来比JPEG差?
使Lightroom中的颜色与其他编辑工具匹配
在RAW中拍摄时,是否需要对其进行后处理以使图片看起来更好?

为什么从相机到计算机屏幕质量都会下降?
为什么我的照片在Photoshop / Lightroom和Canon EOS实用程序/相机中看起来不一样?
为什么在相机上的图像看上去与导入到笔记本电脑中的图像不同?
如何在Lightroom中模拟相机中的处理?
尼康相机内和Lightroom JPG转换
为什么加载后我的Lightroom / Photoshop预览会更改?


2
这可以解释由于精度降低而导致的图像中的条纹或后代现象,但是仍然应该可以将白点移动到正确的位置。
skyde

2
是的,这是有道理的,这是说当转换为TIFF色域时,可能会裁剪原始图像中的颜色。因此,我们仍然丢失了色彩平衡校正可能需要的信息。
skyde

1
我喜欢skyde:色彩分辨率上的离散步骤更少,这并不意味着白平衡会带来很好的可见的不同结果。尤其是jpeg版本具有沉重的紫色调时。一个更合适的理论是,可能的内部校正值在jpeg中的范围要比在原始范围中的范围窄,这是基于从原始传感器数据解释原始图像并且jpeg是离散的颜色值这一事实。
Horitsu

1
我也和skyde一起加入。关于原始和jpeg格式之间的差异,这只是一个漫长而无关紧要的故事。这里没有任何内容,实际上可以回答原始问题。
jarnbjo

1
@jarnbjo大多数答案都用于解释图像文件中实际原始数据与当人们“观看”原始数据的许多可能解释中的一种时在屏幕上看到的内容之间的区别。根据我的经验,大多数此类问题的出现是由于根本上缺乏对人们在屏幕上看到的内容永远不是“ THE”原始文件的理解。根据我的经验,以几种不同的方式进行说明会增加灯泡最终供提问者使用的机会。YMMV。
Michael C

3

简单的答案是因为您的相机和RAW处理器(LR,Darktable,仅举几例)使用不同的算法来处理RAW文件。原因有很多,我们无法评估这些算法,因为很多是商业秘密。例如,佳能(EOS 700D)的日光色温约为5200K,而Lightroom的色温为5500K。在某些情况下,这会有所不同。

准确地说,RAW文件没有预先定义的色温。它作为元信息包括在内。RAW处理器在执行您描述的操作时会应用特定的白平衡。

编辑:并根据您的评论:您不能在JPEG文件上更改很多色温,因为它已被“煮熟”。色温已经应用,并且您没有足够的色深来“移动”颜色。


Darktable的算法不是商业机密。
请阅读我的资料,

@mattdm,是的。但是LR,ON1,CaptureOne和其他非开源RAW处理器是...
Romeo Ninov

但是,这真的与这个问题有关吗?白平衡校正的基础是众所周知的,并在开放软件中实现。
请阅读“我的资料”,

是的。但是实现可能有所不同。确切地说,那些细节通常是秘密的(对于非开源软件)
Romeo Ninov

1

可能的白平衡JPEG文件,但用于对RAW操作编辑工具VS其他图像往往会表现不同(不同的算法)。进一步:

  • 滴管工具是不准确的,这使得它很难复制的结果。

  • JPEG 的位深度限制了与RAW相比可以移动多少颜色。

  • 伽玛曲线混乱的一切行动。

  • 线性数据与对数数据的计算方式不同。

并不完全是它的工作方式,而是为了说明:

  • 假设您要将一些数据(1、4、8)乘以2,结果是(2、8、16)。对于线性数据,最大结果16是最小结果2的四倍。

  • 但是,使用对数表示法,相邻值(例如2 5和2 6)之间的差距远大于线性值5和6之间的差。此外,最大结果2 16不仅比线性结果大32768倍。最小结果2 2,它也是原始值2 8的 256倍。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.