CRguy put the answer to your question right in the post with an embedded link, and you even copied that link in your post. Sorry, but are you really that lazy?
Upvote
0
Multiple RAW image resolutions coming to the Canon EOS R5 Mark II?
- Thread starter Canon Rumors
- Start date
unfocused
Photos/Photo Book Reviews: www.thecuriouseye.com
I’m not interested in less resolution. Give me 60mp and CRAW and I’m happy. If you don’t want or need 60mp then buy an R6. Don’t compromise stills performance for video. Buy the R5 II Cinema model if video is your priority. I’d rather Canon forgo gimmicky resolution and video tricks and just give us a 60mp R5II with modest, evolutionary improvements in autofocus and other features. They can skip eye-control autofocus and the pre-shot recording too as far as I’m concerned. Neither are worthwhile in my experience.
Upvote
0
I shoot events and landscapes. 60MP fine for landscapes (although I am happy with 45MP), but 20 MP is ideal for events, so I had an R5 and R6. However, for events, I need two bodies, and can't justify 3 bodies. The ability to shoot a higher MP body at around 20MP would be great. Its not clear to me why that would compromise those who just want 60MP.
And yes, I shoot CRaw.
Upvote
0
Look at it another way: lower resolutions would not prevent you from shooting full resolution. It would get more out of the camera's buffer and memory cards, which some photographers would consider not a gimmick. Canon would rather not lose opportunities to sell more expensive cameras, with higher profit margins.
Question is how usable the lower resolution raw files be. I use DXO Photolab, which did not process sraw & mraw, so I skipped them. They were dropped in the R5 in favor of craw, so apparently there's sufficient demand for something better.
I think lower resolution stills make as much sense as lower resolution video - saves on disk space and processing power as well. Personally, I don't care for 60MP, so I might downgrade to R6 when my R5 breaks, or an R6 mark whatever would make an attractive proposition.
Upvote
0
unfocused
Photos/Photo Book Reviews: www.thecuriouseye.com
I should clarify. I would have no problem with less resolution as an added option. I just want to make sure that the don’t compromise full raw and c raw. Same with video. I don’t want to have less of a stills camera for the sake of video and that would include limiting the resolution.
Upvote
0
It's a DNG file according to the metadata, the 18 MP files as well.
Quote from the German website: "wählen Sie zwischen 60, 36 oder 18 Megapixeln Auflösung für DNG und JPG"
"Choose between 60, 36 or 18 MP resolution for DNG and JPG"
Upvote
0
Thanks. CRguy stated, “This is something that we have seen recently in some Leica cameras. Their latest cameras offer 60mp, 36mp or 18mp RAW stills shooting using the entire sensor.”
DNG ≠ RAW. Apple’s ProRAW is a DNG file, and it’s heavily pre-processed. Leica is scant on details, but from what I can tell they’re downsampling the image data before demosaicing. To me, that’s not RAW. Pixel binning can yield a smaller RAW file, but that’s not what Leica is doing – the steps are wrong, a 2x2 binned file from a 60 MP sensor would be 15 MP. Anything in between is interpolated and therefore not RAW.
Upvote
0
Its called pixel binning - where by say 2 adjacent pixels are averaged together across, and then down, to make a smaller image. Depending on how fancy they get, this can be interpolated to average 1.5 pixels together with software tools like drizzle that interpolate between pixels. But it works pretty well. Its used extensively in astrophotography, so not really breaking new ground.
About shutter speed - I suppose its always best to plan for the highest resolution. But how much cushion the lower res modes buy you will have to be tested once its on the market. A lot will depend on implementation.
Brian
Upvote
0
That’s an interesting —and disturbing— suggestion. I’ve taken it for granted that including video is benign, and if anything either adds functionality (e.g., more controls that can be reassigned to stills functions) or lowers costs by broadening appeal.
But your statement highlights the fact that the R5’s horizontal pixel count is exactly that needed for 8K DCI video. That’s not likely a coincidence, but rather is why the R5 is 45 MP and not 50 MP, etc.
Food for (uncomfortable) thought…
Upvote
0
yeah where is the difference nowadays?! I don't get it. Also I don't get it that its gone since the EOS R... was the same sensor as the 5DIV which had this...
Upvote
0
I think what we have here, and what will likely continue to be more prevalent, is camera makers giving us RAW files that are not RAW files in the strictist terms, but files processed and saved as DNG (or perhaps even given the RAW or other new extension names) that can be opened and edited in RAW editing software. Which should be good enough for 99% of us, even if it isn't really RAW.
Upvote
0
Personally, I'm fine with that as long as it can be treated as such by my preferred RAW converter (DxO PhotoLab). Canon's mRAW and sRAW formats were not handled by DxO, nor are the DNG files from Apple's ProRAW.
Upvote
0
Raw data has interspaced RG/GB pixel elements. To "pixel bin" is to combine neighboring pixel sensors. But you can't do that if your neighboring sensor pixel elements are of different color and you want the output to be in a "raw" pattern of RG/GB nature. So you should ignore the simple term "pixel binning" if you want to output raw data.
If you look at the CR3 algorithm, you can see that they look at each color's pixel elements separately and then convert pixel pairs to pixel averages and differences in a horizontal and vertical pass (I'd call an "image pass"), and repeat this image pass 3 times. You could strip out just the first averaged quadrant of the first image pass to have "1/4" size indeed, or you could strip out the averaged quadrant of the 2nd pass for "1/16th", or the averaged quadrant of the 3rd pass for "1/64th size. But this is still reading the entire sensor, doing CR3 compression and outputting a different slice of it and throwing away all the remaining data.
If you really wanted to do just that (and throw away all the other data which is really important), there are other "wavelet" compression schemes that would give you a better reduced-size image quality of averaged pixel elements than that. I say this because I have used one of them in the past, and it was designed to use a single horizontal and a single vertical pass to combine a much longer set (than just 2) of neighboring similar pixel elements together with appropriate weighting to yield a single pixel to get a result in one "image pass".
The problem with both of these techniques is that while the reduced averaged data has been done for R, G, and B separately, it is now WITHOUT the "raw" nature of having them still in a RB/GB nature. Now they're in an overlaid RGB nature together per pixel, which is akin to de-Bayer'ing and size reducing the image. If that's all you want, then you're just competing with jpg or heif for a reduced size non-raw output.
If I was in charge at Canon, for "raw output" I'd use quadrature encoding & run length output (what CR3 basically is) but keep it lossless and tell the user what that output size is as a percent of the original. Then if they want the size reduced further I'd use different amounts of "low bit" discarding of the various quadrant sections (as intelligently needed per quadrant area) so that they have a smaller data size file (possibly a VERY small file) but still a RG/GB nature raw file of the original image size. To be clear, this very small encoded file would still be decoded (quickly) into a full size raw version so it'd work with PhotoLab, etc. You could make it easier on the user by asking them what maximum % of original file size they want the raw output to be and then they'd get the best image quality possible in a raw encoded format for full-size image output for the reduced file size wanted by the user.
If you look at the CR3 algorithm, you can see that they look at each color's pixel elements separately and then convert pixel pairs to pixel averages and differences in a horizontal and vertical pass (I'd call an "image pass"), and repeat this image pass 3 times. You could strip out just the first averaged quadrant of the first image pass to have "1/4" size indeed, or you could strip out the averaged quadrant of the 2nd pass for "1/16th", or the averaged quadrant of the 3rd pass for "1/64th size. But this is still reading the entire sensor, doing CR3 compression and outputting a different slice of it and throwing away all the remaining data.
If you really wanted to do just that (and throw away all the other data which is really important), there are other "wavelet" compression schemes that would give you a better reduced-size image quality of averaged pixel elements than that. I say this because I have used one of them in the past, and it was designed to use a single horizontal and a single vertical pass to combine a much longer set (than just 2) of neighboring similar pixel elements together with appropriate weighting to yield a single pixel to get a result in one "image pass".
The problem with both of these techniques is that while the reduced averaged data has been done for R, G, and B separately, it is now WITHOUT the "raw" nature of having them still in a RB/GB nature. Now they're in an overlaid RGB nature together per pixel, which is akin to de-Bayer'ing and size reducing the image. If that's all you want, then you're just competing with jpg or heif for a reduced size non-raw output.
If I was in charge at Canon, for "raw output" I'd use quadrature encoding & run length output (what CR3 basically is) but keep it lossless and tell the user what that output size is as a percent of the original. Then if they want the size reduced further I'd use different amounts of "low bit" discarding of the various quadrant sections (as intelligently needed per quadrant area) so that they have a smaller data size file (possibly a VERY small file) but still a RG/GB nature raw file of the original image size. To be clear, this very small encoded file would still be decoded (quickly) into a full size raw version so it'd work with PhotoLab, etc. You could make it easier on the user by asking them what maximum % of original file size they want the raw output to be and then they'd get the best image quality possible in a raw encoded format for full-size image output for the reduced file size wanted by the user.
Last edited:
Upvote
0
Given that Canon doesn't even let the user specify a frame rate (outside of the 1-series), I can't really see them giving the user a free choice of output resolutions. Rather, they'll go the Leica route and select 2-3 smaller-than-maximum output options. OTOH, there are actually 8 JPG output options (5 sizes and two levels of compression), so maybe they'll offer several choices for pseudo-RAW output if the native resolution is high enough.
Upvote
0
Actually, the R5 already supports the so-called 'C-Raw' which is the same image size (8192x5464) and bit depth as a 'normal' Raw, but roughly 1/2 file size (45.4MB vs. 21.9MB according to the R5 user manual) thanks to a slightly lossy compression - which is in my eyes not detectable even when viewing the pixels. A Raw file uses lossless compression.
Upvote
0
serious question... Why wouldn't they use cRaw format instead? If the issue is the resolution then cRaw doesn't help but if the issue is file size then shouldn't that be a simple solution?
Upvote
0
I shot CRaw on my 20 MP R6 - great for events where you shoot lots of relatively low res images. I would shoot 20 MP (or thereabouts) in CRaw if my R5 gave me the option. I have never needed more than 20 MP for events (and that even allows for some (limited) cropping), and so anything more simply consumes more space on my card or HDD. I'm not saying the R5ii should be 20 MP, but a 20 MP (or thereabouts) option would be great.
If you double the MP, you double the file size (all things being equal) but you only increase the linear resolution by 1.4 times.
Upvote
0
Similar threads
