Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Ottoga

#76
Camera-specific Development / Re: Canon 7D
April 18, 2016, 01:20:54 AM
@a1lex
Ok, thanks for the reply.
#77
@A1ex
Do you still want more test data from a 7d?  If so give me a link to your test raw_rec modules and I'll run your test script against them.
#78
Camera-specific Development / Re: Canon 7D
April 17, 2016, 03:13:27 PM
Does the "Delayed Start"  script work on a 7D? I'm using April 17, 2016 nightly. Camera in "M" mode and Global Draw is Off.

With the movie mode enabled, I have tried it with normal movies, raw (MLV) enabled and raw_rec enabled. It doesn't appear to work.

Steps taken:
normal movies
Switch camera into movie mode
Set Delay amount value
Set Stop After value
Highlight the run option and press play (nothing happens), press Set (nothing happens)
Pressing the start/stop recording button just starts recording without any delay.

Raw movie modes
Switch camera into movie mode
Enable raw video mode (mlv or raw only)
Set Delay amount value
Set Stop After value
Highlight the run option and press play (nothing happens), press Set (nothing happens)
Pressing the start/stop recording button just starts recording without any delay.

the lua module is loaded and appears to work. I can access the calculator, editor and play pong.

Fundamentally, even though I can set the required run time paramaters, I don't seem to be able to get the script to actually run. Am I missing something or just doing it wrong?
#79
Tried it on my 7D.
Global draw off, max resolution and again at 5x. Continuous recording ok.  With global draw on and 5x recordings recording stopped after approx 30 seconds.

Output was 3 x multi chunk  files and 1 x single chunk.

All were able to be opened and processed in MLVP.
#80
@kidfob
Ok, gave this a test today. I could have used this last October after returning home from a "Bucket List" holiday.

Likes

  • It just works
  • [edit] Ability to adjust the number of threads used by the application
  • Automatically handles Dual ISO CR2 and DNG files. (Some suggestions on how to handle the originals below)
  • Sub folder management for processed files. Although, I feel that there can be some improvement here (see suggestions below)
  • Ignores sub folders in the source path that are empty or don't contain cr2/dng files
  • Progress feedback on screen and log files

Dislikes

Installation location
The application installation doesn't adhere to common windows standards.
i.e.: 32 bit programs should be installed to the "Program Files (x86)" folder  and 64bit programs should be installed to the "Program Files".

Your application installs its executable into here:
C:\Users\ottoga\AppData\Local\Apps\2.0\WRA2MAW5.WOX\G8EX5A5M.O9K\dual..tion_0000000000000000_0001.0000_59e1370d8110acf4

As a result, the user AppData directory which, in a default Windows installation is a hidden directory is now exposed introducing a potential risk to non power users. On first use, it is exposed via the "Set Image Folder" and "Set cr2hdr Path" buttons whose dialogue boxes open within the applications installation directory. Subsequent uses default to the last selected path which is ok.

Suggestions

  • Installation be changed to comply with Windows standards.
  • "Set Image Folder" and "Set cr2hdr Path" buttons be changed to open in the users default image/pictures and possibly documents directories respectively.

No ability to select cr2hdr run time parameters
Default settings for a first pass bulk process is fine however, after a review of the processed images, alternate or debug parameters settings may be required for reprocessing. From a user perspective it would be preferable to select the run time parameters here rather than use another app to do this.

Suggestion
Expand GUI to include a selectable list of parameters to be passed to cr2hr and build the run command based on the selections.

Original Source Dual ISO is lost if it is a DNG file
Unlike CR2 files where the original source files are retained, for DNG files they are lost.

Suggestion
Copy all DNG files to an Original DNGs folder prior to processing.

Non Dual ISO CR2s are copied to the "Dual ISO Original CR2" Folder
This is confusing as the outcome is inconsistent with the folder naming convention.

Suggestion
Either rename the folder to something like "Processed Originals"
or
Retain the exiting file name and don't move non dual_iso CR2s into it
or
Create another subfolder "Non Dual_ISO CR2s" and move the "non dual_iso CR2s " files there.

Any of the above would then make it very clear to the user what they should expect to find within the process folders.

Bugs

When initially setting the cr2hdr path using the "Set cr2hdr Path" button the actual path selected was not displayed in the value filed beside the button. I ended up copy and pasting the value in. Subsequent launches retained and displayed the path.

Anyway that's my 2 cents worth.  With a bit more refinement, I can see this becoming a very useful tool in the ML communities toolkit.
#81
Very nice.
#82
@dfort
QuoteJust to make sure we're on the same page, we're using reddeercity's 5D2 dual iso MLV file for this test:

https://www.dropbox.com/s/utb5b9hvfzuxr52/M19-2200.MLV?dl=0
Correct

QuoteI have not encountered that artifact you pointed out with MLVFS on the Mac.

It may be a Windows or w10 specific issue. I don't have a MAC or W7 machines so I can't do any parallel testing.

QuoteHave you tried processing those raw2cdng processed dual iso DNG files in cr2hdr?

Here are the results.

For those reading, this test result is specifically referring to dual_iso dng frames extracted from a dual_iso video.

mlvfs frame processed through cr2hdr

The same band of horizontal discolouration in the lower half of the image that is present in the original extracted frame is retained in the processed frame.
No errors logged by cr2hdr

Original unprocessed frame:  https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11735&authkey=!AAdkihGIrgX66lA&ithint=file%2cdng
cr2hdr processed frame:       https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11635&authkey=!AJoTpvZKJdKgdxs&ithint=file%2cDNG
cr2hdr run time text:            https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11737&authkey=!AISReBXRWPvt5Gc&ithint=file%2ctxt

mlv_dump frame processed through cr2hdr
Successfully processed with no errors logged by cr2hdr.

Original unprocessed frame:  https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11718&authkey=!ABhj6JPqDUwNQrI&ithint=file%2cdng
cr2hdr processed frame:       https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11658&authkey=!AGfXcTSg0lAm7DU&ithint=file%2cDNG
cr2hdr run time text:            https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11739&authkey=!AFJZ5yUIETuwZUA&ithint=file%2ctxt

raw2cdng_v1.6.5 and 1.7.8 frame processed through cr2hdr
cr2hdr didn't like the frames extracted by either version of raw2cdng displaying a number of 'offset too large" messages during processing. The output files generated are essentially a discoloured distortion of the source dng. They visually still look like dual-iso's but are no longer recognised as such by cr2hdr. The examples below are from v1.7.8.

Original unprocessed frame:  https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11758&authkey=!ACLei2iSHagG5mQ&ithint=file%2cdng
cr2hdr processed frame:       https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11695&authkey=!AIhe-SmbWq1W29Y&ithint=file%2cDNG
cr2hdr run time text:            https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11738&authkey=!AEPQG2ghgiDWvqM&ithint=file%2ctxt

Post processing conclusions of dual_iso from the sample video in my w10 environment......

  • mlvfs has a potential problem with the initial frame extract that that causes corruption within the pre-processed dual_iso frame. post processing of the frame using amaze interpolation fails to correct this however mean23 interpolation did. Note that @dfort has advised that he is not seeing this issue in his Apple MAC environment
  • mlv_dump coupled with cr2hdr resulted in a clean extract and successful post processing of the dual-iso frame
  • raw2cdng coupled cr2hdr: a visual inspection of the extracted frames a successful extraction however cr2hdr encounters offset problems and fails to process the extracted frame correctly

Remember that these test results from one source video with capture parameters that may or may not have contributed to the results. If you are into dual_iso video then I urge you to perform similar tests and give feedback to the devs. Given good feedback and examples will enable them the tools available and provide a consistent post processing experience for all supported platforms.

#83
@dfort

I pm'd you.

QuoteHave you tried processing those raw2cdng processed dual iso DNG files in cr2hdr?

No, but I can give it a go and report back.
#84
@dfort   Correction @dmilligan - a new headache for you  :)

I was using reddeercity's dual_iso  mlv clip to perform some time trials of mlvfs vs other dual_iso processing utilities when I stumbled across a potential issue with mlvfs.

My hardware ASUS s550c notebook, intel i5 processors (4 cores), Intel HD graphics, 6gb RAM, OS w10_Pro

Dual_ISO mlv clip used from this link: https://www.dropbox.com/s/utb5b9hvfzuxr52/M19-2200.MLV?dl=0

The following links are for the same frame extracted from the mlv with hot/bad pixel fixing and chroma smoothing enabled only from mlvfs_x64, mlv_dump and raw2cdng respectively. Note the mlvfs images were just dragged and dropped from the virtual dokan folder to a local HD folder.

from mlvfs_x64:     https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11635&authkey=!AJoTpvZKJdKgdxs&ithint=file%2cdng
from mlv_dump:     https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11658&authkey=!AGfXcTSg0lAm7DU&ithint=file%2cdng
from raw2cdng:      https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11654&authkey=!AP3YXZLggtyjtLQ&ithint=file%2cdng

If you compare the images you will see that in the mlvfs extracted frame, there is a band of horizontal discolouration in the lower half of the image that does not occur in the other two images.

I tried various combinations of bad pixel fix, vertical stipe fix and chroma smoothing in mlvfs to see if it would correct the issue to no avail.

Next in mlvfs, I enable the Full 20it dual_iso with Amaze interpolation, Alias map ON and Fullres blending ON. The following is a link to the processed image:
https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11607&authkey=!AHl0M4oRKUS65fQ&ithint=file%2cdng

When inspecting this image you will se that the horizontal discolouration is still visible in the image. I tried again with combinations of Alias Map and Fullres Blending ON/OFF to no avail.
Lastly, I switched from Amaze interpolation to Mean32 and voilĂ ! the frame was processed cleanly as per the following example.
https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11619&authkey=!AJnOkHpyiK5v_fI&ithint=file%2cdng

Is this an issue? Clearly, not a major one as I was ultimately able to successfully process the dual_iso mlv using mlvfs. However, based on my observations during this testing exercise, a couple of questions are raised my mind:


  • For MLVFS, what is different in the logic that converts the individual frames to dngs vs mlv_dump and raw2cdng?
    It seems to me that this is where the problem lies.
  • It is my understanding that Amaze is a superior interpolation algorithm/process than mean32. So why didn't it work?

Some links to additional frames extracted from the mlv clip and demonstrating the above.

MLVFS unprocessed dngs:           https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11591&authkey=!AJnfDU17yD92grI&ithint=folder%2cdng
mlv_dump unprocessed dngs:     https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11657&authkey=!AOuzH6UPxPb-0R8&ithint=folder%2cdng
raw2cdng unprocessed dngs:      https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11592&authkey=!ABIMtCaTULWJie8&ithint=folder%2cdng
mlvfs dual_iso using Amaze:       https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11589&authkey=!AEWf0uZEcrkT0P0&ithint=folder%2cdng
mlvfs dual_iso using Mean32:     https://onedrive.live.com/redir?resid=C1A12E009BA4F636!11590&authkey=!AHf8g2U5lutfPTQ&ithint=folder%2cdng
#85
@Kharak

A link to mlv_dump can be found here. http://www.magiclantern.fm/forum/index.php?topic=7122.msg59525#msg59525

If you are a Windows or Linux user:

  • Copy the relevant binary into your source mlv files directory
  • Open a command window (I always do this in administrator mode)
  • Change directory to your source MLV files directory
  • As a first time user, run mlv_dump without any parameters to display a list of available parameters.

As you are trying to create some cut down versions of your MLV files the following run string should achieve this:

mlv_dump -o output_filename -f [nr of frames] -c -l compression_level(0-9) <inputfile_name>

eg:  mlv_dump -o M20-1234_new.mlv -f 50 -c -l 9 m20-1234.mlv

The value of the number of frames in the -f parameter is optional.  The more frames that you extract the larger the output file.

The -c and -l parameters are optional but will reduce the size of the output file and as such, the time required to download it for @chmee.

#86
@Kharak
Its an option in mlv_dump.
#87
@dmilligan

So does bad pixel equate to hot pixel in ML speak and recovery process?

I would define a bad pixel as one which is say permanently off (dead) or permanently stuck to a specific colour. I can see analysis the first frame only working for these. Whereas a hot pixel may not manifest itself until some time after the camera has been in use, specifically when the camera starts to get hot. if this true then only checking the first frame would risk missing these.

If you have to have a separate process for hot verses bad pixels would defeat the purpose of your proposed bad pixel management. Don't get wrong, I like the idea. Just thinking out loud of a potential pitfall that could just lead whole new slew of support issues.

Apologies if my thoughts are a pile of nonsense.

#88
@reddeercity
QuoteNo , It take Cdng,s & DNG's Trust me ! Just drag & drop on the batch list that's how I  process all of  my Dual ISO on Windows.

Your right, tried it on another PC and it works fine. May need to reinstall Barracuda_GUI on my main notebook.

QuoteFunny I never got any error  , All DNG's, are accounted for no missing
MLRawViewer didn't display any error messages. The error identified was written into a log file that is located in:
     C:\Users\[username]\.mlrawviewer - @danne has identified a metadata mismatch which was the cause of the
                                                                      error message.
#89
@kgv5
QuoteI tried the newest MLVProducer (PC win7 64) but couldnt export processed dualiso files as CDNGs despite preview which looked ok and processed. CDNGs still have stripes after export. Does this feature works in build 2241.intel ?

MLVP is a work in progress. At this stage it will process dual ISO MLVs when exporting/rendering as a video (MOV format) only.

For now I suggest that you use MLVFS, cr2hdr or Barracuda_GUI.
#90
@dfort @reddeercity
QuoteI have built and re-built cr2hdr from the cr2hdr branch on more than one Mac and verified that it keeps tripping up on the same frames from DeafEyeJedi's sample 5D2 files. Has anyone tried to convert these files on Windows or Linux?

DNG's -- https://mega.nz/#F!qgFDVIYY!Qe6XZc8FyVnbM6C4_OtdsA

MLV's -- https://mega.nz/#F!Wo8SDLaR!KD98tGfnzJMHlLy-cllB1A

Does anyone have another short Dual ISO test shot on a 5D2 they can post to see if this is a recurring issue or maybe just something with that one sample?

My test results processing the MLV's in a W10 environment. MLV file names were M14-1732 and M14-1733. A third MLV file from reddeercity m19-2200 was also tested.

Initial observation is that mlv file m14-1733 is not a Dual ISO mlv file. A visual inspection of the individual DNGs does not show the tell tale bright / dark horizontal lines of the alternate ISO's. Also, none of the apps used for testing recognised the DNGs as Dual ISO. If it was filmed in Dual ISO, then I'd suggest that some other setting in camera has overridden the alternate ISO value.

For files M14-1732 and m19-2200:

MLVP with Dual ISO enabled

  • Was able to export a video file. Playback showed that that the individual frames had been processed for dual ISO successfully. In M14-1732 there did appear to be a bit of fringing? around the window frame.
  • Exported cDNGs were not processed for dual ISO 

MLVFS Dual ISO enabled

  • From the virtual folders, I was able to successfully view dual ISO processed DNGs and successfully extract them to local HD directory.

MLVP with Dual ISO disabled and cr2hdr

  • Dragging and dropping dngs from the dokan virtual drive directly onto cr2hdr resulted in cr2hdr going through the motions but it was unable to overwrite the original dng with the dual ISO processed image.
  • Dragging and dropping dngs directly from the dokan virtual drive into a local directory on my HD and then processing them through cr2hdr successfully processed them as dual ISO images. Note that this resulted in the source dngs being overwritten with the dual ISO processed dngs.
  • In both of the above bullet points the warning "Exiftool - not recognised as an internal or external command, operable program or batch file", "Exiftool couldn't update dng data" was display. Exiftool was in the same directory as cr2hdr so in light of a better explanation, I assume that this is because the source file was a dng that was being overwritten by the process.

Barracuda

  • No joy here as this app only accepts .cr2 files as input


Edit:  Correction. I was able to get this app to process the dng frames after extracting the individual frames to a local HD directory and renaming the file extensions from .dng to .cr2
Edit2: Correction. If I run this app via the desktop shortcut created at installation time vs from its installation directory, then dragging and dropping dngs into the app works fine.

MLRawViewer v1.4.3

  • Allows preview of video but cannot process dual ISO.
  • Allows export to dng but cannot process dual ISO.
  • The following error was logged for reddeercity's file M19-2200.mlv

    MlRawViewer v1.4.3
    (c) Andrew Baldwin & contributors 2013-2014
    Using GLFW
    Loading 'D:\\MLVs\\M19-2200.MLV'
    Set indexed. Frames missing: 2
    M19-2200.WAV D:\MLVs\M19-2200.WAV
    FAILED TO FIND FRAME AFTER SCAN 212
    FAILED TO FIND FRAME AFTER SCAN 213

MLV Converter 1.9.2

  • Extracts the dng frames 1st, then processes the extracted dngs for dual ISO (overwriting them). A very slow process (5 seconds per frame to convert to dual ISO on my notebook).
    There is a restricted parameter set for the dual ISO conversions.
  • Can produce a proxy mov video using temporary tiff files generated from the dual ISO processed dng files. There was a noticeable colour shift in the proxy video vs the source dng images.

Hope this helps.
#91
@dfort
QuoteI don't think that's a troll post--the 7D is about the same vintage as the 5D2 so maybe it will work. Of course someone has to be the guinea pig.

I'm happy to be the guinea pig if you can provide the relevant updated modules.
#92
@Tai.Fighter

I've had this happen to me in the past. After much searching and reading on the forum I found a reference to a similar problem.

The solution was to turn OFF the link to Dual ISO in Auto ETTR.

It may not be the case here but if you are using Auto ETTR and Dual ISO at the same time it might be worth a try.
#93
@Markus

QuoteYour mlvfs launch command:

c:\mlvfs_x64\mlvfs_x64.exe X:\ --mlv-dir=c:\

The '\' in your X:\ parameter is not required.

The parameter --mlv-dir=c:\  as per your launch command will result in MLVFS (or more likely the background dokan service) passing through, trying to map and interpret all files and sub-directories under the root of C: to drive X:

I'd suggest that under this scenario it is probably hitting a file that it can't deal with elegantly and as such causing the error. It also looks like it is trying to process the same MLV file twice which may be causing a conflict.

the --mlv-dir= parameter should contain the path to the folder where the MLV files that you want to process actually reside.

So, based on your screen shots I suggest that your mlvfs launch command should be:

c:\mlvfs_x64\mlvfs_x64.exe X: --mlv-dir=c:\HEj

MLVFS as a process appears to be working as it has successfully analysed M17-1143.mlv given that it is listed with all details in your localhost view. So hopefully with a corrected launch command you will be successful.

If you are still getting the error after that, then I'm at a loss and will need to hand your issue up to DMilligan. just provide fresh screen shots including some from File manager showing drive X: and any of its sub directories as well as one with a sub-directory contents showing.
#94
@MARKUS

QuoteUsed the following string to mount: "mlvfs_x64.exe C:\MLV --mlv_dir=F:\DCIM\100EOS5D\"

It looks like the format of your MLVFS launch command is incorrect. 'C:\MLV' is a path to a folder not a drive letter. Try the following:

launch a command prompt (in administrator mode) then:

cd /d [path_to_your_mlvfs_x64_rc.exe]

mlvfs_x64.exe X: --mlv-dir=[path_to_your_MLV_dir]

Where X: - the logical drive letter that will be assigned by the system for mounting the MLV file/s. Note that it doesn't have to be X: but it needs to be a drive letter that is not already in use on your computer.

Then type the url http://localhost:8000/ into your default browser that will bring up the GUI and let you configure the MLVFS correction/adjustment parameters.

Also, once you have done the above, if you launch Windows File Explorer you should see your chosen drive letter listed and the individual MLV files listed as sub-directories.

A small tip: set your preferred correction/adjustment setting in the GUI before accessing a mounted mlv folder in your logical drive or the settings won't be applied.

The MLVFS process will automatically build index files for each of the MLV files in your --mlv-dir location.  I see from your mount string that you are going directly to the CF card. under this scenario the index files will be created on your CF card. There might be a performance hit from this approach. Also, this is where your original footage is. If there is a hiccup with your PC that causes the card to corrupt then you have potentially lost everything.

It would be safer and I dare say faster if you copied your MLVs to a directory on your local hard drive.
#95
@Markus

QuoteDoes anyone know if it is possible to process dng - sequences for fixed pattern noise if you haven't saved the mlv's?

From memory, you might be able to use mlv_dump to recreate an MLV file from a DNG series. One of the Devs may be able to confirm that.

If this is confirmed, then the answer to your question is likely to be "yes".

Oh, I also uninstalled Pismo and rebooted my PC before installing Dokan. I didn't see any point having two services running in the background that are essentially trying to do the same thing. Just something else to consider.
#96
@Developers

Just a note to advise that Dokan v1.0.0-RC2 is available and, at least on my W10 system is working error free. Tested with single and multi-chunk MLV's.
#97
@Markus

First try using the latest supported versions of Dokan and MLVFS.

Links to these can be found here:  http://www.magiclantern.fm/forum/index.php?topic=13152.msg163041#msg163041

Note that you will need to uninstall Dokan first before reinstalling the latest version. The MLVFS download totally replaces your existing install instance.

Also, do the paths to your MLV files contain spaces?  If so, create a path without spaces and try again.

If it still fails after that, report back with some screen shots demonstrating successful Loading of Dokan, File mounts (A localhost one) and the error message when trying to access a specific DNG.

What application are you using to access the DNG's. The issue may be with the application and not MLVFS. what happens if you just double click on a DNG to view the image with windows default viewer.

@DMilligan - Might be worthwhile to update the links in the 1st post to reflect the latest supported versions.
#98
Raw Video Postprocessing / Re: MLVProducer
March 06, 2016, 03:43:02 AM
@mohanohi

Maybe try a naming convention like MLVname_InFrameNR_OutFrameNR eg: M08-1422_150_249. This will easily let you reference back to your original.

@AWPStar, maybe an option to append these to the file name at render time?
#99
Raw Video Postprocessing / Re: MLVProducer
March 04, 2016, 09:07:50 AM
@AWPStar

build 2253

New presets system       -  Nicely done.
fix of 3DLut                   -  Yep they work again
fixed output folder bug   -  can't say that I experienced this
and some crashes...       -  Anything that improves stability has got to be good.
#100
Raw Video Postprocessing / Re: MLVProducer
February 29, 2016, 08:55:39 AM
@awpstar

QuoteI plan to implement automatic updates

Sounds like a great idea.