What does an unprocessed RAW file look like?Why are Red, Green, and Blue the primary colors of light?RAW...

How can I differentiate duration vs starting time

Does changing "sa" password require a SQL restart (in mixed mode)?

Does the kobold player race feature, Pack Tactics, give ranged attacks advantage?

Is it possible to detect 100% of SQLi with a simple regex?

Why is quixotic not Quixotic (a proper adjective)?

Can a planet be tidally unlocked?

How can I portray body horror and still be sensitive to people with disabilities?

Current measurement op-amp calculation

Is it common to refer to someone as "Prof. Dr. [LastName]"?

How can a kingdom keep the secret of a missing monarch from the public?

boss asked me to sign a resignation paper without a date on it along with my new contract

Was Opportunity's last message to Earth "My battery is low and it's getting dark"?

Ramanujan's radical and how we define an infinite nested radical

Is it ethical to apply for a job on someone's behalf?

Reading source code and extracting json from a url

What happens if you declare more than $10,000 at the US border?

Rudeness by being polite

Which was the first story to feature space elevators?

Why is Bernie Sanders maximum accepted donation on actblue $5600?

How to play songs that contain one guitar when we have two or more guitarists?

Integral check. Is partial fractions the only way?

The Longest Chess Game

Microphone on Mars

Stream.findFirst different than Optional.of?



What does an unprocessed RAW file look like?


Why are Red, Green, and Blue the primary colors of light?RAW files store 3 colors per pixel, or only one?How sharp are RAW photos before processing?How does Picasa process RAW photos?How is colour balancing performed in post processing of raw imagesPulling colors out of a raw file in postHow to open 'RAW' file from UltraCam-Xp WA camera?Why does the appearance of RAW files change when switching from “lighttable” to “darkroom” in Darktable?Why do we even need RAW-specific editing software?How do I convert multiple RAW files to jpeg in Photoshop Elements 11 without losing the RAW?How to identify slide/negative scanners that produce RAW files?How to process DSLR RAW files for display on modern HDR-capable TVs & computer monitors? (actual 10bit/ch or 12bit/ch dynamic range)darktable “lighttable” view: how to show only one of each JPG or raw image in a directory?













16















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


















  • 1





    The matrix. It looks like the matrix.

    – Hueco
    7 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
    6 hours ago
















16















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


















  • 1





    The matrix. It looks like the matrix.

    – Hueco
    7 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
    6 hours ago














16












16








16


5






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 8 hours ago









mattdmmattdm

120k38352646




120k38352646








  • 1





    The matrix. It looks like the matrix.

    – Hueco
    7 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
    6 hours ago














  • 1





    The matrix. It looks like the matrix.

    – Hueco
    7 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
    6 hours ago








1




1





The matrix. It looks like the matrix.

– Hueco
7 hours ago





The matrix. It looks like the matrix.

– Hueco
7 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
6 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
6 hours ago










2 Answers
2






active

oldest

votes


















31














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





















  • 1





    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
    6 hours 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
    6 hours ago






  • 4





    good show! boldly go and display non-images! (by some opinions ;-)) but i don't agree with the first picture. displaying numbers as intensities assumes some min and max values. you used 16 bits because that's what you got from dcraw, but the actual raw is more like 12 or 14 bits. so it should be brighter. also, you are showing some values (let's forget they are light intensities) on a nonlinear display device. knowing the device characteristics (sRGB) the values should be scaled to counteract the nonlinearlity. this would make the first picture closer to the second one.

    – szulat
    2 hours ago



















0














It's a really really big grid of numbers. Everything else is processing.






share|improve this answer








New contributor




WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 3





    so is JPG, TXT and everything else in computers ;-)

    – szulat
    2 hours ago






  • 1





    @szulat The difference is most of those other things have a single legitimate representation. Raw image data is like a latent negative, it still has potentially a near infinite number of ways it can legitimately be interpreted and displayed on a screen.

    – Michael C
    2 hours ago











  • @MichaelC but now you are talking about human creativity ;-) of course there are millions of ways we can process RAWs, JPGs and TXT files!

    – szulat
    2 hours ago






  • 2





    But there is only one correct way to display the JPG and TXT files. That's not true with raw image data.

    – Michael C
    2 hours ago











  • @szulat Correct. I didn't claim that's a unique quality of RAW files. JPG has a specification, so it's pretty clear how to get from the data to a visual representation. On the other hand, that clearly is processing. Text files don't even have that though - what does an unprocessed text file look like? Applying a character encoding to get from the binary data to unicode code points (or some other logical representation), and applying a font to get a visual representation both are processing.

    – WolfgangGroiss
    1 hour 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

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









31














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





















  • 1





    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
    6 hours 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
    6 hours ago






  • 4





    good show! boldly go and display non-images! (by some opinions ;-)) but i don't agree with the first picture. displaying numbers as intensities assumes some min and max values. you used 16 bits because that's what you got from dcraw, but the actual raw is more like 12 or 14 bits. so it should be brighter. also, you are showing some values (let's forget they are light intensities) on a nonlinear display device. knowing the device characteristics (sRGB) the values should be scaled to counteract the nonlinearlity. this would make the first picture closer to the second one.

    – szulat
    2 hours ago
















31














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





















  • 1





    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
    6 hours 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
    6 hours ago






  • 4





    good show! boldly go and display non-images! (by some opinions ;-)) but i don't agree with the first picture. displaying numbers as intensities assumes some min and max values. you used 16 bits because that's what you got from dcraw, but the actual raw is more like 12 or 14 bits. so it should be brighter. also, you are showing some values (let's forget they are light intensities) on a nonlinear display device. knowing the device characteristics (sRGB) the values should be scaled to counteract the nonlinearlity. this would make the first picture closer to the second one.

    – szulat
    2 hours ago














31












31








31







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 8 hours ago

























answered 8 hours ago









mattdmmattdm

120k38352646




120k38352646








  • 1





    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
    6 hours 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
    6 hours ago






  • 4





    good show! boldly go and display non-images! (by some opinions ;-)) but i don't agree with the first picture. displaying numbers as intensities assumes some min and max values. you used 16 bits because that's what you got from dcraw, but the actual raw is more like 12 or 14 bits. so it should be brighter. also, you are showing some values (let's forget they are light intensities) on a nonlinear display device. knowing the device characteristics (sRGB) the values should be scaled to counteract the nonlinearlity. this would make the first picture closer to the second one.

    – szulat
    2 hours ago














  • 1





    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
    6 hours 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
    6 hours ago






  • 4





    good show! boldly go and display non-images! (by some opinions ;-)) but i don't agree with the first picture. displaying numbers as intensities assumes some min and max values. you used 16 bits because that's what you got from dcraw, but the actual raw is more like 12 or 14 bits. so it should be brighter. also, you are showing some values (let's forget they are light intensities) on a nonlinear display device. knowing the device characteristics (sRGB) the values should be scaled to counteract the nonlinearlity. this would make the first picture closer to the second one.

    – szulat
    2 hours ago








1




1





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
6 hours 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
6 hours 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
6 hours 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
6 hours ago




4




4





good show! boldly go and display non-images! (by some opinions ;-)) but i don't agree with the first picture. displaying numbers as intensities assumes some min and max values. you used 16 bits because that's what you got from dcraw, but the actual raw is more like 12 or 14 bits. so it should be brighter. also, you are showing some values (let's forget they are light intensities) on a nonlinear display device. knowing the device characteristics (sRGB) the values should be scaled to counteract the nonlinearlity. this would make the first picture closer to the second one.

– szulat
2 hours ago





good show! boldly go and display non-images! (by some opinions ;-)) but i don't agree with the first picture. displaying numbers as intensities assumes some min and max values. you used 16 bits because that's what you got from dcraw, but the actual raw is more like 12 or 14 bits. so it should be brighter. also, you are showing some values (let's forget they are light intensities) on a nonlinear display device. knowing the device characteristics (sRGB) the values should be scaled to counteract the nonlinearlity. this would make the first picture closer to the second one.

– szulat
2 hours ago













0














It's a really really big grid of numbers. Everything else is processing.






share|improve this answer








New contributor




WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 3





    so is JPG, TXT and everything else in computers ;-)

    – szulat
    2 hours ago






  • 1





    @szulat The difference is most of those other things have a single legitimate representation. Raw image data is like a latent negative, it still has potentially a near infinite number of ways it can legitimately be interpreted and displayed on a screen.

    – Michael C
    2 hours ago











  • @MichaelC but now you are talking about human creativity ;-) of course there are millions of ways we can process RAWs, JPGs and TXT files!

    – szulat
    2 hours ago






  • 2





    But there is only one correct way to display the JPG and TXT files. That's not true with raw image data.

    – Michael C
    2 hours ago











  • @szulat Correct. I didn't claim that's a unique quality of RAW files. JPG has a specification, so it's pretty clear how to get from the data to a visual representation. On the other hand, that clearly is processing. Text files don't even have that though - what does an unprocessed text file look like? Applying a character encoding to get from the binary data to unicode code points (or some other logical representation), and applying a font to get a visual representation both are processing.

    – WolfgangGroiss
    1 hour ago
















0














It's a really really big grid of numbers. Everything else is processing.






share|improve this answer








New contributor




WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 3





    so is JPG, TXT and everything else in computers ;-)

    – szulat
    2 hours ago






  • 1





    @szulat The difference is most of those other things have a single legitimate representation. Raw image data is like a latent negative, it still has potentially a near infinite number of ways it can legitimately be interpreted and displayed on a screen.

    – Michael C
    2 hours ago











  • @MichaelC but now you are talking about human creativity ;-) of course there are millions of ways we can process RAWs, JPGs and TXT files!

    – szulat
    2 hours ago






  • 2





    But there is only one correct way to display the JPG and TXT files. That's not true with raw image data.

    – Michael C
    2 hours ago











  • @szulat Correct. I didn't claim that's a unique quality of RAW files. JPG has a specification, so it's pretty clear how to get from the data to a visual representation. On the other hand, that clearly is processing. Text files don't even have that though - what does an unprocessed text file look like? Applying a character encoding to get from the binary data to unicode code points (or some other logical representation), and applying a font to get a visual representation both are processing.

    – WolfgangGroiss
    1 hour ago














0












0








0







It's a really really big grid of numbers. Everything else is processing.






share|improve this answer








New contributor




WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










It's a really really big grid of numbers. Everything else is processing.







share|improve this answer








New contributor




WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this answer



share|improve this answer






New contributor




WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









answered 3 hours ago









WolfgangGroissWolfgangGroiss

171




171




New contributor




WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






WolfgangGroiss is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 3





    so is JPG, TXT and everything else in computers ;-)

    – szulat
    2 hours ago






  • 1





    @szulat The difference is most of those other things have a single legitimate representation. Raw image data is like a latent negative, it still has potentially a near infinite number of ways it can legitimately be interpreted and displayed on a screen.

    – Michael C
    2 hours ago











  • @MichaelC but now you are talking about human creativity ;-) of course there are millions of ways we can process RAWs, JPGs and TXT files!

    – szulat
    2 hours ago






  • 2





    But there is only one correct way to display the JPG and TXT files. That's not true with raw image data.

    – Michael C
    2 hours ago











  • @szulat Correct. I didn't claim that's a unique quality of RAW files. JPG has a specification, so it's pretty clear how to get from the data to a visual representation. On the other hand, that clearly is processing. Text files don't even have that though - what does an unprocessed text file look like? Applying a character encoding to get from the binary data to unicode code points (or some other logical representation), and applying a font to get a visual representation both are processing.

    – WolfgangGroiss
    1 hour ago














  • 3





    so is JPG, TXT and everything else in computers ;-)

    – szulat
    2 hours ago






  • 1





    @szulat The difference is most of those other things have a single legitimate representation. Raw image data is like a latent negative, it still has potentially a near infinite number of ways it can legitimately be interpreted and displayed on a screen.

    – Michael C
    2 hours ago











  • @MichaelC but now you are talking about human creativity ;-) of course there are millions of ways we can process RAWs, JPGs and TXT files!

    – szulat
    2 hours ago






  • 2





    But there is only one correct way to display the JPG and TXT files. That's not true with raw image data.

    – Michael C
    2 hours ago











  • @szulat Correct. I didn't claim that's a unique quality of RAW files. JPG has a specification, so it's pretty clear how to get from the data to a visual representation. On the other hand, that clearly is processing. Text files don't even have that though - what does an unprocessed text file look like? Applying a character encoding to get from the binary data to unicode code points (or some other logical representation), and applying a font to get a visual representation both are processing.

    – WolfgangGroiss
    1 hour ago








3




3





so is JPG, TXT and everything else in computers ;-)

– szulat
2 hours ago





so is JPG, TXT and everything else in computers ;-)

– szulat
2 hours ago




1




1





@szulat The difference is most of those other things have a single legitimate representation. Raw image data is like a latent negative, it still has potentially a near infinite number of ways it can legitimately be interpreted and displayed on a screen.

– Michael C
2 hours ago





@szulat The difference is most of those other things have a single legitimate representation. Raw image data is like a latent negative, it still has potentially a near infinite number of ways it can legitimately be interpreted and displayed on a screen.

– Michael C
2 hours ago













@MichaelC but now you are talking about human creativity ;-) of course there are millions of ways we can process RAWs, JPGs and TXT files!

– szulat
2 hours ago





@MichaelC but now you are talking about human creativity ;-) of course there are millions of ways we can process RAWs, JPGs and TXT files!

– szulat
2 hours ago




2




2





But there is only one correct way to display the JPG and TXT files. That's not true with raw image data.

– Michael C
2 hours ago





But there is only one correct way to display the JPG and TXT files. That's not true with raw image data.

– Michael C
2 hours ago













@szulat Correct. I didn't claim that's a unique quality of RAW files. JPG has a specification, so it's pretty clear how to get from the data to a visual representation. On the other hand, that clearly is processing. Text files don't even have that though - what does an unprocessed text file look like? Applying a character encoding to get from the binary data to unicode code points (or some other logical representation), and applying a font to get a visual representation both are processing.

– WolfgangGroiss
1 hour ago





@szulat Correct. I didn't claim that's a unique quality of RAW files. JPG has a specification, so it's pretty clear how to get from the data to a visual representation. On the other hand, that clearly is processing. Text files don't even have that though - what does an unprocessed text file look like? Applying a character encoding to get from the binary data to unicode code points (or some other logical representation), and applying a font to get a visual representation both are processing.

– WolfgangGroiss
1 hour 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

Szabolcs (Ungheria) Altri progetti | Menu di navigazione48°10′14.56″N 21°29′33.14″E /...

Discografia di Klaus Schulze Indice Album in studio | Album dal vivo | Singoli | Antologie | Colonne...

How to make inet_server_addr() return localhost in spite of ::1/128RETURN NEXT in Postgres FunctionConnect to...