Switch for macOS Catalina/Linux (former cr2hdr.app)

[festr]

Hi, I'm trying to process dual_iso with lossless compressino enabled (lj92) - first few frames are normal but then a lot of greenish frames until the end. Is this known issue?

(even if I disable lossless compression after few frames the rest are greenish)

[motionSOUL]

I have tried to open it in Automator and step by step execute the tasks, all is going well until the last script which is understood but the cr2hdr window doesn't open.

[Danne]

Sorry, cannot help you here. If you get all scripts to work from inside automator it should probably work. MAybe if you copy all scripts and files into a vanilla build of an automator app it might work but there are other thkngs which might be troublesome here. HArd to say.

festr. Are regular dual iso files also problematic? Not compressed ones? Could you upload a short sample?

[festr]

Edit: I have tried to turn off ls92 compression in MLV menu (the same result) so its not compression issue


This is first frame:




this is second frame (bad) and all others are bad

[Danne]

Upload a short file that exhibits the issue. I can take look.

[festr]

Here it is: https://drive.google.com/open?id=0B650ZX3ln336QzlvVWhTanRiY2M

let me know how it decodes on yours machine

[Danne]

Thanks for the clip. It´s my version of mlv_dump. It seems to go bananas with your file. You can still use regular cr2hd.app and it will work.

[togg]

Small suggestions, option 05 and 07 are a little bit strange to read. Are they active when selected or not? Could be improved to be less confusing.

[Danne]

It´s from the mlv_dump menu. But yes, things can always be clearer

[festr]

cr2hd.app - but will it work with the compressed lj92 feature?

[Danne]

The issue is related to vertical stripes correction. Since I divide mlv_dump processing into 4 chunks working in parallell it seems only the first chunk using vertical stripes correction is producing nice output. This bug appears on latest lj92 version crop4k branch as well.
If I run processing in one chunk all looks ok but it seems to change vertical stripes algorithm for every new chunk when processing in parallell.
The fix is to disable vertical stripes correction with dualiso files. Can be done in mlv_dump menu (m)

Code Select Expand

Vertical stripes correction:
  1.00000  1.00084  1.00200  0.98271  0.99992  1.00200  1.00189  1.01596

Frame0 : cold pixels found: 0                             


Vertical stripes correction:
  1.00000  1.99995  1.00266  1.99995  0.99980  1.99995  1.00221  1.99995

Frame0 : cold pixels found: 0                             


Vertical stripes correction:
  1.00000  1.99995  1.00204  1.99995  1.00047  1.99995  1.00127  1.99995

Frame0 : cold pixels found: 0                             


Vertical stripes correction:
  1.00000  1.99995  1.00270  1.99995  1.00055  1.99995  1.00276  1.99995

[festr]

Hi Dane, yes without stripes correction there is no problem - but there are vertical stripes now which I need to correct. Do you know how to fix it?

[Danne]

Could you upload a dng with stripes?
On a sidenote this issue could be of something related to mlv_dump function -f which works with frame exports. Since files ranging from 0 and forward seems play nicely a -f 100-200 does not. Question is how non dualiso files are affected or not.

[Danne]

Uploaded a new cr2hdr_lj92.dmg version. Download in first post.

Reason is I think I found the bug with vertical stripes correction when using the -f function in mlv_dump. This one only occurs when exporting let´s say mlv_dump -f 10-20 --dng. If outputting frames somewhere in the middle of the mlv file vertical stripes correction numbers seems way off as opposed to processing mlv_dump --dng or mlv_dump -f 0-100 --dng.

After the fix I got much more coherent numbers. Please check older numbers a few posts before.

Code Select Expand

Vertical stripes correction:
  1.00000  1.25429  1.12299  1.33395  1.12294  1.14198  1.08633  1.20380

Frame0 : cold pixels found: 0                             


Vertical stripes correction:
  1.00000  1.25465  1.13469  1.31161  1.11452  1.17938  1.09082  1.12737

Frame0 : cold pixels found: 0                             


Vertical stripes correction:
  1.00000  1.25990  1.13376  1.31618  1.12531  1.18373  1.07240  1.12363

Frame0 : cold pixels found: 0                             


Vertical stripes correction:
  1.00000  1.25998  1.12959  1.31648  1.12939  1.18280  1.10335  1.12971
Reached end of chunk 1/1 after 232 blocks
Processed 223 video frames
Done

Commit here.(Needs to be tested)
https://bitbucket.org/Dannephoto/magic-lantern/commits/be8d3a22ce28ec8c18bc07b43c1045204dc03d83

In short vertical stripes correction is called after  /* finally save the DNG */ as opposed to before.

Code Select Expand

                           /* finally save the DNG */

                            if(!dng_save(frame_filename, frame_buffer, &dng_info))
                            {
                                print_msg(MSG_ERROR, "VIDF: Failed writing into .DNG file\n");
                                goto abort;
                            }

                            /* call raw2dng code, moved here because otherwise numbers are off for compressed raw */
                            if (fix_vert_stripes)
                            {
                                fix_vertical_stripes();
                            }

[festr]

I have tried the latest cr2hrd_lj92.dmg but it does not remove vertical strips now (I have checked that I did not disabled it)

[Danne]

Well, you need to upload example dng files. Dual iso files in general doesn´t work as regular footage. Not even sure that dual iso files are supposed to apply vertical correction to them. Upload dng samples that shows your problem.

[festr]

It is the same MLV file I have uploaded to dropbox. Here is the new DNG which exhibits vertical stripes:



and here is for comparison previous version which removed vertical stripes (but it broken all other images)

[Danne]

I want the dng files.

[festr]

I have uploaded few DNGs here https://drive.google.com/open?id=0B650ZX3ln336MWJ1VDZISGNxTkk

the postimg.org changed resolution, here is the same picture where stripes are clearly visible:

[Danne]

Specify two dng files. One with stripes, the other one without stripes. For comparisons.

[festr]

I have reverted to previous cr2hdr which has the green problem - first of two images are without vertical stripes - I have uploaded it to the same link under directory WithoutStripes
(please note that I'm using still the same .MLV which is also uploaded there

https://drive.google.com/open?id=0B650ZX3ln336MWJ1VDZISGNxTkk

[Danne]

Compared with g3gg0 latest code and there is a problem with my so called fix. Will have to tinker some more...
Thanks for sharing information on this. It´s only related to -f function, otherwise it works.
By the way. Is it happening on all your dualiso files or only this one?

[festr]

I can try more footage but I'm convinced it will do for all. I was actually not using dualiso because of very long postprocess but this application with parallelisation and automation rocks so I wanted to use it

what is exactly -f and how I can remove it as a workaround? 

[Danne]

Try a few more files. It seems to work for non dualiso files. I suspect it could be the file. If not I upload a version which skips processing in parallell. I uploaded the old version again.

[festr]

this latest version converted first 56 frames OK (including vertical stripes removing) but the rest of 56-222 frames are green again