EOS M3 porting - page 15 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20 ... 70   Go Down

EOS M3 porting

  • 696 Replies
  • 300914 Views
*

Offline reyalp

  • ******
  • 13443
Re: EOS M3 porting
« Reply #140 on: 11 / September / 2016, 14:46:30 »
Advertisements
Quote from: Ant on 11 / September / 2016, 14:29:54
CR2 files contain sensor width that does not match with buffer width
It should be very obvious in CHDK DNG whether the width is correct or not, no need to care what Canon puts in their exif. Most CHDK ports don't have a canon exif to work from.

It might be interesting to figure out why they differ (is the data in the CRW actually cropped to the size given in the exif, does adding some of the mask or border values end up with the right value?) but it should have no impact on CHDK.

It's also possible there is some other exif tag that has the true width. On g7x, exiftool gives me
Quote
Sensor Width   5632
Sensor Height   3710
Which is the correct size. There is also the following
Quote
Sensor Left Border   132
Sensor Top Border   40
Sensor Right Border   5603
Sensor Bottom Border   3687
Black Mask Left Border   0
Black Mask Top Border   0
Black Mask Right Border   0
Black Mask Bottom Border   0
Logged
Don't forget what the H stands for.
*

Offline Ant

  • ****
  • 491
Re: EOS M3 porting
« Reply #141 on: 11 / September / 2016, 15:09:06 »
Quote from: reyalp on 11 / September / 2016, 14:46:30
is the data in the CRW actually cropped to the size given in the exif, does adding some of the mask or border values end up with the right value?

Data in CR2 match the sensor dimensions from CR2 header. And it's cropped to the buffer size, that I use in CHDK DNG.
Logged
*

Offline reyalp

  • ******
  • 13443
Re: EOS M3 porting
« Reply #142 on: 11 / September / 2016, 15:22:33 »
Quote from: Ant on 11 / September / 2016, 15:09:06
Data in CR2 match the sensor dimensions from CR2 header. And it's cropped to the buffer size, that I use in CHDK DNG.
I don't understand. You said the CR2 dimension is smaller than the real buffer width? No matter what, CHDK must use the real buffer size, which should be obvious looking at the actual raw buffer data.

And when you say "data", you mean you extracted and decompressed the raw data from the CR2, or are you relying on some image processing application?

Logged
Don't forget what the H stands for.
*

Offline Ant

  • ****
  • 491
Re: EOS M3 porting
« Reply #143 on: 11 / September / 2016, 15:50:01 »
Quote
You said the CR2 dimension is smaller than the real buffer width?
Yes.

Quote
or are you relying on some image processing application?
yes and some programs show decoded CR2 with black borders
Logged
*

Offline 62ndidiot

  • *****
  • 591
Re: EOS M3 porting
« Reply #144 on: 11 / September / 2016, 16:01:25 »
So you must use the real sensor width and height which will be larger than the JPEG dimensions and the cr2 dimensions to set buffer sizes.  Otherwise corrupt dng. 
Logged
*

Offline Ant

  • ****
  • 491
Re: EOS M3 porting
« Reply #145 on: 11 / September / 2016, 16:31:36 »
Quote from: 62ndidiot on 11 / September / 2016, 16:01:25
So you must use the real sensor width and height which will be larger than the JPEG dimensions and the cr2 dimensions to set buffer sizes.  Otherwise corrupt dng. 
I now it and I use it in DNG. But it's interesting to understand why canon put cropped buffer to CR2 files and what are real sensor dimensions.
Logged
*

Offline Ant

  • ****
  • 491
Re: EOS M3 porting
« Reply #146 on: 12 / September / 2016, 15:26:18 »
new pre-alpha CHDK for EOS M3:
CHDK core updated to r4682;
ptp liveview now works with latest CHDKPTP;
edge overlay implemented, but works slowly;
motion detection tested at various image aspect ratios;
DNG raw shooting works in PTAM modes.

Only SD Card boot method works at the moment.
« Last Edit: 12 / September / 2016, 15:29:20 by Ant »
Logged
*

Offline Ant

  • ****
  • 491
Re: EOS M3 porting
« Reply #147 on: 15 / September / 2016, 13:52:07 »
I'm trying to implement get_focal_length function:
Code: [Select]
// 0xFC43DF1C             EFLensCom.GetFocalLength
int __attribute__((naked,noinline)) EFLensComGetFocalLength () {
    asm volatile (
" movs r0, #0\n"
" push {r4, lr}\n"
" bl sub_fc43cd91\n"
" mov r4, r0\n"
" ldr r0, [r0, #36]\n"
" movs r1, #160\n"
" strb r1, [r0, #0]\n"
" movs r1, #0\n"
" ldr r0, [r4, #36]\n"
" strb r1, [r0, #1]\n"
" ldr r0, [r4, #36]\n"
" strb r1, [r0, #2]\n"
" movs r1, #3\n"
" ldr r0, [r4, #32]\n"
" str r1, [r0, #0]\n"
" mov r0, r4\n"
" bl sub_fc2f2c0f\n"
" ldr r0, [r4, #40]\n"
" ldrb r1, [r0, #1]\n"
" ldrb r0, [r0, #2]\n"
" add.w r0, r0, r1, lsl #8\n"
" uxth r1, r0\n"
" ldr r0, =0xfc43e274\n"
" bl sub_fc37fd9d\n"
" mov r0, r4\n"
" bl sub_fc43cdf5\n"
//" movs r0, #0\n"
" mov r0, r1\n"   // focal length
" pop {r4, pc}\n"
".ltorg\n"
);
}But when I call it, camera crashes with various causes.
When I call original function (0xFC43DF1C) using ptpcam - everything is ok.
Logged
*

Offline 62ndidiot

  • *****
  • 591
Re: EOS M3 porting
« Reply #148 on: 15 / September / 2016, 15:10:46 »
capdis doesn't like the address 0xFC43DF1C , so trying 0xfc43df1d reproduces your code. I think you might try 0xfc43df1f (e) which essentially eliminates the movs instruction, so you start with push.
Logged
*

Offline Ant

  • ****
  • 491
Re: EOS M3 porting
« Reply #149 on: 15 / September / 2016, 15:33:03 »
Of course, I use the address 0xfc43df1d.
But this function does not return focal length. It prints value as a string to somewhere like EventShell buffer(0x00051520).

UPD. The mistake was found in the first call. There should be "bl   sub_fc43cd97\n"
« Last Edit: 16 / September / 2016, 08:58:57 by Ant »
Logged
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20 ... 70   Go Up
« previous next »
 

Related Topics