supplierdeeply

DNG meta data determining RAW converter crop behavior often of mediocre quality

  • 31 Replies
  • 5884 Views
*

Offline koshy

  • *****
  • 799
Advertisements
If you override the aperture then the same aperture is used for both shots (assuming the override is within the aperture range for the zoom level).
In a camera without an iris?! ... and in areas of the sensor that are shielded from any light that comes through the lens.

*

Offline philmoz

  • *****
  • 3070
    • Photos
If you override the aperture then the same aperture is used for both shots (assuming the override is within the aperture range for the zoom level).
In a camera without an iris?! ... and in areas of the sensor that are shielded from any light that comes through the lens.


Camera without iris was what I was missing - but to be fair you did not mention this in the post I quoted and you claimed to be overriding the aperture.


I still don't think there is anything unexplained happening, just Canon changing the ISO used VS reported in the image.


If you are seeing different brightness in the masked areas then this would be consistent with the ISO changing despite the override.


Phil.

CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)

*

Offline koshy

  • *****
  • 799
Camera without iris was what I was missing - but to be fair you did not mention this in the post I quoted and you claimed to be overriding the aperture.
Did I?  "- take a cam and override Exposure time, ISO and ND-Filter/Aperture" meant override any you can. Either aperture wide open or ND out.


It does not matter though. I tried to revisit this today and heck, I trusted a hack.

On the SD 850 sometimes the overrides really get applied sometimes not. In my tests in 2014 they clearly weren't. So, this is an ancient bug. For the fun part: The overridden parameters always make it into the meta data. So I trusted CHDK to have used what it wrote into the meta data even of the JPEG and all that got me.

For the bug it seems relevant how long shutter half-press is used. Long => overrides really make it. Shorter => overrides fail but still get written to meta data.

Here are two JPEG /DNGS files one where an override succeeded ane where it failed.https://nofile.io/f/0Od6mBJhC4w/SD850.7z

PS: What happened to the forum it eats my white space upon "preview" and when I try editing my old posts with lots of color formats those explode, too.

*

Offline reyalp

  • ******
  • 11583
For the bug it seems relevant how long shutter half-press is used. Long => overrides really make it. Shorter => overrides fail but still get written to meta data.
Never trust the exif  ;)

Overrides not being applied on quick press (shooting without waiting for the camera to be ready) is a pretty common bug. ixus950_sd850 does not appear to have the usual workaround for this. Test build attached.

Note I initially thought you were talking about ixus850_sd800, which *also* appears to not have the workaround. If you have that one, it might be worth testing too.

Quote
PS: What happened to the forum it eats my white space upon "preview" and when I try editing my old posts with lots of color formats those explode, too.
FWIW, you can turn the WYSIWYG editor turned off in your profile under look and layout.
Don't forget what the H stands for.


*

Offline koshy

  • *****
  • 799
FWIW, you can turn the WYSIWYG editor turned off in your profile under look and layout.
Thank you! That was what I hoped for. What I saw clearly wasn't what I was getting with "WYSIWYG"  :lol

*

Offline koshy

  • *****
  • 799
Overrides not being applied on quick press (shooting without waiting for the camera to be ready) is a pretty common bug. ixus950_sd850 does not appear to have the usual workaround for this. Test build attached.
Thanks. I'll test that.

Quote
Note I initially thought you were talking about ixus850_sd800, which *also* appears to not have the workaround. If you have that one, it might be worth testing too.
I checked and I think I still have all Powershot SD cameras supported by CHDK. I can test with any eventually.

*

Offline koshy

  • *****
  • 799
I checked and I think I still have all Powershot SD cameras supported by CHDK. I can test with any eventually.
I made and posted a list of all the cams I did not part from and their FW versions at: https://chdk.setepontos.com/index.php?topic=13445.0

*

Offline koshy

  • *****
  • 799
ixus950_sd850 does not appear to have the usual workaround for this. Test build attached.
Very good, that worked in fixing it. SD850 can be checked in.
What would be the easiest way to see what other cameras are affected? Testing the behaviour or looking at the code? Care to extend the fix to others? Seems worthwhile...


*

Offline reyalp

  • ******
  • 11583
Very good, that worked in fixing it. SD850 can be checked in.
Thanks. Checked in for 1.5 and 1.4
Quote
What would be the easiest way to see what other cameras are affected? Testing the behaviour or looking at the code? Care to extend the fix to others? Seems worthwhile...
You can whether the workaround is present by looking in the source capt_seq.c around shooting_expo_param_override. You can see this in the change for sd850:
https://app.assembla.com/spaces/chdk/subversion/commits/5028

Note some ports have a simpler version of the workaround that doesn't call captseq_hack_override_active, like (from sx1)
Code: [Select]
//  this code added to avoid some incorrect behavior if overrides are used.
 //  but it can cause some unexpected side effects. In this case, remove this code!

            "MOV     R0, #0\n"
            "STR     R0, [R4,#0x24]\n"  // fixes overrides  behavior at short shutter press
 
 //  end of my code

The normal code that the workaround affects is the immediately following
Code: [Select]
                 "LDR     R0, [R4,#0x24]\n"
                 "CMP     R0, #0\n"
                 "BEQ     loc_FF86CEF4\n"
(registers, offsets and addresses vary by camera)

Not all cameras appear to need the workaround. Some ports have a note to this effect in the relevant part of the code.

So if you wanted to go through your cameras and check, I'd suggest looking at capt_seq.c, and testing if there is no comment or workaround.
Don't forget what the H stands for.

*

Offline koshy

  • *****
  • 799
So if you wanted to go through your cameras and check, I'd suggest looking at capt_seq.c, and testing if there is no comment or workaround.
Ok, started to look into that. One question: Files that are
Code: [Select]
capt_seq.c - auto-generated by CHDK code_gen. do not have much in the sense of comments, is it safe to assume that they have this fixed? To name one I looked at ixus95_sd1200 100b and found items that look like what you pointed out as the "normal code" starting at lines 76 and 81 - does that have it fixed?

At the end of the day I will just try with the cameras in question but including the codegen generated sources I still have 69 models where I found no comment on fixing overrides. Hoped to narrow that down more if possible.
« Last Edit: 04 / June / 2018, 18:33:10 by koshy »

 

Related Topics