Messages

5D uses these dark offset table properties:

Code Select Expand


uint32_t dark_prop_ids[] = {
0x0101004D,
0x0101004E,
0x0101004F,
0x01010050,
0x01010051,
0x01010052,
0x01010053,
0x01010054,
0x01010055,
0x01010056,
0x01010057,
0x01010058,
0x01010059,
0x0101005A,
0x0101005B,
0x0101005C,
0x0101005D,
0x0101005E,
0x0101005F,
0x01010060,
0x01010061,
0x01010062,
0x0101007B,
0x0101007C }


in 5D3 code this setup is used to determine the property.
the raw iso value (0x40-0x99) is used as index to this table:

Code Select Expand


uint32_t dark_prop_ids_by_iso[89] = {
0x101004D,
0x101004D,
0x101004D,
0x101004D,
0x101004D,
0x101004D,
0x101004D,
0x101004D,
0x101004D,
0x101004D,
0x101004D,
0x101004E,
0x101004E,
0x101004F,
0x101004F,
0x101004F,
0x1010050,
0x1010050,
0x1010050,
0x1010051,
0x1010051,
0x1010052,
0x1010052,
0x1010052,
0x1010053,
0x1010053,
0x1010053,
0x1010054,
0x1010054,
0x1010055,
0x1010055,
0x1010055,
0x1010056,
0x1010056,
0x1010056,
0x1010057,
0x1010057,
0x1010058,
0x1010058,
0x1010058,
0x1010059,
0x1010059,
0x1010059,
0x101005A,
0x101005A,
0x101005B,
0x101005B,
0x101005B,
0x101005C,
0x101005C,
0x101005C,
0x101005D,
0x101005D,
0x101005E,
0x101005E,
0x101005E,
0x101005F,
0x101005F,
0x101005F,
0x1010060,
0x1010060,
0x1010061,
0x1010061,
0x1010061,
0x1010062,
0x1010062,
0x1010062,
0x101007B,
0x101007B,
0x101007C,
0x101007C,
0x101007C,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062,
0x1010062 }


7D uses only 73 entries for this table.

[exactly what you are doing anyway]

maybe i wasn't specific enough.
using
int PROPAD_GetPropertyData(unsigned int property, void **data, int *length)
you can read the memory address of the properties i wrote.
no need for searching, you just need PROPAD_GetPropertyData to retrieve the RAM addresses you just searched for.

some example (untested)

Code Select Expand


int (*PROPAD_GetPropertyData) (unsigned int property, void **data, int *length) = 0xFF06934C; // 7D.203, see stubs.h where they are defined
unsigned int *table = NULL;
unsigned int table_length = 0;

PROPAD_GetPropertyData(0x0101004D, &table, &length);
if(length != SENSOR_FULL_WIDTH*4)
{
    return;
}

// table should now have the RAM address you tried to find manually
table[0] = value; // patch table entry 0



advantage of above code:
- you are doing it correct (as most likely SPT tool does)
- doesnt matter when RAM addresses change (they are not guaranteed to stay the same, may even vary between boots!)
- you do not have to find RAM addresses for all models, just using the property function for that

disadvantage:
- the PROPAD_ functions are commented out for safety reasons as it is not good to mess with property data in RAM. which is exactly what you are doing anyway. so you went down that rabbit hole already
- i didnt test this code

advantage/disadvantage:
- need to map property ID <-> ISO which is a good thing to document!

Several lines:

which table did you modify for these horizontal lines?

The module requires code cleanup and some work, currently it is only a tool that is not good for official publication.

i would head towards reading and writing the properties if i were you.
this makes the code more robust and then would be an equivalent to the SPT tool.
but that requires thorough testing of course.

We can also use something like two_add engine to speed up the processing. But is it necessary?

nah, if you update properties you wont run it every day.

Current limitation - I can change the black level of the column by 1. So some of the columns still have 1024.5 or 1023.5.

as the offsets are integer, odd numbers aren't possible. at least in-camera
would have to use float-files which are a bit overkill.

[edmac_0x18_address_HivShd]

on 5D3 the properties with size 0x5E0 are being read by function "GetHivshdIRparameter(Po=%ld[%ld])"
it is later written to HIV by first writing this engio list: (0xBC * 8 = 0x5E0)

and then copied there:


and the 0x5CC0 sized ones are used for
stru_45294.edmac_0x18_address_HivShd = get_dark_offset(param_iso, v4);

[TUNE]

doing a quick analysis on 5D3.113, it is the TUNE property table, starting at 0xF8B20000

you can dump it like that:
    PropertyEditor.exe 0xF8000000-0xF8FFFFFF.BIN 0xB20000 0x2E0000

and it will spit out a property dump like this:



where you can see that this memory location is for properties 0x0101004D-0x0101007C with 5936 uint32 values.
before them there are properties 0x0101007E-0x0101008F with 376 uint32 values also looking like a offset table.

getting their value is as simple as reading a property. no need for memory locations.
modifying them, well, i would stick to patching it in-memory

good find!

would really be interesting if this is the FPN compensation table we could simply pass to MLV files.
(well not simply, a dark frame must be calculated from these values)

1) so you found the location where the vertical ADC offset tables for FPN correction are?
2) these probably were calibrated in factory and written into the flash only once?
3) you updated values in RAM to achieve better FPN reduction - for CR2? or did it even affect raw video?

would be interesting to use these tables into a MLV and creating the DARK frame from it

a 83 minute movie shot with ml raw?

OK then, here's my wish list.

Dear Santa,

...give me three clones of myself.
one for taking care of my family.
one for doing my main work.
another one for working on ML again.

so i can finally relax and enjoy life

short: he cant keep up maintaining the german translation of the ML manual.
the site is still up, but wont be updated.
finally some people said thanks for his effort.

vielen dank für die arbeit die du da reingesteckt hast!

or use inkscape. works like a charm.

a) your .idx is defect - delete the .idx file before running mlv_dump
b) your mlv_dump is very old - get a recent version of mlv_dump

should look better then

Thanks!

@g3gg0 - No, that build doesn't work with this file:

Code Select Expand

./mlv_dump.osx -F 3 --dng M15-0904.MLV
FIX BUG #3 [active]

MLV Dumper
-----------------

Mode of operation:
   - Input MLV file: 'M15-0904.MLV'
   - Decompressing before writing DNG
   - Enforcing 14bpp for DNG output
   - Using output path 'M15-0904_' for DNGs
   - Convert to DNG frames
   - Output into 'M15-0904_'
File M15-0904.MLV opened
File M15-0904.M00 not existing.
Processing...


Vertical stripes correction:
  1.00000  1.00290  0.99698  1.00259  0.99626  1.00102  0.99782  0.99646
Cold pixels : 0                             
Unknown Block: %%, skipping
[ERROR] Invalid block size at position 0x7dd46afe
Processed 777 video frames at 24.00 FPS (32.38 s)
Done


https://builds.magiclantern.fm/jenkins/view/Experiments/job/crop_rec_4k/36/

does this version work?

from: https://www.magiclantern.fm/forum/index.php?topic=19761.msg186010#msg186010
"you can specify a bugfix option "-F 3" to fix that issue"

first of all - you never installed ML onto your camera or replaced your firmware.
ML only enables a "boot from card" flag in the camera and enables a "boot flag" on the card where ML binaries are installed.
your camera's flash doesnt contain any code from ML.

did you use a new card?
can you make a video?

In mlv 2.0 specifications, lens name is a optional null terminated string, so maybe option number 2 is to be preferred to avoid interference with other processing tools?

absolutely. this is my recommendation.
in MLV strings dont *have to* be null terminated as you pointed out correctly.

cool video, i like the whole composition

Than I export to uncompressed avi, which is 8 Bit. That´s what I stack with autostakkert.

any reason why to switch to 8 bits alreary there? i directly used TIFF files to keep most information for autostakkert

Nice!
Could you share you camerasettings, please? I had the best results with ISO6400 F 1/5.6 2s on my 6D with 300mm-lens (CR2). Video was not possible.

1. MLV, 1920x1080, ISO200, 1/33, Maksutov MTO-11CA
2. mlvfs -> lightroom -> TIF (without editing)
3. ~4200 frames into autostakkert 3.0.14 to stack 60% of the images
4. used fitswork to apply a handcrafted deconvolution filter
5. applied some gamma correction

my first real try of this toolchain.

the total lunar eclipse was close to impossible to shoot properly.
had to use FPS override to 500ms exposure time to see a faint image of the moon with ISO3200.
then shot a MLV with 1000ms exposure time, but with the moon being imaged only partially (crop_rec)
but autostakkert has trouble detecting the motion properly

didnt have much luck either.
could see the moon the last 30 minutes, but with my gear it was all too dark to capture properly.

here a 2500-image merge of the moon right after it left the umbra

ive just seen that there is some again fixed-length implementaition in manual_lens_info_64byte branch and manual_lens_info.

is there any tool yet that processes the ELNS block?
i still want the name to be dynamic - just like some other blocks are.

this is so impressive. wow. then i might try my cassegrain and see what i can get with it.
any idea/estimation if the MTO-11CA (russentonne) is capable of getting something useful?
or is its 1000mm focal length lost hope and i do better saving the time?

holy crap. this singe MLV and the resulting picture right next to it blew my mind.
didnt expect that someone could recover so much detail from such single frames...

how do you compensate the atmospheric turbulences?
when i look through my maksutov mto-11ca i quickly tend to forget all ideas about shooting photos of planets.