Search results

Interesting. Who would have thought that the hotness of the Canonrumors content depends on the vindaloo supply in your area. I'd expect it to be a wasabi-based dish for a greater immersion into the Japanese rumor flow...

Canon has to put some killer features in the R5II in order for me to preorder it. Rumoured 45Mp don't make me excited, I want more :). Fast electronic shutter might look interesting but still not enough. Dual gain output with high dynamic range in stills - potentially yes. Or anything that...

I think that might be because it's the last firmware update for the R5. Don't expect anything but occasional bug fixes, if any. Canon rounded it up so to say. The next actual firmware will be 1.0.0 for the R5II.

It'll work. If you mean unwanted bokeh artifacts, ES doesn't have them. You put mechanical and EFCS together as if they were the same but they aren't. It's EFCS that has problems with bokeh at wide apertures and fast shutter speeds. Mechanical has shutter shock issues at about 1/100 - 1/30s...

Digital sensors use electronic shutter every time you shoot in any shutter mode. E-shutter is just the normal readout process. If it's slow (which is the case for most of the modern sensors except a few very recent ones), then there's a physical curtain that works on top.

You already have it. With digital, it's always e-shutter, only in most cameras it's slow so there's a physical curtain on top. If Canon makes the speed of the e-shutter comparable or faster than a physical shutter, it'll be much better, including less banding at events with strobe light.

It encompasses the earth and shoots everything and everyone every second. Then you only need to crop.

But what about GPS? High dynamic range dual gain stills? Pixel shift that produces raw? Raw histogram?..

I hope there is an anti-dust curtain at least. It can be a cheap addition as it doesn't have to be fast and sophisticated. Nikon has such a curtain in top end cameras (called a sensor shield) Fast electronic shutter is almost as good as a global shutter. No rolling shutter effect, no issues...

To me it would depend on the base kit price, the features under subscription and the subscription cost. Depending on what's in the package, maybe I don't care at all, or maybe I'll switch the brand. Maybe a GFX100II is waiting for me somewhere in the stock storage... An R5 with RF 100-500 +...

I'd buy it if the basic version was around $500. It'd be much cheaper than some $5000 if I only use the camera for 5 years.

The R5 is already 44.5MP, you think it's too much and optimal resolution would be, say, 42MP? What kind of benefits you're expecting from lowering the pixel count by 3MP? If the 45Mp rumour is true, it's disappointing. Well it's not exciting at the very least.

I will know its real specs even without getting my hands on this camera.

It was already explained above in the thread, but it's interesting you didn't bother to actually take a square root of 1.5. Had you done so, you'd see the exact-exact multiplier.

It'll be a bit less than 5% increase in the linear resolution, providing the sensors are the same size. Not much.

The article has a number of errors. No, it's not 1.25. Take a square root of 1.5 and you'll see the actual gain in linear resolution. Next, the author uses dpi instead of ppi when talking about printing. When talking about the 'sensor size', the author completely loses the track and talks...

Pixel data (digital numbers) is compressed in CR3, so talking about 16-bit containers for 14-bit numbers in the raw files is absolutely meaningless which I tried to point out above in the thread.

There's too many assumptions :) But if they're all true, then again, raw file bitness refers to the content not to the container. There are container types used in CPUs but there's nothing really that's 16 bits in the CR3 files that would refer to pixels. When processing pixel raw data, the...

Statement about 16 bits was from the rumour, not from Canon.

There's no such thing as '16-bit capable file'. "16-bit raw file" is a misnomer or, best case, simplification. What they mean is each pixel needs at least 16 bits to be represented. The container size isn't a concern here.