What does an unprocessed RAW file look like?












3















I know people use fancy software like Lightroom or Darktable to post-process their RAW files. But what if I don't? What does the file look like, just, y'know, RAW?










share|improve this question























  • The matrix. It looks like the matrix.

    – Hueco
    2 hours ago











  • Related; RAW files store 3 colors per pixel, or only one? and Why are Red, Green, and Blue the primary colors of light? which explains how digital camera sensors minic the way or eyes/brains perceive color that in a sense does not actually exist the way we often assume it does.

    – Michael C
    42 mins ago
















3















I know people use fancy software like Lightroom or Darktable to post-process their RAW files. But what if I don't? What does the file look like, just, y'know, RAW?










share|improve this question























  • The matrix. It looks like the matrix.

    – Hueco
    2 hours ago











  • Related; RAW files store 3 colors per pixel, or only one? and Why are Red, Green, and Blue the primary colors of light? which explains how digital camera sensors minic the way or eyes/brains perceive color that in a sense does not actually exist the way we often assume it does.

    – Michael C
    42 mins ago














3












3








3








I know people use fancy software like Lightroom or Darktable to post-process their RAW files. But what if I don't? What does the file look like, just, y'know, RAW?










share|improve this question














I know people use fancy software like Lightroom or Darktable to post-process their RAW files. But what if I don't? What does the file look like, just, y'know, RAW?







raw image-processing






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 3 hours ago









mattdmmattdm

120k38351642




120k38351642













  • The matrix. It looks like the matrix.

    – Hueco
    2 hours ago











  • Related; RAW files store 3 colors per pixel, or only one? and Why are Red, Green, and Blue the primary colors of light? which explains how digital camera sensors minic the way or eyes/brains perceive color that in a sense does not actually exist the way we often assume it does.

    – Michael C
    42 mins ago



















  • The matrix. It looks like the matrix.

    – Hueco
    2 hours ago











  • Related; RAW files store 3 colors per pixel, or only one? and Why are Red, Green, and Blue the primary colors of light? which explains how digital camera sensors minic the way or eyes/brains perceive color that in a sense does not actually exist the way we often assume it does.

    – Michael C
    42 mins ago

















The matrix. It looks like the matrix.

– Hueco
2 hours ago





The matrix. It looks like the matrix.

– Hueco
2 hours ago













Related; RAW files store 3 colors per pixel, or only one? and Why are Red, Green, and Blue the primary colors of light? which explains how digital camera sensors minic the way or eyes/brains perceive color that in a sense does not actually exist the way we often assume it does.

– Michael C
42 mins ago





Related; RAW files store 3 colors per pixel, or only one? and Why are Red, Green, and Blue the primary colors of light? which explains how digital camera sensors minic the way or eyes/brains perceive color that in a sense does not actually exist the way we often assume it does.

– Michael C
42 mins ago










1 Answer
1






active

oldest

votes


















4














There's a tool called dcraw which reads various RAW file types and extracts pixel data from them — it's actually the original code at the very bottom of a lot of open source and even commercial RAW conversion software.



I have a RAW file from my camera, and I've used dcraw in a mode which tells it to create an image using literal, unscaled 16-bit values from the file. Converted to a JPEG for sharing (and scaled to 1200×800), that looks like this:



dcraw -E -4



That's very dark, although if you click to expand, and if your monitor is decent, you can see some hint of something.



Here is the out-of-camera color JPEG rendered from that same RAW file:



out of camera jpeg



(Photo credit: my daughter using my camera, by the way.)



The dcraw program has another mode which converts to a more "useful" JPEG image by stretching the values to a curve where the darks and lights are distributed so they're actually visible. There's still a one-to-one correspondence between photosites on the sensor and pixels in the output. That looks like this:



dcraw -d



... obviously more recognizable as an image — but if we zoom in on this (here, so each pixel is actually magnified 10×), we see that it's all... dotty:



crop 10x



That's because the sensor is covered by a color filter array — tiny little colored filters the size of each photosite. Because my camera is a Fujifilm camera, this uses a pattern Fujifilm calls "X-Trans", which looks like this:



xtrans 10x



There are some details about the particular pattern that are kind of interesting, but overall it's not super-important. Most cameras today use something called a Bayer pattern (which has less green and repeats every 2×2 rather than 6×6). Why more green? The human eye is more sensitive to light in that range, and so using more of the pixels for that allows more detail with less noise.



So, anyway, here's a 1:1 (one pixel in the image is one pixel on the screen) section of the out-of-camera JPEG:



crop



... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:



dcraw -d crop



We can actually take that and colorize the pixels so those corresponding to green in the array are mapped to levels of green instead of gray, red to red, and blue to blue. That gives us:



colorized crop



... or, for the full-sized image:



full colorized



The green cast is very apparent (and, no surprise because there are 2½× more green pixels than red or blue). If we take this into an image editing program and hit "auto levels", we get something like this:



colorized with auto-levels



... which actually isn't half bad, at least from a distance. If you click to get the larger version — which I've scaled down to 1200×800 — you can see that there's lines and other bad artifacts.



So, in reality, conversion programs use more sophisticated algorithms to blend in information from neighbors intelligently, instead of this rough colorizing. And I haven't done anything useful or interesting at all with dynamic range or tone curves or all the things I could have done to the file. This result — basically, a naïvely-colorized RAW file — isn't really the "default" look of the file before processing. It's just one (not so great) interpretation.



All real-world RAW processing programs have their own ideas of a basic default state to apply to a fresh RAW file on load. Which is good, because otherwise we'd have that dark, useless thing at the top of this post.






share|improve this answer


























  • It's good to see that you're finally coming to the realization that one can't just use green for the "green" filtered pixels, red for the "red" filtered pixels (that are really more orange-yellow than red), and blue for the "blue filtered pixels if one wants anything approximating accurate color!

    – Michael C
    1 hour ago













  • It would be interesting to be able to find a published spectral response graph (measured by an independent lab) for the X-trans sensors somewhere. Some have suggested more than one shade of "green" is used. Your fourth image above (the magnified gray scale) certainly looks like this is the case. I'd also love to know what wavelength the "red" filter is centered upon. I'd be really surprised if it was anything approaching 640nm instead of somewhere around 600nm.

    – Michael C
    49 mins ago











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "61"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fphoto.stackexchange.com%2fquestions%2f105271%2fwhat-does-an-unprocessed-raw-file-look-like%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














There's a tool called dcraw which reads various RAW file types and extracts pixel data from them — it's actually the original code at the very bottom of a lot of open source and even commercial RAW conversion software.



I have a RAW file from my camera, and I've used dcraw in a mode which tells it to create an image using literal, unscaled 16-bit values from the file. Converted to a JPEG for sharing (and scaled to 1200×800), that looks like this:



dcraw -E -4



That's very dark, although if you click to expand, and if your monitor is decent, you can see some hint of something.



Here is the out-of-camera color JPEG rendered from that same RAW file:



out of camera jpeg



(Photo credit: my daughter using my camera, by the way.)



The dcraw program has another mode which converts to a more "useful" JPEG image by stretching the values to a curve where the darks and lights are distributed so they're actually visible. There's still a one-to-one correspondence between photosites on the sensor and pixels in the output. That looks like this:



dcraw -d



... obviously more recognizable as an image — but if we zoom in on this (here, so each pixel is actually magnified 10×), we see that it's all... dotty:



crop 10x



That's because the sensor is covered by a color filter array — tiny little colored filters the size of each photosite. Because my camera is a Fujifilm camera, this uses a pattern Fujifilm calls "X-Trans", which looks like this:



xtrans 10x



There are some details about the particular pattern that are kind of interesting, but overall it's not super-important. Most cameras today use something called a Bayer pattern (which has less green and repeats every 2×2 rather than 6×6). Why more green? The human eye is more sensitive to light in that range, and so using more of the pixels for that allows more detail with less noise.



So, anyway, here's a 1:1 (one pixel in the image is one pixel on the screen) section of the out-of-camera JPEG:



crop



... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:



dcraw -d crop



We can actually take that and colorize the pixels so those corresponding to green in the array are mapped to levels of green instead of gray, red to red, and blue to blue. That gives us:



colorized crop



... or, for the full-sized image:



full colorized



The green cast is very apparent (and, no surprise because there are 2½× more green pixels than red or blue). If we take this into an image editing program and hit "auto levels", we get something like this:



colorized with auto-levels



... which actually isn't half bad, at least from a distance. If you click to get the larger version — which I've scaled down to 1200×800 — you can see that there's lines and other bad artifacts.



So, in reality, conversion programs use more sophisticated algorithms to blend in information from neighbors intelligently, instead of this rough colorizing. And I haven't done anything useful or interesting at all with dynamic range or tone curves or all the things I could have done to the file. This result — basically, a naïvely-colorized RAW file — isn't really the "default" look of the file before processing. It's just one (not so great) interpretation.



All real-world RAW processing programs have their own ideas of a basic default state to apply to a fresh RAW file on load. Which is good, because otherwise we'd have that dark, useless thing at the top of this post.






share|improve this answer


























  • It's good to see that you're finally coming to the realization that one can't just use green for the "green" filtered pixels, red for the "red" filtered pixels (that are really more orange-yellow than red), and blue for the "blue filtered pixels if one wants anything approximating accurate color!

    – Michael C
    1 hour ago













  • It would be interesting to be able to find a published spectral response graph (measured by an independent lab) for the X-trans sensors somewhere. Some have suggested more than one shade of "green" is used. Your fourth image above (the magnified gray scale) certainly looks like this is the case. I'd also love to know what wavelength the "red" filter is centered upon. I'd be really surprised if it was anything approaching 640nm instead of somewhere around 600nm.

    – Michael C
    49 mins ago
















4














There's a tool called dcraw which reads various RAW file types and extracts pixel data from them — it's actually the original code at the very bottom of a lot of open source and even commercial RAW conversion software.



I have a RAW file from my camera, and I've used dcraw in a mode which tells it to create an image using literal, unscaled 16-bit values from the file. Converted to a JPEG for sharing (and scaled to 1200×800), that looks like this:



dcraw -E -4



That's very dark, although if you click to expand, and if your monitor is decent, you can see some hint of something.



Here is the out-of-camera color JPEG rendered from that same RAW file:



out of camera jpeg



(Photo credit: my daughter using my camera, by the way.)



The dcraw program has another mode which converts to a more "useful" JPEG image by stretching the values to a curve where the darks and lights are distributed so they're actually visible. There's still a one-to-one correspondence between photosites on the sensor and pixels in the output. That looks like this:



dcraw -d



... obviously more recognizable as an image — but if we zoom in on this (here, so each pixel is actually magnified 10×), we see that it's all... dotty:



crop 10x



That's because the sensor is covered by a color filter array — tiny little colored filters the size of each photosite. Because my camera is a Fujifilm camera, this uses a pattern Fujifilm calls "X-Trans", which looks like this:



xtrans 10x



There are some details about the particular pattern that are kind of interesting, but overall it's not super-important. Most cameras today use something called a Bayer pattern (which has less green and repeats every 2×2 rather than 6×6). Why more green? The human eye is more sensitive to light in that range, and so using more of the pixels for that allows more detail with less noise.



So, anyway, here's a 1:1 (one pixel in the image is one pixel on the screen) section of the out-of-camera JPEG:



crop



... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:



dcraw -d crop



We can actually take that and colorize the pixels so those corresponding to green in the array are mapped to levels of green instead of gray, red to red, and blue to blue. That gives us:



colorized crop



... or, for the full-sized image:



full colorized



The green cast is very apparent (and, no surprise because there are 2½× more green pixels than red or blue). If we take this into an image editing program and hit "auto levels", we get something like this:



colorized with auto-levels



... which actually isn't half bad, at least from a distance. If you click to get the larger version — which I've scaled down to 1200×800 — you can see that there's lines and other bad artifacts.



So, in reality, conversion programs use more sophisticated algorithms to blend in information from neighbors intelligently, instead of this rough colorizing. And I haven't done anything useful or interesting at all with dynamic range or tone curves or all the things I could have done to the file. This result — basically, a naïvely-colorized RAW file — isn't really the "default" look of the file before processing. It's just one (not so great) interpretation.



All real-world RAW processing programs have their own ideas of a basic default state to apply to a fresh RAW file on load. Which is good, because otherwise we'd have that dark, useless thing at the top of this post.






share|improve this answer


























  • It's good to see that you're finally coming to the realization that one can't just use green for the "green" filtered pixels, red for the "red" filtered pixels (that are really more orange-yellow than red), and blue for the "blue filtered pixels if one wants anything approximating accurate color!

    – Michael C
    1 hour ago













  • It would be interesting to be able to find a published spectral response graph (measured by an independent lab) for the X-trans sensors somewhere. Some have suggested more than one shade of "green" is used. Your fourth image above (the magnified gray scale) certainly looks like this is the case. I'd also love to know what wavelength the "red" filter is centered upon. I'd be really surprised if it was anything approaching 640nm instead of somewhere around 600nm.

    – Michael C
    49 mins ago














4












4








4







There's a tool called dcraw which reads various RAW file types and extracts pixel data from them — it's actually the original code at the very bottom of a lot of open source and even commercial RAW conversion software.



I have a RAW file from my camera, and I've used dcraw in a mode which tells it to create an image using literal, unscaled 16-bit values from the file. Converted to a JPEG for sharing (and scaled to 1200×800), that looks like this:



dcraw -E -4



That's very dark, although if you click to expand, and if your monitor is decent, you can see some hint of something.



Here is the out-of-camera color JPEG rendered from that same RAW file:



out of camera jpeg



(Photo credit: my daughter using my camera, by the way.)



The dcraw program has another mode which converts to a more "useful" JPEG image by stretching the values to a curve where the darks and lights are distributed so they're actually visible. There's still a one-to-one correspondence between photosites on the sensor and pixels in the output. That looks like this:



dcraw -d



... obviously more recognizable as an image — but if we zoom in on this (here, so each pixel is actually magnified 10×), we see that it's all... dotty:



crop 10x



That's because the sensor is covered by a color filter array — tiny little colored filters the size of each photosite. Because my camera is a Fujifilm camera, this uses a pattern Fujifilm calls "X-Trans", which looks like this:



xtrans 10x



There are some details about the particular pattern that are kind of interesting, but overall it's not super-important. Most cameras today use something called a Bayer pattern (which has less green and repeats every 2×2 rather than 6×6). Why more green? The human eye is more sensitive to light in that range, and so using more of the pixels for that allows more detail with less noise.



So, anyway, here's a 1:1 (one pixel in the image is one pixel on the screen) section of the out-of-camera JPEG:



crop



... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:



dcraw -d crop



We can actually take that and colorize the pixels so those corresponding to green in the array are mapped to levels of green instead of gray, red to red, and blue to blue. That gives us:



colorized crop



... or, for the full-sized image:



full colorized



The green cast is very apparent (and, no surprise because there are 2½× more green pixels than red or blue). If we take this into an image editing program and hit "auto levels", we get something like this:



colorized with auto-levels



... which actually isn't half bad, at least from a distance. If you click to get the larger version — which I've scaled down to 1200×800 — you can see that there's lines and other bad artifacts.



So, in reality, conversion programs use more sophisticated algorithms to blend in information from neighbors intelligently, instead of this rough colorizing. And I haven't done anything useful or interesting at all with dynamic range or tone curves or all the things I could have done to the file. This result — basically, a naïvely-colorized RAW file — isn't really the "default" look of the file before processing. It's just one (not so great) interpretation.



All real-world RAW processing programs have their own ideas of a basic default state to apply to a fresh RAW file on load. Which is good, because otherwise we'd have that dark, useless thing at the top of this post.






share|improve this answer















There's a tool called dcraw which reads various RAW file types and extracts pixel data from them — it's actually the original code at the very bottom of a lot of open source and even commercial RAW conversion software.



I have a RAW file from my camera, and I've used dcraw in a mode which tells it to create an image using literal, unscaled 16-bit values from the file. Converted to a JPEG for sharing (and scaled to 1200×800), that looks like this:



dcraw -E -4



That's very dark, although if you click to expand, and if your monitor is decent, you can see some hint of something.



Here is the out-of-camera color JPEG rendered from that same RAW file:



out of camera jpeg



(Photo credit: my daughter using my camera, by the way.)



The dcraw program has another mode which converts to a more "useful" JPEG image by stretching the values to a curve where the darks and lights are distributed so they're actually visible. There's still a one-to-one correspondence between photosites on the sensor and pixels in the output. That looks like this:



dcraw -d



... obviously more recognizable as an image — but if we zoom in on this (here, so each pixel is actually magnified 10×), we see that it's all... dotty:



crop 10x



That's because the sensor is covered by a color filter array — tiny little colored filters the size of each photosite. Because my camera is a Fujifilm camera, this uses a pattern Fujifilm calls "X-Trans", which looks like this:



xtrans 10x



There are some details about the particular pattern that are kind of interesting, but overall it's not super-important. Most cameras today use something called a Bayer pattern (which has less green and repeats every 2×2 rather than 6×6). Why more green? The human eye is more sensitive to light in that range, and so using more of the pixels for that allows more detail with less noise.



So, anyway, here's a 1:1 (one pixel in the image is one pixel on the screen) section of the out-of-camera JPEG:



crop



... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:



dcraw -d crop



We can actually take that and colorize the pixels so those corresponding to green in the array are mapped to levels of green instead of gray, red to red, and blue to blue. That gives us:



colorized crop



... or, for the full-sized image:



full colorized



The green cast is very apparent (and, no surprise because there are 2½× more green pixels than red or blue). If we take this into an image editing program and hit "auto levels", we get something like this:



colorized with auto-levels



... which actually isn't half bad, at least from a distance. If you click to get the larger version — which I've scaled down to 1200×800 — you can see that there's lines and other bad artifacts.



So, in reality, conversion programs use more sophisticated algorithms to blend in information from neighbors intelligently, instead of this rough colorizing. And I haven't done anything useful or interesting at all with dynamic range or tone curves or all the things I could have done to the file. This result — basically, a naïvely-colorized RAW file — isn't really the "default" look of the file before processing. It's just one (not so great) interpretation.



All real-world RAW processing programs have their own ideas of a basic default state to apply to a fresh RAW file on load. Which is good, because otherwise we'd have that dark, useless thing at the top of this post.







share|improve this answer














share|improve this answer



share|improve this answer








edited 3 hours ago

























answered 3 hours ago









mattdmmattdm

120k38351642




120k38351642













  • It's good to see that you're finally coming to the realization that one can't just use green for the "green" filtered pixels, red for the "red" filtered pixels (that are really more orange-yellow than red), and blue for the "blue filtered pixels if one wants anything approximating accurate color!

    – Michael C
    1 hour ago













  • It would be interesting to be able to find a published spectral response graph (measured by an independent lab) for the X-trans sensors somewhere. Some have suggested more than one shade of "green" is used. Your fourth image above (the magnified gray scale) certainly looks like this is the case. I'd also love to know what wavelength the "red" filter is centered upon. I'd be really surprised if it was anything approaching 640nm instead of somewhere around 600nm.

    – Michael C
    49 mins ago



















  • It's good to see that you're finally coming to the realization that one can't just use green for the "green" filtered pixels, red for the "red" filtered pixels (that are really more orange-yellow than red), and blue for the "blue filtered pixels if one wants anything approximating accurate color!

    – Michael C
    1 hour ago













  • It would be interesting to be able to find a published spectral response graph (measured by an independent lab) for the X-trans sensors somewhere. Some have suggested more than one shade of "green" is used. Your fourth image above (the magnified gray scale) certainly looks like this is the case. I'd also love to know what wavelength the "red" filter is centered upon. I'd be really surprised if it was anything approaching 640nm instead of somewhere around 600nm.

    – Michael C
    49 mins ago

















It's good to see that you're finally coming to the realization that one can't just use green for the "green" filtered pixels, red for the "red" filtered pixels (that are really more orange-yellow than red), and blue for the "blue filtered pixels if one wants anything approximating accurate color!

– Michael C
1 hour ago







It's good to see that you're finally coming to the realization that one can't just use green for the "green" filtered pixels, red for the "red" filtered pixels (that are really more orange-yellow than red), and blue for the "blue filtered pixels if one wants anything approximating accurate color!

– Michael C
1 hour ago















It would be interesting to be able to find a published spectral response graph (measured by an independent lab) for the X-trans sensors somewhere. Some have suggested more than one shade of "green" is used. Your fourth image above (the magnified gray scale) certainly looks like this is the case. I'd also love to know what wavelength the "red" filter is centered upon. I'd be really surprised if it was anything approaching 640nm instead of somewhere around 600nm.

– Michael C
49 mins ago





It would be interesting to be able to find a published spectral response graph (measured by an independent lab) for the X-trans sensors somewhere. Some have suggested more than one shade of "green" is used. Your fourth image above (the magnified gray scale) certainly looks like this is the case. I'd also love to know what wavelength the "red" filter is centered upon. I'd be really surprised if it was anything approaching 640nm instead of somewhere around 600nm.

– Michael C
49 mins ago


















draft saved

draft discarded




















































Thanks for contributing an answer to Photography Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fphoto.stackexchange.com%2fquestions%2f105271%2fwhat-does-an-unprocessed-raw-file-look-like%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

Mangá

Eduardo VII do Reino Unido