IXUS160/ELPH160 Porting attempt - page 7 - DryOS Development - CHDK Forum supplierdeeply

IXUS160/ELPH160 Porting attempt

  • 497 Replies
  • 169985 Views
*

Offline srsa_4c

  • ******
  • 4426
Re: IXUS160/ELPH160 Porting attempt
« Reply #60 on: 31 / May / 2015, 15:30:19 »
Advertisements
0.2.3 branch does not have calibration features, only the 0.2.2 has
I've never checked whether this feature was actually removed or just disabled. The 0.2.2 Windows release offers no camera customisation features (it only knows some cameras in the 5 .. 10 Mpixel range), so you are out of luck unless you hack on the source...

BTW, the reason for my reply was that the location of the raw hook will have no impact on the raw data size, only on its content.

May I ask what kind of raw do you get when using either the capt_seq or the dvlpseq raw hook (is it clean or corrupted)? Can you upload a sample?

Unfortunately the camera logs show it's not quite the same as sx170, as the dvlp task does not get hit with the correct args.
Yeah, they seem to have changed how things work...
Quote
(capt indexes are a little bit different, in ixus160 what is called capt 4 is capt 3 in sx170 and capt3 was not in sx170, sorry about that)
Can you show the patched source (for clarity, I have several versions of those patches laying around)?
Quote
We can also see that the capt 2 call is actually earlier than the dvlp call, so no point if I understood right to put it in dvlpseqtask.
When the hook is placed in dvlpseq, it might be possible to catch raw in cases when the original capt_seq location is not usable (example: auto mode, low light mode - though the latter is not supported by the current source).
You could check this one day, but it isn't priority at the moment.

*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #61 on: 31 / May / 2015, 16:25:56 »
Updated the github repo.

Here is a raw + jpg taken with the latest changes.

https://www.dropbox.com/s/wlcttaq1so9q3z6/ixus160_raw_test.rar?dl=0

Edit: you may notice there is something completely inconsistent with the logs I posted (getmachinetime is totally missing).

At first I didn't correctly use the biglog.lua script, so there was nothing, so I removed the first arg, but forgot to run make clean before rebuilding, making this wierd soup of new defines but old style logging (I didn't have much time to test this week). I believe it did not take the new version of the logging functions at all, so don't pay too much attention to the format.
« Last Edit: 31 / May / 2015, 16:29:54 by adong »

*

Offline srsa_4c

  • ******
  • 4426
Re: IXUS160/ELPH160 Porting attempt
« Reply #62 on: 31 / May / 2015, 17:08:10 »
Updated the github repo.

Here is a raw + jpg taken with the latest changes.

https://www.dropbox.com/s/wlcttaq1so9q3z6/ixus160_raw_test.rar?dl=0
Thanks. I did not yet make a dng4ps-2 profile for the raw, so I don't know how it looks. I did notice however that the file size is not what's expected. Reason: the default bitdepth for RAW is 10bits, your 'from scratch' platform_camera.h doesn't redefine CAM_SENSOR_BITS_PER_PIXEL.
Things might be easier if you start with another port's platform_camera.h (the closest the better), and comment/uncomment/change its entries, keeping its format. I suspect that some RAW/DNG related define is also missing, causing the previously discussed DNG problem.

If the logging functions' location corresponds to the source, that's good enough.
If you plan on using this logging method note, that some buffer can't hold the desired number of entries and you may experience 'datalost' messages if there's too many entries in the log. ('Some buffer' means either the Canon log buffer or the UART redirector's buffer (if any) or something else...)

*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #63 on: 31 / May / 2015, 17:14:03 »
Ok will try to do that next week.
By any chance, do you have a raw img tester? I have both win and nix so either is fine. That way I'll know when my raw is correct.


*

Offline srsa_4c

  • ******
  • 4426
Re: IXUS160/ELPH160 Porting attempt
« Reply #64 on: 31 / May / 2015, 17:28:34 »
By any chance, do you have a raw img tester?
Not sure I understand. If you'd like to convert RAWs to DNG (which can be opened by many applications), set up a camera profile in DNG4PS-2:
Settings -> Camera options -> (choose a camera from the list) -> "Copy..." -> "Yes" -> adjust the fields below -> close the window with "OK"
and then
Settings -> Camera types -> 5248x3920 (may not be visible in the official version(?)) -> IXUS 160 -> "OK"
If these are done and the RAW file size is correct, RAWs will show up in the main window if you browse to a folder with your RAW files.

You only need to use DNG4PS-2 until you figure out all parameters for a correct in-camera DNG.

edit:
Attached a screenshot, mosaic type may not be correct, you need to work out the rest (color matrix). The program will expect files with 5248*3920*(12/8) bytes size.

edit2:
if 5248*3920 is not showing up on the "Camera types" page, try my hacked version (or perhaps try compiling the latest official source, maybe they fixed this UI limitation).

edit3:
... and yes, the RAW data is corrupted, see attachment
« Last Edit: 31 / May / 2015, 17:50:46 by srsa_4c »

*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #65 on: 01 / June / 2015, 15:21:37 »
Can't seem to make it work, the UI isn't translated (like buttonOption etc) and it doesn't detectg raw files.

*

Offline srsa_4c

  • ******
  • 4426
Re: IXUS160/ELPH160 Porting attempt
« Reply #66 on: 01 / June / 2015, 15:34:24 »
Can't seem to make it work, the UI isn't translated (like buttonOption etc) and it doesn't detectg raw files.
If you're using 0.2.3:
Settings: second button from left at the bottom of main window
UI language: first dropdown box from the bottom of the settings window
You also need the language file(s), for example English: langs/en/dng4ps-2.mo in the program's directory

The raw files must have the exact size (width*height*bitdepth/8) to be detected, and you also need to do this:
Quote
Settings -> Camera types -> 5248x3920 (may not be visible in the official version(?)) -> IXUS 160 -> "OK"

*

Offline adong

  • **
  • 66
Re: IXUS160/ELPH160 Porting attempt
« Reply #67 on: 01 / June / 2015, 16:07:52 »
Got it, thanks. Will retry a build with 12 bit depth later this week.

Edit:

Got it to semi-work with 10bit pic (can't calibrate, gives too big percentages, don't know how you got these matrices :p)

12 bit is no go, says no camera profile even if the CRW + JPG are listed and camera prof is selected in options.
However in the calibrate window (now that I know where it is), I can see the raw is still corrupted, verified for the dvlptask hook AND old hook (before
"    B       loc_FF99AA50 \n"
and just after
"loc_FF99AA50:\n" )
« Last Edit: 03 / June / 2015, 16:06:11 by adong »


*

Offline srsa_4c

  • ******
  • 4426
Re: IXUS160/ELPH160 Porting attempt
« Reply #68 on: 03 / June / 2015, 19:19:25 »
12 bit is no go, says no camera profile even if the CRW + JPG are listed and camera prof is selected in options.
Did you fix the platform_camera.h values and re-shot a bunch of CRWs, or you're just using some old files? I got it to work by appending the appropriate number of zero bytes to the end of your short CRW.
Quote
However in the calibrate window (now that I know where it is), I can see the raw is still corrupted, verified for the dvlptask hook AND old hook (before
"    B       loc_FF99AA50 \n"
and just after
"loc_FF99AA50:\n" )
This is a problem then that needs some research... I'll try to do a comparison with an older firmware.
You could also help by inserting debug calls backwards from your current capt_seq raw hook and gather debug data by doing long (1 sec) exposures. This could help locating parts of the fw code which are pre- and post-exposure.

BTW, you may want to make separate posts for your progress, updating a one-liner after several days will hardly attract audience.

*

Offline srsa_4c

  • ******
  • 4426
Re: IXUS160/ELPH160 Porting attempt
« Reply #69 on: 04 / June / 2015, 14:17:59 »
I've done a bit of exploration. It appears that parts of the capt_seq fw code have been rewritten (asserts indicate a different source file edit: I was looking at the wrong place). I think that JPEG compression is now set up in capt_seq rather than in dvlpseq.
I'd like to know whether one of the following locations ("HERE") is reliably entered after a shot:
Code: [Select]
"loc_FF99AA14:\n"
"    LDR     R0, [R7, #0xAC] \n"
"    CMP     R0, #0 \n"
"    MOV     R0, R5 \n"
"    BEQ     loc_FF99AA2C \n"
"    BL      sub_FFAD80B0 \n"
/* HERE */
"    B       loc_FF99AA50 \n"

"loc_FF99AA2C:\n"
"    BL      sub_FFAD7C94_my \n"  // --> Patched. Old value = 0xFFAD7C94.
/* HERE */
"    B       loc_FF99AA50 \n"
If yes, the appropriate place for the raw hook(s) will be in sub_FFAD80B0 and/or sub_FFAD7C94 somewhere. Or, on a yet deeper level...
« Last Edit: 04 / June / 2015, 19:15:25 by srsa_4c »

 

Related Topics