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?
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
add a comment |
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
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
add a comment |
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
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
raw image-processing
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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:
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:
(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:
... 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:
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:
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:
... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:
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:
... or, for the full-sized image:
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:
... 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.
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
add a comment |
It's a really really big grid of numbers. Everything else is processing.
New contributor
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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:
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:
(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:
... 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:
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:
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:
... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:
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:
... or, for the full-sized image:
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:
... 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.
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
add a comment |
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:
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:
(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:
... 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:
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:
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:
... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:
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:
... or, for the full-sized image:
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:
... 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.
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
add a comment |
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:
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:
(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:
... 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:
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:
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:
... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:
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:
... or, for the full-sized image:
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:
... 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.
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:
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:
(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:
... 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:
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:
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:
... and here's the same area with the simple grayscale conversion. You can see the stippling from the X-trans pattern:
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:
... or, for the full-sized image:
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:
... 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.
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
add a comment |
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
add a comment |
It's a really really big grid of numbers. Everything else is processing.
New contributor
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
add a comment |
It's a really really big grid of numbers. Everything else is processing.
New contributor
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
add a comment |
It's a really really big grid of numbers. Everything else is processing.
New contributor
It's a really really big grid of numbers. Everything else is processing.
New contributor
New contributor
answered 3 hours ago
WolfgangGroissWolfgangGroiss
171
171
New contributor
New contributor
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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