As far as I remember, magic lantern uses mostly C or C++ for its code. Guessing Canon would do the same. You can write a LOT of statements in 20 literal lines of code with a language where statements are separated by semicolons
Another mention of a 70+ megapixel EOS R camera
- Thread starter Canon Rumors Guy
- Start date
Code:
#define ADC_RANGE (1<<14)
#define ADC_MAX (ADC_RANGE-1)
#define MAX_X 6720
#define MAX_Y 4480
int aiHistogram[ ADC_RANGE ];
memset( &aiHistogram, '\0', sizeof( aiHistogram ) );
for ( int x = 0; x < MAX_X; x++ )
for ( int y = 0; y < MAX_Y; y++ )
aiHistogram[ max3( aaiImage[x][y][0], aaiImage[x][y][1], aaiImage[x][y][2] ) ]++; // use max of RGBIf aiHistogram[ADC_MAX] is zero, then you're getting ALL the highlight detail and I think read noise and shot noise can be discounted.
If BOTH are true, scene DR < sensor DR capability. We therefore have a range of exposures that would capture the scene and we can choose which exposure we want, based on minimizing shadow noise and hand-holdability.
Specifically: if the camera seems to be on a tripod (based on motion sensor history), use ETTR: pick the slowest shutter speed that won't clip the highlights you do see. If the camera seems to be hand-held, get as close to reciprocal rule (adjusted by a factor for IS and an additional user preference for shorter or longer) as possible. This means if the SLOWEST shutter in your range is still ABOVE recip, use that slowest shutter. If the FASTEST is still BELOW recip, use the fastest (sacrificing shadow noise for an attempt to avoid camera motion blur). Otherwise use recip (minimizing shadow noise to the extent possible without going into camera motion blur territory.)
Examples for shooting with 50/1.4:
- Shutter could be from 1/90 to 1/320? Shoot 1/90.
- Shutter could be from 1/15 to 1/90? Shoot 1/50.
- Shutter could be from 1/4 to 1/15? Shoot 1/15.
And despite what the brain surgeon denies he's said before, doing this calculation wouldn't affect the histogram shown on the LCD, nor the live view image simulated exposure.
BTW, that suggestion is for modes full-auto, P, AP, where camera has free reign to decide shutter speed. For SP, where the camera has to decide aperture, you could likewise bias exposure towards say f/5.6 instead of recip, on grounds that 5.6 is nearly always the sharpest aperture, as well as rendering a healthy amount of the scen in DOF. It's unclear whether shallow DOF and soft image is worse than shadow noise, but say it is. (Or say the user has set a setting that it is.)
Examples for shooting with 50/1.4:
- Aperture could be from f/8 to f/22? Use f/8.
- Aperture could be from f/2 to f/8? Use f/5.6.
- Aperture could be from f/1.4 to f/2? Use f/2.
Last edited:
I coded it up; see my reply to Don Haines. And you know what? I coded it up literally waiting for a bus, because I don't want to take my Ferrari out in the rain. It was more like 9 lines, including some constants that surely are already defined elsewhere.
I'm curious what makes you think I have zero idea about this stuff? I've been writing machine language on 8-bit CPUs (a tougher task than most embedded systems today) since the 70s for instance, and programmed Linux system-on-a-chip systems. I've written software for a digital synthesizer, a very similar type of embedded system to a digital camera. I've used Photoshop since 5.0, and wrote software to do such things as HDR and focus stacking before there were even words for these things. I've been a professional software engineer since 1991 and a pretty elite one if paycheck is anything to go by. But maybe it's not. Maybe you can make good money as a programmer having zero idea how to program, zero.
Good question. I have two answers:
1) maybe because ETTR is preferable, to minimize shadow noise? In fact I'm not even saying shadow noise IS the priority, I meant the proposal as more of a question, and appreciate your answer that maybe it isn't.
2) maybe because as engineers, we don't know which a user will prefer at a given moment, so on the AE page we add some options: "smart ETTR" (my proposal), "ETTL" (your proposal), and maybe "ETTR" (make shadow noise a priority even if it pushes shutter speeds way past recip rule, or pushes apertures way lower than f/5.6).
Definitely, but I'm not sure it wouldn't be utterly negligable. My guess is that the amount of processing already going on is far, far, far more than collecting this one additional histogram.
I feel like using that animated gif on occasion.Then you weren't reading. I even repeated it for you.
How is that not correct? Or did you just fixate on the 'the number of users who would want that is likely insignificant' bit? That's also correct. The vast majority of ILC users never shoot RAW images.
One last time, and I do mean that. CANON COULD IMPLEMENT A RAW HISTOGRAM. Is that clear enough for you? Please, go back and read the capitalized words one more time. Or the blue text above. Heck, read them all. Then do it again. Then once more, for good measure. This is the second time you've argued that Canon can implement a RAW histogram after I already stated they could, if they wanted to. If they did, of course they would not eliminate the 'standard' (jpg-based) histogram, that's a rather silly strawman you've created there. Honestly, the fact is you seem sadly confused on this whole issue, you keep perseverating on arguing that something is possible when we both agree that it's possible. The fact of the matter is that Canon has not chosen to do so, nor have they chosen to implement hundreds of other features for which a handful of people on this forum have expressed a desire. Feel free to re-state your repetitive argument that Canon can add a RAW histogram in a pointless attempt to convince me of something that I've stated repeatedly is true...I'm out.
One of the reasons why I am waiting for the effing G7X III is that with it I expect to be able to write code that will run on my phone, connect to my camera, put it into manual mode and control its aperture, shutter speed and ISO as I would want them to be controlled in my personally designed scene modes - and maybe even automatically choose scene modes based on deep neural network classification of the live view content, but that will surely require a lot of phone battery power. Maybe my phone will also be able to predict the exact moment to take the shot.
That would definitely bring posting cats on the internet to a totally new level.
Granted, I could already try doing it on EOS RP, but I'm not going to buy a $1.3k camera just for that. When its price drops below $1k or Canon makes a 70+ MP cat shooter controlled with CCAPI, I may consider buying them.
(I cannot yet say that I am totally serious, but this is definitely not just a joke)
And yet, you still have not installed it to prove your work. So until then, the code is worthless and unproven. Harry may be able to give you a lift if his helicopter is out of the shop. That should save you a few nickels in bus fare until it stops raining and you can get the Ferrari out again.
What makes me think you know nothing about programming a Canon camera? I'll gladly acquiesce when you've got your code running and do a working demo.Just point out the error if you see one. Anyone can. There's scads of guys doing embedded software on this very forum. I'm sure someone will take issue if they see why it wouldn't work. I'm sure you would if you were in software. I thought from your know-it-all tone that you were but it turns out you're not, and are simply calling bullshit on things you don't understand.
But what the heck is your actual point? You want to clamp down on anyone speculating how our Canons work, or wondering aloud what new features might be nice, unless they can actually modify existing production hardware to demo the feature in question? You set that same high bar for people saying they wished their EF24-70/2.8 was IS? "There's the lens, go modify it and until you deliver a demo unit in working order I'm just going to cover my ears and scream because there's no point talking about things that might not currently exist and therefore are utterly impossible until I see it with my own eyes?" You do that in all aspects of your life or just with cameras? Do you scream at your wife like that when she muses about painting the living room white? "Shut up, white's not even a color! You're wrong it exists! And I won't discuss whether it'd be a good idea to paint it white until you actually do so!"
His point is that even if your code is perfect, unless it’s installed and running on your camera, including full and debugged integration with the camera’s firmware, it’s useless. Not worth the time you wasted writing it.
Hey, maybe you could get your code incorporated into Magic Lantern? Then ML could have a RAW histogram. Oh, wait...ML already has a RAW histogram, as was pointed out earlier in this thread.
So other than repeatedly arguing points previously stipulated, writing code that cannot be tested or used, and asking for a feature from people who have zero power to implement it instead of asking those who do, what have you accomplished here?
I would have been impressed if you had a back up vehicle for rainy days.
Don't the vast majority of mirrorless cameras (maybe even all of them?) not do a full scan/processing of the sensor to display preview images and information, such as histograms, on the EVF? Don't they use line binning or other such shortcuts to reduce the processor load required to provide the EVF with those things? Wouldn't that mean in order to process the output from the entire sensor to do such precise metering it would require additional processing compared to what they are now doing?
Even Magic Lantern's RAW histogram feature doesn't actually use the full data of the RAW capture, but the RAW data from the much lower resolution video feed.
Given that parking in Tokyo can be up to $700/month, few people have two cars, but for whatever reason I do have an E39-generation BMW M5 that I've carried with me in about four international moves and still love. But it's getting its bi-yearly inspection. In Tokyo mass transit can be better than driving in some cases--the only chance I have to keep on top of the Economist for instance.
Last edited:
From what you write I'm pretty sure you realize this but others on the forum don't seem to. The fact that AE might putatively have a raw histogram for the purposes of AE doesn't mean that this histogram would be used for the EVF. You could totally use an internal raw histogram for purposes of determining exposure, while using the JPG-dynamic range histogram to show the user a graph, to do over/under exposure blinkies, and to make the EVF image.
Perhaps, but doing it once ought not be significantly taxing. Maybe sensor read speeds would need improvement first, though.
If you are going to display the image on the LCD screen, then you need to process the RAW files, and in order to get the colour information you have to read each pixel. Obviously, Canon has already written the software to do so
Michael was suggesting, I believe, that some subset of the full resolution is rendered for the live view display. It’s plausible but I have no idea if it’s true.
It is true. For people who want to know stuff about the internal workings of Canon's non-dual pixel cameras, the magic lantern forum contains a ton of information.
CR for the humour ... even when I don't understand much, there is always a laugh.
Jack
Jack
The 6Dii was a turd and the 5Ds was such a niche camera aimed at such a small number of shooters that hardly anyone bought it. Those are the first two mirrorless versions you want to make? Really? Not a mirrorless 5DIV or 1DxII which are much better cameras and much better sellers? Pure stupidity on Canon's part. Besides, the EOS R is the mirrorless 5DIV Im sure. Canon is inept, they lack the ability to keep up with Sony in processors and sensors. They don't have a prayer at making anything to keep up with the a9. They should just stick to making lenses, thats always been their strength anyways.