Canon EOS R5 Mark II to arrive before EOS R1? [CR2]

[neuroanatomist]

You don't seem to understand. It has less to do with construction and more to do how today's cameras market looks through consumers's eyes (in a world dominated by smartphones) and also how quickly newer parts are available for manufacturing. Sony has seemed to adopt to this quite well, and I don't see why all the others would not follow to compete, probably in a middle-state that is not as quick as it was in the early days or mirrorless but also not as slow as it was in the DSLR era.
.
MILCs are more like smartphones, e.g. upgrading them frequently is more incentivized by some new technology, whether that's a new sensor (with smartphone-like processing features like handheld HDR), processor (AI, better energy efficiency), new batteries, new screens. (That's something Sony can do any time, or in Canon's case they always make some tweaks to their bodies, so they could add things like full-size HDMI)
The R1 is likely to be the first representative of the new generation, but after that, some of its features will start to tickle-down to the rest of the range even though this generation is still quite new.

Canon updated the R6 'early' and while that may be the start of a trend, it's really hard to support that with a single data point. There's still no R1, they did not update the R5 that was launched alongside the R6. The rapid update cycle typically applies more at the low end than at the high end, especially since it's those models that are in 'competition' with smartphones at the price level. The xxxD DSLRs were updated annually for many years, while the xxD and xD updates were much less frequent. Most likely, the same will be true for the R series.

Consider that Canon has steadily gained MILC market share on Sony and last year they overtook Sony as the #1 MILC brand in Japan. I don't follow Sony closely, but if as you say they have had a rapid update cycle while Canon has kept to a slow introduction/update of their MILCs, and Canon has overtaken Sony anyway...why would Canon change their strategy since it's evidently been successful?

It's more about the present than the past...

Camera sales increase with mirrorless lenses growing in popularity - IFA Newsroom

Data provided by CIPA shows that camera sales, especially for mirrorless models, are increasing with heightened demand around the world.

news.ifa-berlin.com

Mirrorless cameras set to drive market growth - IFA Newsroom

The forecast comes in ResearchandMarket.com’s latest report entitled "Mirrorless Camera Market - Forecasts from 2021 to 2026".

news.ifa-berlin.com

Yes, MILC sales are finally growing slightly. Yay. When you look back at the past, it's clear that MILCs have a long way to go to make up for the industry losses...

 

[John Wilde]

Jup... Common sense.
In the last decade ILC market has shrunk. The technology has matured... Why isn't Canon releasing new cameras like crazy???
Especially now that cameras don't have mirrors slowing down product cycles.

In 2022-2023, Canon has released 6 new camera bodies, and Nikon has released 1.

 

[cayenne]

Still happily using the 5D IV.

I still have my 5D3....but hoping for a R52 coming soon, and I'm planning to pull the trigger for it.
I have the funds in savings now...so, Canon..."Please take my money"!!


cayenne

 

[David - Sydney]

We don't know whether those improvements are due to the processor or from other power saving methods. But, the main point under discussion is whether the R5 has an older version processor than the Digic X in the R10, R50, R8, R7, or R3.

It would be speculation then as we don't have a base line eg mark 1 vs mark 2.
In terms of power savings options, IBIS will draw power of course so with/without would make a difference.
The sensor and refresh rate / type of EVF/rear screen would also be options but I am guessing that the processor is the big power consumer. More efficient SW would be great but the one big advantage would be line width for the processor. Of course, a combination all adds up.

It is clear that Sony's net power usage is more efficient than Canon overall based on the CIPA shot count vs battery capacity. The only major difference is the use of SD cards vs SD/CFe type B. That said, I don't know whether the CIPA standard allows for only one card to be used during the test ie the SD card in both Sony and Canon. In that case, the only big variable is the processor.
Sony would have some leverage for processors based on the PS5 which uses a custom SoC designed in tandem by AMD and Sony, integrating a custom 7 nm AMD Zen 2 CPU with eight cores running at a variable frequency capped at 3.5 GHz.

 

[dolina]

I still have my 5D3....but hoping for a R52 coming soon, and I'm planning to pull the trigger for it.
I have the funds in savings now...so, Canon..."Please take my money"!!


cayenne

Your 5D3 would be a dozen years old when the R52 comes out before July 2024.

Really wish Canon could use the 3nm A17 SoC. Sips power and would be able to process images like no body's business.

 

[David - Sydney]

We don't know whether those improvements are due to the processor or from other power saving methods. But, the main point under discussion is whether the R5 has an older version processor than the Digic X in the R10, R50, R8, R7, or R3.

Speculation is tricky... thermal comparisons is all we can really look at unless teardowns of the different bodies show the processor/heatsick configurations.

Thermal limits are not just processor driven but overall body temperature where the size/thermal spread makes a difference (keeping in mind that Sony's bodies are smaller than Canon in general).

I would suggest that the R5 was pushing the envelop for what the Digic X could do at the time with heat being the primary limitation. Video comparisons keep the EVF/AF tracking consumption the same whereas stills comparison are pretty hard to do with buffer speed/depth being additional constraints.
Line skipped 4k120 has the lowest recording time based on thermal cutoffs with 4KHQ not far behind and then 8k/30 raw.
4k120 and 8k30 could be more heat intensive at the CFe card but 4kHQ more intensive at the processor.
The addition of raw lite codecs reduces the card bandwidth but increases the CPU work... suggesting that the card is a bigger issue thermally for the body. The use of 4k120 being recorded at 4k30 but 3 times the normal speed and hence no audio probably speaks to processor capacity rather than card limitations.

The R3 has better thermal dissipation (larger body) characteristics, has the same card slots as R5 but bigger battery capacity. Less pixels for AF tracking though
4k60 raw has the same bandwidth to the card as the R5's 8k30 rate but I can't find the recording limit before thermal cutout.

I don't think that we can make any meaningful guesses on different processors for different models. It is easier to have one SKU from the fab and adjust performance in SW than having multiple SKUs and potential supply chain issues. ROI with one SKU makes more sense as well. The downside is having one physical package which could be large to then fit into smaller bodies. If cores can be turned off ie less consumption/heat then smaller heatsinks (if any) for smaller bodies could assist.

The current leading edge technology for SoC low power processors (looking at you Apple) could be turning off cores or using specific low power cores to reduce power (consumption and heat). Sounds ideal to apply something similar for cameras but I imagine that would be the next generation.

 

[Czardoom]

Waiting 3+ years is long for me. I don't know what is "expected" for you, so you can have your own opinion on that.
I have found that the EM1_II was easier to setup and use than my R5. That's my opinion as an owner of both. You have your own evaluation so I respect your opinion on it. I do find that the R5 & lenses give me appreciably better photos, but at a much higher cost and a loss of mobility & ease of use.
If Canon knew "far better than any forum participant what the good ideas are" then I, and others, wouldn't be griping on how they should add this or that feature which is only a firmware update. There are many things they could do better, and if they had a regular way to accept & acknowledge input from users then they would be better off for it. FWIW, I have found all manufacturers I've used to have the same issue with ignoring common users, so it's not just Canon I'm talking about regarding that.

I find lots of users griping about things, but even if lots of forum users are griping, that does not mean that a majority - or even a large number - of Canon users would agree that those gripes are going to make the cameras better. My guess is that for every suggestion made, there are an equal number of people who would not want that suggestion implemented. And quite frankly, we have no idea how many user suggestions have made it into cameras over the years. Nor how many of those great suggestions are actually do-able.

I would guess (although I do not know) that only a small percentage of those griping here have ever actually contacted Canon or used their community forums to actually reach out to Canon with their suggestions. Although I am sure many folks here see me as a Canon fanboy because I don't complain about their cameras, I don't waste my time by doing it here. I recently suggested on a Canon site, that Canon should implement Focus Limiting settings in-camera ( A great feature on Olympus and now OM system cameras). It's the reason I prefer my OM-1 to to my R7 for Birds in Flight photography.

As Neuro mentioned, at a certain point adding too many of those suggestions would lead to menus that are nu-navigatable. As a long time Olympus user, I would say one of the biggest complaints about Olympus is their overly complex menus.

I find your final comment rather illuminating. You wrote, "I have found all manufacturers I've used to have the same issue with ignoring common users, so it's not just Canon I'm talking about regarding that." Maybe that should tell you that the manufacturer's - who have in many cases done tons of market research and spent lots of money doing so - are not ignoring common users at all - but are not in agreement with with what one person (or even a handful of forum users) feels is a good idea. If you have been on this forum over the years, I think you will realize that there is rarely any type of consensus.

 

[David - Sydney]

My guess is that for every suggestion made, there are an equal number of people who would not want that suggestion implemented. And quite frankly, we have no idea how many user suggestions have made it into cameras over the years. Nor how many of those great suggestions are actually do-able.

There are some things that should be easy to fix but Canon doesn't implement them and yet lower end bodies have that feature.
The R5 30 minute record time is a classic example. But you may say that it is market segmentation with the R5c but its cinema focus means more to those than just a 30 minute limit. It is hard to see the rationale even if I wouldn't be affected by that change. If Canon had wanted to really separate the R5 and R5c then they would not have added raw lite codecs and external 8k recording.

Also hard to understand why there is no ability to shoot inbetween 1 and 20fps. The coding was done for the R3 coding and could be added to the R5. If memory cards are cheap then it is just the time to review that is the issue... just an annoyance for the user.
Allowing the Rate button to be remapped should also be a simple improvement as the R5c allows all the buttons to be remapped in both video and stills mode... maybe there is a physical difference between R5 and R5c in this case.

Mechanical redesigns are hard but there are many SW features that should be relatively simple to implement. Formal "Change Requests" have to be evaluated before being planned. We will never know how their CRs are prioritised and complaining here won't help except maybe to vent occasionally.
Maybe these little things will be the biggest improvement in a R5ii

And yes, I have sent feedback to Canon on their support website.

 

[Czardoom]

There are some things that should be easy to fix but Canon doesn't implement them and yet lower end bodies have that feature.
The R5 30 minute record time is a classic example. But you may say that it is market segmentation with the R5c but its cinema focus means more to those than just a 30 minute limit. It is hard to see the rationale even if I wouldn't be affected by that change. If Canon had wanted to really separate the R5 and R5c then they would not have added raw lite codecs and external 8k recording.

Also hard to understand why there is no ability to shoot inbetween 1 and 20fps. The coding was done for the R3 coding and could be added to the R5. If memory cards are cheap then it is just the time to review that is the issue... just an annoyance for the user.
Allowing the Rate button to be remapped should also be a simple improvement as the R5c allows all the buttons to be remapped in both video and stills mode... maybe there is a physical difference between R5 and R5c in this case.

Mechanical redesigns are hard but there are many SW features that should be relatively simple to implement. Formal "Change Requests" have to be evaluated before being planned. We will never know how their CRs are prioritised and complaining here won't help except maybe to vent occasionally.
Maybe these little things will be the biggest improvement in a R5ii

And yes, I have sent feedback to Canon on their support website.

You say these things would be easy to implement, but do you actually know? Ever written firmware for a camera? The 30 minute time limit has been discussed many times, but does anyone actually know the answer? I have seen some folks say that at the time of the camera's registration, if that 30 minute time limit was still an issue in some countries, then you can not change it. Once registered, it is fixed. I have no idea if this is true, do you? I once saw an interview with someone who was part of the firmware team for Olympus. Some suggestions were made of what could be added. He said if some items were to be added, others would have to be removed. My guess is - every time some forum warrior proclaims that something would be easy to add or fix, it would not be. The number of non-experts who think they know better on the internet is unfotunately huge. Not saying this applies to you - you have always been a thoughtful and knowledgeable forum dweller, but let's be real. We are not experts.

 

[neuroanatomist]

You say these things would be easy to implement, but do you actually know? Ever written firmware for a camera? The 30 minute time limit has been discussed many times, but does anyone actually know the answer? I have seen some folks say that at the time of the camera's registration, if that 30 minute time limit was still an issue in some countries, then you can not change it. Once registered, it is fixed. I have no idea if this is true, do you? I once saw an interview with someone who was part of the firmware team for Olympus. Some suggestions were made of what could be added. He said if some items were to be added, others would have to be removed. My guess is - every time some forum warrior proclaims that something would be easy to add or fix, it would not be. The number of non-experts who think they know better on the internet is unfotunately huge. Not saying this applies to you - you have always been a thoughtful and knowledgeable forum dweller, but let's be real. We are not experts.

Even if 'easy' to implement, each feature requires testing when ported to cameras and/or with each new firmware update. As an example of the complexity, there was a firmware bug when the 1D X was released that resulted in lens-specific AFMA values not being stored, but only if the orientation-linked AF point setting was enabled (it's off by default). I have no idea why those two functions are linked in firmware, but that does show that these 'easy to make' changes are likely not as easy as people seem to think.

 

[dolina]

You say these things would be easy to implement, but do you actually know? Ever written firmware for a camera? The 30 minute time limit has been discussed many times, but does anyone actually know the answer? I have seen some folks say that at the time of the camera's registration, if that 30 minute time limit was still an issue in some countries, then you can not change it. Once registered, it is fixed. I have no idea if this is true, do you? I once saw an interview with someone who was part of the firmware team for Olympus. Some suggestions were made of what could be added. He said if some items were to be added, others would have to be removed. My guess is - every time some forum warrior proclaims that something would be easy to add or fix, it would not be. The number of non-experts who think they know better on the internet is unfotunately huge. Not saying this applies to you - you have always been a thoughtful and knowledgeable forum dweller, but let's be real. We are not experts.

Sometimes it is market segmentation.

Feature X may be designated for low-end while feature Y is for high-end.

The 3rd party firmwares tend to added these features to circumvent the arbitrary marketing decisions.

That's the only way they'd be able to get a better margin.

 

[AlanF]

My guess is that for every suggestion made, there are an equal number of people who would not want that suggestion implemented.

Maybe for most, but not all. What about, for example, the R5's electronic shutter being fixed at 20 fps without the option for lower fps, the most common gripe?

 

[David - Sydney]

You say these things would be easy to implement, but do you actually know? Ever written firmware for a camera? The 30 minute time limit has been discussed many times, but does anyone actually know the answer? I have seen some folks say that at the time of the camera's registration, if that 30 minute time limit was still an issue in some countries, then you can not change it. Once registered, it is fixed. I have no idea if this is true, do you? I once saw an interview with someone who was part of the firmware team for Olympus. Some suggestions were made of what could be added. He said if some items were to be added, others would have to be removed. My guess is - every time some forum warrior proclaims that something would be easy to add or fix, it would not be. The number of non-experts who think they know better on the internet is unfotunately huge. Not saying this applies to you - you have always been a thoughtful and knowledgeable forum dweller, but let's be real. We are not experts.

Only seeing the internal Canon Change Request would provide the estimated internal cost. It would include the problem investigation cost, the coding, testing and documentation update cost. There would also be a small marketing cost for announcement/update on company websites if it was the only update which is unlikely.

That said, I have written code in the past but not firmware for cameras. Something like the 30 minute limit was originally due to the European importation/duty rates where movie cameras had a higher duty than stills cameras and the 30 minute recording time was the deciding factor between stills/movie. That duty rate was removed a number of years ago so it is not relevant for the R5.

The 30 minute limit is a simple table lookup value. If removing all the logic was costly then changing it to 300 minutes would be the simple solution.

 

[David - Sydney]

Maybe for most, but not all. What about, for example, the R5's electronic shutter being fixed at 20 fps without the option for lower fps, the most common gripe?

Hard to comment about how common the gripe is but it looks to be a simple issue to fix especially as the R3 had the code written to offer different rates. This "feature" is not a blocking one like the 30 minute record time. It is just annoying for users to need memory storage and time to review them in post.

 

[David - Sydney]

Even if 'easy' to implement, each feature requires testing when ported to cameras and/or with each new firmware update. As an example of the complexity, there was a firmware bug when the 1D X was released that resulted in lens-specific AFMA values not being stored, but only if the orientation-linked AF point setting was enabled (it's off by default). I have no idea why those two functions are linked in firmware, but that does show that these 'easy to make' changes are likely not as easy as people seem to think.

A bug ("phenomenon" in Canon parlance) isn't the same as a new/updated feature. Canon can be very quick to fix phenomenons in a firmware update.

Canon was quick to update to firmware 1.1 on the R5 and it included a bunch of improvements but most importantly addressing the overheating concerns from reviewers (which was completely overblown) from using a timer to actual temperature measurements.
Some phenomenon can be fixed within weeks.
Something like fixing the R5's occasional freezes for some people was variable to say the least due to the complexity to replicate the scenarios.

9-July R5 announcement date
30-July R5 shipping
27-August FW1.1 announced
Early September 1.1 available for download
10-September FW1.1.1 was available improving the RF100-500 CIPA stability and fixing a phenomenon.

With any new product release - especially with the complexity of the R5, the number of initial bug fixes would be high and the R&D team would still be mobilised to support that product after launch for a period of time so there were available resources. Clearly, they get reallocated to other new products after that.

 

[neuroanatomist]

Hard to comment about how common the gripe is but it looks to be a simple issue to fix especially as the R3 had the code written to offer different rates.

The R3 maintains 14-bit RAW shooting regardless of fps. The R5 drops to 13-bit with H+ mechanical/EFCS and 12-bit with full electronic shutter.

Just one example of how what may seem simple often is not.

 

[neuroanatomist]

A bug ("phenomenon" in Canon parlance) isn't the same as a new/updated feature. Canon can be very quick to fix phenomenons in a firmware update.

Canon was quick to update to firmware 1.1 on the R5 and it included a bunch of improvements but most importantly addressing the overheating concerns from reviewers (which was completely overblown) from using a timer to actual temperature measurements.
Some phenomenon can be fixed within weeks.
Something like fixing the R5's occasional freezes for some people was variable to say the least due to the complexity to replicate the scenarios.

9-July R5 announcement date
30-July R5 shipping
27-August FW1.1 announced
Early September 1.1 available for download
10-September FW1.1.1 was available improving the RF100-500 CIPA stability and fixing a phenomenon.

With any new product release - especially with the complexity of the R5, the number of initial bug fixes would be high and the R&D team would still be mobilised to support that product after launch for a period of time so there were available resources. Clearly, they get reallocated to other new products after that.

My point is that fixing a bug or adding a feature often have complexities that are not obvious to people not involved in a product’s development.

Also, you cannot necessarily infer that because a problem is rapidly addressed via a firmware update, the fix was simple and quick. The same is true for additional features added the updates. New cameras and new firmwares are always beta tested prior to public release. In many cases, problems that are identified or features that are requested during that beta testing are pushed off to a future release or update, because timelines must be met. Obviously, I have no inside knowledge on this, but it’s quite possible that the 100-500 issue with the R5 was noticed and reported by testers under NDA before the R5 launched, but canon could not fix the issue in time to meet the launch deadline, so they went ahead and continued working on the fix, which, then only appeared to be a rapid response.

 

[David - Sydney]

The R3 maintains 14-bit RAW shooting regardless of fps. The R5 drops to 13-bit with H+ mechanical/EFCS and 12-bit with full electronic shutter.

Just one example of how what may seem simple often is not.

Wouldn't that be an example of the sensor difference rather than coding?

 

[David - Sydney]

My point is that fixing a bug or adding a feature often have complexities that are not obvious to people not involved in a product’s development.

Also, you cannot necessarily infer that because a problem is rapidly addressed via a firmware update, the fix was simple and quick. The same is true for additional features added the updates. New cameras and new firmwares are always beta tested prior to public release. In many cases, problems that are identified or features that are requested during that beta testing are pushed off to a future release or update, because timelines must be met. Obviously, I have no inside knowledge on this, but it’s quite possible that the 100-500 issue with the R5 was noticed and reported by testers under NDA before the R5 launched, but canon could not fix the issue in time to meet the launch deadline, so they went ahead and continued working on the fix, which, then only appeared to be a rapid response.

We are on the same page
Sure, I have no issues with problem resolution leadtime being different to release date schedule... but Canon have been quick to fix phenomenons created by firmware releases or have pulled firmware updates if they couldn't quickly fix them.
I guess my point is that Canon can react quickly if they choose to. What they choose to be quick about is nebulous to outsiders assuming there is a fix.

Changing from timers to actual temperature sensors would have involved a lot of quick testing that Canon that would not have anticipated. They thought that it was pretty important to counter the reviewer's storm-in-a-teacup/3-video-modes response to the introduction of a new benchmark body. They even did a press release about the actual times which is very unusual for them.

 

[neuroanatomist]

Wouldn't that be an example of the sensor difference rather than coding?

Are you saying that the coding is independent of the sensor? So what happens when you change the fps setting…the sensor magically knows and adjusts the bit depth accordingly? Then the RAW converter uses the same exact algorithm to reduce 14, 13 or 12 bits to 8 bits?