Real vs market ISO

waterwingz

12138

Re: Real vs market ISO

« Reply #40 on: 13 / July / 2013, 19:19:46 »

Advertisements

I gave this a try but implemented a little differently to make it cleaner. Tested with ISO override, ISO bracketing in continuous mode and Custom AutoISO mode and seems to be okay.

The only little glitch is that the resulting EXIF's round values to the nearest standard Canon step values. But I think that's the way its always worked.

Added this to camera.h

Code: [Select]

#define CAM_ISO_MARKET_LOW           80
#define CAM_MARKET_TO_ISO_FACTOR_LO  1757  // special case for ISO 80
#define CAM_MARKET_TO_ISO_FACTOR     1645

and this to shooting.c

Code: [Select]

int iso_market_to_real(int isom)
{
  #ifdef CAM_SV96_MARKET_LOW
       if(isom <= CAM_ISO_MARKET_LOW) return isom*1000/CAM_MARKET_TO_ISO_FACTOR_LO; 
  #endif
       return isom*1000/CAM_MARKET_TO_ISO_FACTOR; 
}

The rest of the patch is just to insert iso_market_to_real() in the six place where the UI accepts an ISO value and to delete the market-to-real code from autoiso.c . I think there are several related functions that can be deleted there - I'll go back and clean that up if this patch looks useful.

Update : patch file changed to fix implicit reference to iso_market_to_real() in autoiso.c.

iso5.patch (3.85 kB - downloaded 22 times.)

« Last Edit: 13 / July / 2013, 20:08:42 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14080

Re: Real vs market ISO

« Reply #41 on: 14 / July / 2013, 22:42:05 »

Thanks for doing this. It seems reasonable to me.

I think I'd prefer to keep the camera.h conversions defined in terms APEX96 values, since they end up being an exact add/subtract, and it would be good to be able to cleanly convert between the APEX96 values in the future. This doesn't change logic of your patch at all, it would just mean iso_market_to_real would covert to APEX96 and back.

So I started trying to figure out how to test this in a rigorous way. To get a baseline for ISO overrides, I made script that sets the config values the UI would set, and records the resulting real/market and delta sv values. In the current code, one would expect the resulting "real" ISO to be the same as the requested value.

The input ISO values are hard coded in the script, chosen to give the following expected "real", "market" values, based on the values determined by the previous script
50, 81
60, 100
100, 164
486, 800
800, 1316
972, 1600
3200, 5266 but out of range

Note, this only applies to "modern" cameras.

On my d10, it comes out fairly close. The trunk and release builds give the same values.

Note the script may trigger the FsIoNotify assert due to logging or saving config values too close to image saving.

isotesto.lua (2.62 kB - downloaded 22 times.)

isotesto.ods (11.12 kB - downloaded 21 times.)

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: Real vs market ISO

« Reply #42 on: 14 / July / 2013, 23:59:42 »

Quote from: reyalp on 14 / July / 2013, 22:42:05

I think I'd prefer to keep the camera.h conversions defined in terms APEX96 values, since they end up being an exact add/subtract, and it would be good to be able to cleanly convert between the APEX96 values in the future. This doesn't change logic of your patch at all, it would just mean iso_market_to_real would covert to APEX96 and back.

Its not very often that I find myself arguing software architecture with you (I get enough of that at work so choose to not play that role here) but in this case I think I have to complain.

<rant>
Assuming we want to stick with the desired the minimum changes to existing code, then I would think that the simplest function to convert market ISO to real ISO is needed. Saving the camera.h values as APEX96 means converting each ISOm value to APEX96 and then back to ISOr. This means that a simple integer muldiv function becomes a conversion involving logarithmic functions just to make the constant in the camera.h file more "standard". And the process to discover that standard APEX96 offset is the same as the one to calculate the slope value I used.
</rant>

If you feel its better to work in units of "whale dropping per feet of lead pipe in a commercial boiler" or anything else then I'm okay with that as long as we get to a point where users can enter "market" ISO and have it match what their LCD display and EXIF info tells them.

Update : must have missed a step here - in your spreadsheet the sv96_m and iso_m are locked at 480 & 100 (respectively) ??

« Last Edit: 15 / July / 2013, 00:38:00 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14080

Re: Real vs market ISO

« Reply #43 on: 15 / July / 2013, 00:39:54 »

Quote from: waterwingz on 14 / July / 2013, 23:59:42

Assuming we want to stick with the desired the minimum changes to existing code, then I would think that the simplest function to convert market ISO to real ISO is needed.

If all we ever wanted to do was convert an input market ISO to a real ISO, I would agree completely.

Quote

Saving the camera.h values as APEX96 means converting each ISOm value to APEX96 and then back to ISOr. This means that a simple integer muldiv function becomes a conversion involving logarithmic functions just to make the constant in the camera.h file more "standard".

Not just to make camera.h more "standard".

Since we've gone though the trouble of figuring this out, I want to be able to convert between real / market in either unit, even though the immediate need is just ISO. The APEX conversion can be done exactly (e.g. x = x + 69). The ISO conversion is not exact, whether it takes a round trip through log/pow or not. So I would rather define it in terms of the one where one conversion can be exact.

If this didn't depend on camera specific values, I'd just do it in terms of ISO now, and switch later if needed.

I hope that makes my reasoning clearer, and I really do appreciate the effort you've put into this.

Logged

Don't forget what the H stands for.

reyalp

14080

Re: Real vs market ISO

« Reply #44 on: 15 / July / 2013, 00:45:56 »

Quote from: waterwingz on 14 / July / 2013, 23:59:42

Update : must have missed a step here - in your spreadsheet the sv96_m and iso_m are locked at 480 & 100 (respectively) ??

Because CHDK ISO override operates by using canon auto ISO and fiddling the "delta" that gets added to a fixed base iso. The 100 is the base here. The iso_m +d column gives the market sv + delta converted to ISO, which if I understand correctly should be the actual value used.

Attached updated spreadsheet has output with your patch applied.

Obviously, things change because it is now working in "market" units instead of real, but the values for 60 and 486 in the old system match 100 and 800 in the new system, which is as it should be.

edit:
Regarding the conversion, we can just calculate conversion factors once at startup in shooting_init(). The factor doesn't depend on the specific ISO value, it simplifies to 2^(SV96 offset/96)

edit:
posted script doesn't test ISO 80, which is kind of important. I'll post an update tomorrow.

isotesto.ods (13.95 kB - downloaded 19 times.)

« Last Edit: 15 / July / 2013, 03:01:47 by reyalp »

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: Real vs market ISO

« Reply #45 on: 15 / July / 2013, 09:27:49 »

Quote from: reyalp on 15 / July / 2013, 00:39:54

Since we've gone though the trouble of figuring this out, I want to be able to convert between real / market in either unit, even though the immediate need is just ISO. The APEX conversion can be done exactly (e.g. x = x + 69). The ISO conversion is not exact, whether it takes a round trip through log/pow or not. So I would rather define it in terms of the one where one conversion can be exact. If this didn't depend on camera specific values, I'd just do it in terms of ISO now, and switch later if needed.

I'm fine with that. I was working on the basis of our IRC chat where I think you suggested going for the least invasive change.

Having gone to this much effort instead, we might as well go all the way and change the underlying code so that the UI ISO market value gets changed and used as SV96r directly rather than from ISOm to ISOr and then later to SV96r (or worse from ISOm to SV96m to SV96r to ISOr and only then to SV96r).

One final note - do want to add an ISO_real2market() and ISO_market2real() function to the scripts? Opens a bit of a can of worms - converting between seconds and Tv96 or f-stops and AV96 would be nice at that point too.

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14080

Re: Real vs market ISO

« Reply #46 on: 15 / July / 2013, 16:05:02 »

Quote from: waterwingz on 15 / July / 2013, 09:27:49

I'm fine with that. I was working on the basis of our IRC chat where I think you suggested going for the least invasive change.

Yes, I apologize for the confusion. I do want to do the least invasive changes, but I also want to lay the ground work to fix things more properly in 1.3. Also, I would like to have my cake and eat it too!

Like I said, I would have just gone with your way for 1.2, except then we'd have to re-do the cameras specific defines.

I have implemented the code I described earlier (generating the conversion factor once from the SV96 differences), I'll post a patch this evening after I get a chance to test it.

Quote

Having gone to this much effort instead, we might as well go all the way and change the underlying code so that the UI ISO market value gets changed and used as SV96r directly rather than from ISOm to ISOr and then later to SV96r (or worse from ISOm to SV96m to SV96r to ISOr and only then to SV96r).

My testing shows that the current conversions are not very accurate anyway, so I don't think there is an urgent need to do this for 1.2

Quote

One final note - do want to add an ISO_real2market() and ISO_market2real() function to the scripts? Opens a bit of a can of worms - converting between seconds and Tv96 or f-stops and AV96 would be nice at that point too.

I think all of this should be done in 1.3. For 1.2, I want to just stick to changing the UI input values, though if the script functions turn out to not require deeper changes, they could be backported after release.

Logged

Don't forget what the H stands for.

reyalp

14080

Re: Real vs market ISO

« Reply #47 on: 16 / July / 2013, 00:44:43 »

patch and updated script attached, spreadsheet to follow.

iso-real-work-1.patch (4.87 kB - downloaded 21 times.)

isotesto.lua (2.62 kB - downloaded 22 times.)

Logged

Don't forget what the H stands for.

reyalp

14080

Re: Real vs market ISO

« Reply #48 on: 16 / July / 2013, 01:19:40 »

Spreadsheet
- The top section is the trunk, i.e. overrides working in "real" ISO.
- The "ww patch" section is wateringz iso5.patch from earlier in the thread.
- The "low iso" special case was broken in waterwingz original patch, because the ifdef name changed. the "ww patch + low fix" section of the spreadsheet has this fixed.
- The "reyalp patch" is the patch posted above.

Values of interest are
iso - the input value to to the override
sv96 - the sv96 generated by the override
sv96_me - the effective "market" sv96, from adding sv96_m to delta_sv
iso_r, iso_me - the previous two values converted to ISO. Theoretically, iso_r should match the input values in teh current trunk, and iso_me should match the new code.
sv96_in - the input ISO converted to APEX96

Some observations
- The first section is not directly comparable, but the row containing 486 should give the same results as 800 in the later runs. This is true across the board. The row containing 50 should be close to the value of 80 on the remaining sections, but this is less true.
- In the original code, the resulting values are lower than the input value. For example ISO 100 gives an iso_r of only 92.
- This effect appears to be due to calculations deeper in the override code, so we shouldn't expect it to change with the new code that just takes a "market" value as input and switches it to a "real" value.
- The special case for iso <= 80 makes things worse. This is probably because the override code that generates the final sv96 etc values isn't aware of the special case. Thus the "fixed" patch and my patch give an iso_me of 68, while the unfixed one gives 73.
- This doesn't actually matter much, because the cameras don't go below 80 anyway. If it gets too low, you might get a low value in the exif.
- The ww fix patch and my patch give essentially identical results. They are identical to the unfixed patch above ISO 80

Conclusions:
Too tired to make conclusions. Try again later

isotesto.ods (18.11 kB - downloaded 21 times.)

Logged

Don't forget what the H stands for.

waterwingz

12138

Re: Real vs market ISO

« Reply #49 on: 16 / July / 2013, 09:51:27 »

Quote from: reyalp on 16 / July / 2013, 01:19:40

- The "low iso" special case was broken in waterwingz original patch, because the ifdef name changed.

Doh!

Quote

The ww fix patch and my patch give essentially identical results. They are identical to the unfixed patch above ISO 80

I guess the question, is how accurate do we need to be? I tested that the values on my camera LCD and the camera EXIF matched what I set in the CHDK UI. Even with my bug, they did. Canon appears to round things to the nearest user settable value ( i.e. 80, 100, 200, 400, 800, 1600, 3200 )

Not complaining about your detailed work - if that's not done then we will have the "pixel peepers" complaining about not having three decimal place accuracy.

But from any practical standpoint, can anyone tell an ISO 80 setting from ISO85 ?

Logged

Ported : A1200 SD940 G10 Powershot N G16