Jump to content
Sign in to follow this  
hankg

Sign a petition for menu selectable lens profiles

Recommended Posts

Advertisement (gone after registration)

The lens table is already in the firmware. The table entry is selected via the lens coding and or the frame selector. As a software engineer, I know that adding a UI to allow the user to make the selection from the table is not difficult as they already have a drop down list component they can use that uses the scroll wheel and set buttons for selection. It is simple, low risk and would make many customers happy so why not do it? It is what we do when our customers ask for a feature. It's called picking the low hanging fruit.

Share this post


Link to post
Share on other sites

John, what you may have missed is that the lens code/frame selector position is detected by the M16C processor which has nothing to do with the back panel user interface, which is done by the Intel processor.

 

It's true that the support for the Tri-Elmar already integrates the two but adding this support probably requires extensions to the messaging interface between the two processors.

 

As such, it's not as trivial as some of the armchair programmers here might think.

Share this post


Link to post
Share on other sites

Mark,

 

As you point out the information is already carried across to support the Tri-Elmar, meaning the information is probably stored at some known location. Integrating that information into the selection logic (if one desires a more sophisticated selection schema) cannot be that difficult. Even armchair programmers could do it so I am surprised one as skilled as you are, make it out to be so difficult, unless you have a different agenda behind your statement.

Share this post


Link to post
Share on other sites

An earlier post from Sean indicated patience will be required. 2012 would suit me fine.

 

Indeed, Mark, but that's one perspective among thousands of M8 owners and potential owners. Not everyone's needs and priorities are the same.

 

Sean

Share this post


Link to post
Share on other sites
Mark,

 

As you point out the information is already carried across to support the Tri-Elmar, meaning the information is probably stored at some known location. Integrating that information into the selection logic (if one desires a more sophisticated selection schema) cannot be that difficult. Even armchair programmers could do it so I am surprised one as skilled as you are, make it out to be so difficult, unless you have a different agenda behind your statement.

 

Don't most programmers sit in chairs? Standing, it seems, would get so tiring.

 

Cheers John,

 

Sean

Share this post


Link to post
Share on other sites

No hidden agendas from me, but years have experience have shown me that changing interfaces between components is not to be undertaken lightly especially if you did not design the interface to start with and are still getting up to speed.

 

Suffice it to say, I would quote for more than a man-day to do the job...

Share this post


Link to post
Share on other sites

Advertisement (gone after registration)

Mark,

 

As you point out the information is already carried across to support the Tri-Elmar, meaning the information is probably stored at some known location. Integrating that information into the selection logic (if one desires a more sophisticated selection schema) cannot be that difficult. Even armchair programmers could do it so I am surprised one as skilled as you are, make it out to be so difficult, unless you have a different agenda behind your statement.

 

 

Bingo...

Share this post


Link to post
Share on other sites
No hidden agendas from me, but years have experience have shown me that changing interfaces between components is not to be undertaken lightly especially if you did not design the interface to start with and are still getting up to speed.

 

Suffice it to say, I would quote for more than a man-day to do the job...

 

I won't speculate as to the resources required. Anytime you alter code their is the potential of unintended consequences. But the fact is that Leica is pretty much continuously messing with the code to improve it. So this is really not an impediment.

 

It seems to me the basic objection to this feature is based on the false premise that every lens that CV sells is a sale lost for Leica. It seems evident that Leica has chosen not to make lenses outsourced to be manufactured in Asia at the price point of CV. The new Summarits look to be the bottom of the Leica price range. As such they are really not so much in competition with each other as having a sort of symbiotic relationship which is beneficial to both in the RF ecosystem. While there is some overlap each fills a different need and they both benefit from having those needs addressed as it makes for a healthier market for both players. Leica would be worse off today if CV had not entered the market.

Share this post


Link to post
Share on other sites
When lens coding was first announced in June 2006, Leica listed the current and discontinued lenses which could be coded and so benefit from in-camera image enhancements which at that time were unspecified. And so it has turned out.

Most other lenses manufactured since 1954 could still be mounted on the camera and used, but without the image enhancements. And so it has turned out.

When the IR problem was first recognised and disclosed..., Leica's very first response was to say the solution to the problem was to use a Leica coded lens and a Leica IR filter. And so it has turned out.

Seems to me Leica have been completely consistent in what they claim for the camera and lens compatability....

According to current M8 specs 'Almost all Leica M lenses with a focal length of 21-90 mm manufactured from 1954 can also be used without 6 bit-coding'.

Thoses lenses can be used for sure but the specs don't disclose that color shifts will occur with wides even with IR-cut filters.

Then either Leica update their specs or their software but they'd better make a move IMHO.

Share this post


Link to post
Share on other sites
Don't most programmers sit in chairs? Standing, it seems, would get so tiring.

 

Cheers John,

 

Sean

Well, actually, there's recent evidence--anecdotal on my part from folks I know--that the "ergonomic" chair+foot rest+massage, etc. has lost out to the old draughts-table set up with "task stool" and a lot of standing... yet, there ARE a LOT of cubed enivironments still in use:D. Many coders don't need a mouse(!), so the standing/higher workspace method is not as uncomfortable as it would seem... and yes, I'm sitting(task stool) as I write this. Standing, as with merely stepping away from the screen, is strongly recommended by all but the workspace/cube designers... and a few managers!

 

rgds,

Dave

Share this post


Link to post
Share on other sites
Mark,

 

As you point out the information is already carried across to support the Tri-Elmar, meaning the information is probably stored at some known location. Integrating that information into the selection logic (if one desires a more sophisticated selection schema) cannot be that difficult. Even armchair programmers could do it so I am surprised one as skilled as you are, make it out to be so difficult, unless you have a different agenda behind your statement.

The "information..carried accross to support the [WATE]" is based on the 6bit in-camera reader; yes, the data for this lens, and others is stored in f/w and called by the h/w 6bit reader routine, not the menu... the "menu" of the WATE FLs is called much further down the line, not by the user.

 

Leica(Jenoptik?) chose the lens code as the decision point to apply the color correction. Evident in the posts about "My hand-coded lens is not recognized", the design goal was to "fit the lens, determine its character and alter data processing based on this character... the charater of the light expected on the sensor."

 

While it seems to amaze, estoound and annoy, the "user override" suggested--no, petitioned--is simply contrary to the coded-lens-detection method, and falsely supported by the premise that "whatever the color correction algo available in firmware(and that's NOT open to tweaks, yet...), better to have the option to mis-apply than not at all." Next we will read of the "problem" introduced by an improvement in the algo for, say, the 24mm Elmarit that is no longer satisfactory for the ZM 25mm using the "no-impact, easy to implement menu item for user obviation of lens codes." Point is, Sean's tests are his tests, shared(by subscription) in the forever closed Adobe Flash data and are a poor substitute for the work that can be done with known(coded) 24mm lenses and the color corrections qualitatively, and demonstrably proven with the "IR Problem". In deference to Sean's work to which certain persons have subscribed, one could not have the merest clue that a CV 21mm lens would provide passable results using Leica's firmware color corrections. And with respect to those who acted on this subscribed, otherwise closed, set of observations to report results, and produce after-market aids toward this end. I have benefitted from all of this, and posted elsewhere thus. But the camera system is still a bit stupid, and need not become moreso.

 

And there's the crux: the coded lens method provided a set of constants to improve on the color/light volatility; and once gained(somewhat), now the clamor for an ad-hoc application of this work for short-term results("I cannot be without my lens!")...

 

To trumpet this ad-hoc "the firmware corrections WORKFORME(NOW)" for so subtle a system, a system so young, in the midst of "Wither the M9?" and "Digital Obsolescence Rulez, dude!" is least inspired tune I've heard from this fine band.

 

The "agenda" here is "down with lens codes", not "better quality data from my M8"... maybe it's a "backfocus" thing that this agenda is ignored?

 

rgds,

Dave

Share this post


Link to post
Share on other sites

I don't think anybody here is suggesting that Leica shouldn't first fix the known problems, get the camera to meet its promised specifications with improved file quality (especially in low light & JPGs). However, where there are relatively easy to add features that users have been asking for they should be implemented. I agree with Mark that it isn't a one-man-day job (no software change is) it isn't because of the coding difficulty but rather the time to test to ensure that nothing else gets broken in the process and the time to document the change in user manuals, addendums, etc. How modular and well isolated each module is from the other will determine how difficult this task is. Since they supposedly spent 4 months refactoring the code, I would hope they have carefully studied how to improve the isolation so that going forward gets easier.

Share this post


Link to post
Share on other sites

 

The "agenda" here is "down with lens codes", not "better quality data from my M8"...

 

I don't know what your talking about. It's really very simple. I have 2 coded supported lenses and one lens that is supported but I can not part with it for coding. It would be convenient to be able to select the code. For those who have used Leica codes for unsupported lenses and got good results there is nothing more that needs to be said, it works for them.

 

Cameras and lenses are a pile of compromises decided by engineers and marketing departments. Photographers are forever using the equipment in ways unforseen and unintended because they have to use this stuff in the real world. Each photographer knows best what his or her needs and requirements are.

 

Leica is not a church with it's engineering department a priesthood periodically releasing the latest gospel to the faithful. It's a company committed to providing tools for photographers and it's always a good idea to give the photographer as much control over the tool as possible.

Share this post


Link to post
Share on other sites
for so subtle a system, a system so young,

 

Dude, it's just a camera. 'so subtle a system, a system so young' -you need to get out more:).

Share this post


Link to post
Share on other sites
Well, actually, there's recent evidence--anecdotal on my part from folks I know--that the "ergonomic" chair+foot rest+massage, etc. has lost out to the old draughts-table set up with "task stool" and a lot of standing... yet, there ARE a LOT of cubed enivironments still in use:D. Many coders don't need a mouse(!), so the standing/higher workspace method is not as uncomfortable as it would seem... and yes, I'm sitting(task stool) as I write this. Standing, as with merely stepping away from the screen, is strongly recommended by all but the workspace/cube designers... and a few managers!

 

rgds,

Dave

 

That's interesting. Isn't that hard on the lower back?

 

Cheers,

 

Sean

Share this post


Link to post
Share on other sites
Guest tummydoc

Leica is not a church with it's engineering department a priesthood periodically releasing the latest gospel to the faithful.

 

Blasphemer! Heretic! Buying an M8 is the quintessential example of a faith-based initiative

Share this post


Link to post
Share on other sites
That's interesting. Isn't that hard on the lower back?

 

Cheers,

 

Sean

We're getting far OT, but coders/developers do a lot of sitting... or better, finding support with a "chair"... My friends and I might be of the restless sort, but sitting at the console must be tempered with a healthy re-position of the whole body... it's not ergonomics, but economics: flow of currency, in this case, blood, etc. A good supportive pair of shoes, and frequent shifts of body position, for us, seems to stimulate rather than aggravate conditions of back, and the body whole. It was a "guerilla tactic" to "steal" the cafe-style standing tables from the break room(so who uses these anyway?) and put them in our cubes(for the keyboard(s).

 

My work day involves more on foot than not, and I have found the best back support to come from two things: firm, not "air" nor "foamy" shoes, and a backpack style gear bag, not the single strap sling style. OK, so I don't wear a backpack while coding! Oh, and a good sleep is helpful too:D

 

rgds,

Dave

Share this post


Link to post
Share on other sites
Dude, it's just a camera. 'so subtle a system, a system so young' -you need to get out more:).

I try:D, but my comment was intended to remind folks that within the year's time lens coding has been offered--and that the not a year-old system has been available--the coding system offers a more accurate application of the firmware color corrections than a "user selectable" menu system ever will, the "IR Problem" as recent evidence, publicly(thus, openly) available.

 

That certain persons, however important they may be(and to whomever this importance is ascribed), cannot part with their lens(es) for coding is a "corner case" for justification of less accurate, "user selectable" mis-application of firmware functions.

 

I'd hope that a "petition" for a true "data dump", all of the raw bits in the DNG be advanced before a plea that Leica's firmware coders make their very lens-specific color corrections "available" for mis-application... in so doing, those who have lenses with character "out of scope" for firmware corrections would at least have--although a much larger data file, and not JPEG!--a more reasonable opportunity to make the shot work.

 

Because we have interpreted bits, I say this system is young; and that we could have more data, that's subtle, and underlies the capability of the current M8 to dispell the want of an M9. Oh yes, I am referring to having 16bit DNGs with no "LinearizationTable" metadata as a "user selectable" menu item. And Mark, I agree, this too will require a "man-month" of resources, at least... Control offered to the artist? Depends on your data storage technique:) If the data is available, the post-processing tools will come... or something like that!

 

rgds,

Dave

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue., Read more about our Privacy Policy