Dealing with Focus Pixels in raw video

[dfort]

Yay!

SL1/100D Dual ISO with MLVFS commit 1bc6f7f and focus pixel map file

No point posting non-Dual ISO shots because they look just as good as the previous build. Damn near perfect. My understanding is that no Bayer pattern demosaicing algorithm is perfect so toss in a bunch of focus pixels into the mix just to make it that much harder. The SL1/100D shows the most focus pixels and hard vertical lines seem to be the most difficult to tame.

SL1/100D Dual ISO with MLVFS commit 1bc6f7f and focus pixel map file

I tried chroma smoothing again and this time cs5x5 seemed to give the best results.

SL1/100D Dual ISO with MLVFS commit 1bc6f7f and focus pixel map file Chroma Smoothing 5x5

The focus pixel problem is present in all Dual ISO shots I examined closely. Reviewing this shot I used before.

EOSM mv1080crop Dual ISO

   

Even with the latest MLVFS build and focus pixel map there are still a few stray focus pixels present.

Now look very closely at the two green dots in the above shot and try to find them below.

Chroma Smooth 2x2

Of course this is real pixel peeping. Once rendered to a movie file or posted online there should be no issues.

I'm hoping that this is the last chart I'm going to post in this topic.

Canon SL1/100D Dual ISO, MLVFS commit 1bc6f7f and focus pixel map

@dmilligan
I'm not sure how you want to roll this out but of the four cameras we identified with focus pixels in raw video, three of the cameras share the same map files. I was going to suggest that if a camera has an id number within a certain range to use the same map but according to the exiftool code that isn't possible.

Code: [Select]

    0x80000301 => 'EOS Rebel T4i / 650D / Kiss X6i',
    0x80000302 => 'EOS 6D', #25
    0x80000324 => 'EOS-1D C', # (NC)
    0x80000325 => 'EOS 70D',
    0x80000326 => 'EOS Rebel T5i / 700D / Kiss X7i',
    0x80000327 => 'EOS Rebel T5 / 1200D / Kiss X70',
    0x80000331 => 'EOS M',
    0x80000355 => 'EOS M2',
    0x80000346 => 'EOS Rebel SL1 / 100D / Kiss X7',
    0x80000347 => 'EOS Rebel T6s / 760D / 8000D',
Oh yeah--updating the MLVFS test build in my bitbucket download area. I do encourage everyone with an EOSM, 650D, 700D or 100D that wants to work with MLV give it a try.

@AWPStar
Hope this helps your project too.

@Steve_FR
Thanks for finding those pixels that I overlooked.

[dfort]

Can't seem to let go of this topic--here's some more of my thoughts on how to deal with focus pixels.

So far it looks like there are a couple of ways to deal with them. One is the shotgun approach by applying chroma smoothing over the entire image and the other is targeting only the focus pixels themselves. Mapping out all the focus pixels that are on the sensor creates a rather large list of coordinates but the pixels make a simple repeating pattern that can be tiled, therefore saving lots of space and possibly speeding up processing.

The EOSM, 650D and 700D all share the same pattern. When seen in crop mode there is no line skipping.

The pattern on the 100D is denser but it is also a simple repeating pattern.

When the cameras shoot in mv1080 mode they all create the same pattern.

Likewise in mv720 mode.

As you can see you only need four basic patterns to cover all the cameras in every video mode. Actually if you are clever enough you could use the two full patterns and line skip them to create the other two patterns.

I've also been thinking about what causes these pixels to turn green or magenta. When processed through dcraw -d it is possible to get a clearer view of the focus pixels. Note how some turned white and others black.

Exactly how these focus pixels function isn't something that we explored in this topic but what we do know is that they seem to turn on and off. Sometimes they are invisible and I have yet to see an example that shows all of the pixels in a single shot. What is interesting is that it seems to depend on the color of the background and whether or not the pixel is next to a high contrast area giving the appearance something like focus peaking in a video monitor.

Back on Reply #69 a1ex explained that the focus pixels are only on the red or blue areas of the Bayer pattern. If the pixel turns off it is filled in with the surrounding green pixels and if it lights up it has an absence of green thus turning magenta (a.k.a. "pink dots"). I'm only speculating but it seems to make sense.

Whatever the camera is doing in firmware to hide these focus pixels, it is doing a very good job. a1ex explained that there are other ways to capture raw video. Perhaps one of these alternate methods can capture the data after it has gone through the focus pixel annihilation process? That would make this topic obsolete which would be a very good thing for EOSM/650D/700D/100D users who want to explore raw video.

I'm not done working on this. While MLVFS is great for Mac users, Windows and Linux users may be feeling left behind until other tools like mlv_dump can deal with focus pixels in the same way.
[EDIT: Well, MLV Producer does a good job and it will probably get even better.]

Right now I'm working on using the focus pixel map files we created for this topic along with the MLV metadata that shows how to crop the map file for each image size and creating files that can be used with dcraw. I'm also planning to include the maps for the first generation raw video which doesn't have the metadata but it wasn't too difficult to figure it out--well we'll see if it worked once the files are ready. I don't expect any developer to pick up on this side project but it does give users another tool to deal with focus pixels and it can be used with Mac, Windows and Linux.

[dmilligan]

While MLVFS is great for Mac users, Windows and Linux users may be feeling left behind

MLVFS works fine on Linux, and as of yesterday Windows too

a1ex explained that there are other ways to capture raw video. Perhaps one of these alternate methods can capture the data after it has gone through the focus pixel annihilation process?

I wouldn't really say there are "other ways" to capture raw video, there are just other possible video modes. Capturing them is the same, you just have to figure out how to get Canon firmware to put the camera in those modes. The EOSM is unique b/c Canon firmware doesn't put it into mv1080 until you start recording (H.264). So if you want to record raw video on mv1080, you have to do it while also recording H.264 at the same time (ML prevents you from doing this now a days, but it was possible in some old versions when raw video just came out). That or do some reverse engineering to figure out how to put the camera in mv1080 without starting recording. All other cameras go into the video mode you selected in the Canon menu immediately, so actually mv1080 is pretty much the "default".

[dfort]

MLVFS works fine on Linux, and as of yesterday Windows too

Great news! Is the version with the focus pixel map files also working on Linux and Windows?

[Danne]

Right now I'm working on using the focus pixel map files we created for this topic along with the MLV metadata that shows how to crop the map file for each image size and creating files that can be used with dcraw.

  Oh yes

MLVFS works fine on Linux, and as of yesterday Windows too

MLVFS fully cross platform now? Remarkable.

[dfort]

@dmilligan

[EDIT: Upon further checking it looks like I've got some more refinement on my script but this part of my post is still relevant.]

I've got a bit of a problem with my bash script to create dcraw badpixels files from the focus pixel map files. The crop metadata doesn't seem to be correct in some cases. I saw you had this in your code:

Code: [Select]

        //there was a bug with cropPosX, so we'll round panPosX ouselves
        int cropX = (frame_headers->vidf_hdr.panPosX + 7) & ~7;
        int cropY = frame_headers->vidf_hdr.panPosY & ~1;

Looks like I need to read up on bitwise operators but isn't this something that should be corrected in the mlv_rec module?

[dfort]

Whack on the side of my head--figured it out.

So this change was done in mlv_rec by a1ex on January 13, 2016.

Code: [Select]

#     hdr->cropPosX = (skip_x + 7) & ~7;
#-    hdr->cropPosY = (skip_y + 7) & ~7;
#+    hdr->cropPosY = skip_y & ~1;

Of course that means that any MLV file shot before this change has the incorrect Crop information in the metadata. So MLVFS is taking the Pan and calculating the Crop. I was wondering why MLVFS pixel fix was working with my old files. Very clever programming on the part of dmilligan.

Nitpicky note -- the comment in MLVFS says there was a bug with cropPosX, it should read cropPosY. Super nitpicky, "ourselves" is misspelled.

My bash script was using the Crop information which works fine for new MLV files but I was a bit careless last night and checked an old MLV file, of course that didn't work. In any case I learned something about bitwise operators and now my script also works with older MLV files.

I'll make up a batch of focus pixel map files that can be used with dcraw. Here's the script I'll be using. Most of it is comments so I'll shut up now and encourage anyone interested in this stuff to read the source code. Most of it has already been discussed in this topic.

fpm2badpixels.sh

Code: [Select]

#!/bin/bash

# fpm2badpixels.sh
#
# Create a dcraw ".badpixels" formatted file from
# MLVFS .fpm (focus pixel map file)
# For removing focus pixels from Magic Lantern raw video
# files shot on on Canon 100D, 650D, 700D and EOSM cameras.
#
# Usage fpm2badpixels.sh [frame_size][pan][fpm_file]
# The frame size is the final size of the movie frame.
# The crop and pan information can be read from the mlv
# metadata using "mlv_dump -v -m [mlv_file]"
#
# example--for a 1280x720 mv1080 shot with a T5i / 700D:
# fpm2badpixels.sh 1280x720 296x247 80000326_1808x1190.fpm
#
# The output file in dcraw "badpixels" format is named the same
# as the input parameters. For the above example:
# 1280x720_pan296x247_80000326_1808x1190.fpm.txt
#
# The file can be renamed and comments added as per the
# dcraw documentation.
#
# You need to know the buffer size for the video mode you
# are using to pick the right .fpm file.
#
# Mode          Buffer Size   Notes
# mv1080      - 1808x1190  -  not available on the EOSM.
# mv720       - 1808x727   -  needs to be stretched by 1.67x
#                             vertically - up to 50/60 fps
#                             except on EOSM.
# mv640       - 1808x1190  -  basically the same as mv1080 mode.
# mv1080crop  - 1872x1060  -  highest resolution and largest
#                             sustainable frame sizes on all cameras.
# mv640crop   -            -  not possible.
# zoom        - 2592x1108  -  same 5x magnification as mv1080crop
#                             but can pan around sensor.
#                             Performance not as good as mv1080crop.
#
# Sorry but with zoom mode a new badpixels file needs to be made
# every time that the pan position changes.
#
# This is a very simple shell script and can be greatly improved.
# For example with MLV files it should be possible to extract
# the image size and crop information from the metadata and
# the focus pixel map file shouldn't be necessary because it is
# a simple pattern that can be built on the fly. In addition, raw
# video without metadata should be able to be supported with minimal
# user input about the video mode. The crop information should
# be able to be determined for most modes except zoom mode because
# of the multiple buffers and the frame can move around within the
# raw buffer.
#
# This script does not support filenames and paths with spaces
# and there is no error checking.
# Hey, what do you want for nothing.
#
# 2016 Daniel A. Fort
# This is free and unencumbered software released into the public domain.

SIZE=$1
PAN=$2
FPM=$3
output="$SIZE"_pan"$PAN"_"$FPM"

IFS='x'
read -r width height <<< "$SIZE"
read -r panPosX panPosY <<< "$PAN"
unset IFS

# We would rather work with the Crop information from the MLV file
# but there was a bug in the way that the Y axis was calculated.
# This was fixed by a1ex on commit 2e5367a but that means any
# MLV file shot on a nightly build prior to January 12, 2016
# has this bug. So let's round Pan instead of using Crop.

cropX=$((panPosX + 7 & ~7))
cropY=$((panPosY & ~1))

while read -r raw_buffer_x raw_buffer_y; do
  ((x = $raw_buffer_x - $cropX))
  ((y = $raw_buffer_y - $cropY))
  if (( "$x" >= 0 )) && (( "$y" >= 0 )); then
    if (( "$x" <= "$width" )) && (( "$y" <= "$height" )); then
      echo -e "$x \t $y \t 0" >> $output
    fi
  fi
done < "$FPM"


[dmilligan]

Nitpicky note -- the comment in MLVFS says there was a bug with cropPosX, it should read cropPosY. Super nitpicky, "ourselves" is misspelled.

I misremembered which one (x or y) had the problem, I just knew what it was supposed to be.

[dfort]

[EDIT: I'm pulling the files because they aren't two sizes fits all. Even though the raw buffer pixel maps are the same size, the crops for different cameras are also different. This would mean a much larger inventory of dcraw "badpixels" files would be necessary to cover every camera, every MLV standard image size and every video mode.]

More goodies for experimenters and legacy raw format users. I uploaded a bunch of dcraw "badpixels" formatted files to my bitbucket downloads. The 2016-02-11_dcraw_badpixels.zip package contains all the standard sizes for the various MLV modes. I divided them into two groups. The A group is for the EOSM/650D/700D and the B group is for the 100D. These are the two focus pixel patterns that I have discovered so far.

How to use these files. Check out the dcraw documentation:

-P deadpixels.txt
      Read the dead pixel list from this file instead of ".badpixels". See FILES for a description of the format.

FILES

:./.badpixels, ../.badpixels, ../../.badpixels, ...
      List of your camera's dead pixels, so that dcraw can interpolate around them. Each line specifies the
      column, row, and UNIX time of death for one pixel. For example:

       962   91 1028350000  # died between August 1 and 4, 2002
      1285 1067 0           # don't know when this pixel died

      These coordinates are before any stretching or rotation, so use dcraw -j -t 0 to locate dead pixels.

So let's say you made your dng files with mlv_dump and want to create TIFF files without focus pixels. Here's an example:

Code: [Select]

dcraw -T -P A_mv720_1280x432_pan296x159.txt *.dng
These files can also be used with MLP. Simply take the appropriate file, rename it dead_pixel_list.txt and add that to the A_lut_hold. Then you'll have to add this to the beginning of the file:

Code: [Select]

-P ../../PRORES/A_lut_hold/dead_pixel_list.txt
-P ../A_lut_hold/dead_pixel_list.txt
-P A_lut_hold/dead_pixel_list.txt

As you can see the file doesn't have to be named dead_pixel_list.txt as long as these lines point to the right name. Danne has been adding features to MLP and focus pixel fixing is sure to get easier in the coming releases.

I used the fpm2badpixels.sh script from Reply #181 and to make things easier I also created this simple script to create a batch of files:

Code: [Select]

#!/bin/bash

# This is a very simple hard coded script to generate
# dcraw "badpixels" formatted files from the .fpm files
# and a bunch of MLV files using the fpm2badpixels.sh
# script posted at:
# http://www.magiclantern.fm/forum/index.php?topic=16054.msg162066#msg162066
#
# Sorry but with zoom mode a new badpixels file needs to be made
# every time that the pan position changes.
# This script does not support filenames and paths with spaces
# and there is no error checking.
# Hey, what do you want for nothing.
#
# 2016 Daniel A. Fort
# This is free and unencumbered software released into the public domain.

# Change the path to match where your MLV files are located.
for MLV in /Users/rosiefort/Desktop/Humongous_test/zoom/*.MLV
do

# The script tells you what it is working on so you'll know
# that it is doing its job.

  echo $MLV

# Using mlv_dump we look up the resolution and pan information.

size=`mlv_dump -m -v $MLV | grep Res | head -1 | sed -e 's/^[ Res:]*//'`
echo $size

pan=`mlv_dump -m -v $MLV | grep Pan | head -1 | sed -e 's/^[ Pan:]*//'`
echo $pan

# Run the fpm2badpixels.sh from the current directory and use
# the corresponding .fpm file also in the current directory.
#
# To figure out which .fpm to use for your camera:
#
# 80000301 => 'EOS Rebel T4i / 650D / Kiss X6i',
# 80000326 => 'EOS Rebel T5i / 700D / Kiss X7i',
# 80000331 => 'EOS M',
# 80000346 => 'EOS Rebel SL1 / 100D / Kiss X7',
#
# And for the video mode:
#
# Mode          Buffer Size   Notes
# mv1080      - 1808x1190  -  not available on the EOSM.
# mv720       - 1808x727   -  needs to be stretched by 1.67x
#                             vertically - up to 50/60 fps
#                             except on EOSM.
# mv640       - 1808x1190  -  basically the same as mv1080 mode.
# mv1080crop  - 1872x1060  -  highest resolution and largest
#                             sustainable frame sizes on all cameras.
# mv640crop   -            -  not possible.
# zoom        - 2592x1108  -  same 5x magnification as mv1080crop
#                             but can pan around sensor.
#                             Performance not as good as mv1080crop.
#
# I'm testing with both a 700D and 100D so I'll run two at a time.
#

./fpm2badpixels.sh $size $pan 80000326_2592x1108.fpm
echo ./fpm2badpixels.sh $size $pan 80000326_2592x1108.fpm

./fpm2badpixels.sh $size $pan 80000346_2592x1108.fpm
echo ./fpm2badpixels.sh $size $pan 80000346_2592x1108.fpm

done
If there's any resolution I missed you can make your own with these scripts. Note that the dcraw files will also work with legacy RAW video format but you will note that there are more resolution choices for raw than for MLV. To get these, and more, go to the RAW video (MLV) submenu, select Resolution and click the left and right thumbwheel. You can cycle through all the possible resolutions--there's a boatload!

A few notes about zoom mode. The files I created assumed the zoom was centered. Panning around the sensor requires something more sophisticated like MLVFS. Other programs may also support panning but only with MLV files because the original RAW format doesn't have the necessary Pan/Crop metadata. Another thing I didn't know about until I was creating these files was that with zoom mode the setting allows up to 2496x1074. However, these cameras can only record a few frames of video at that setting.

[Danne]

238,4 MB of mapped pixels  .
Thank you for this. Just downloaded and will see what can be done in MLP and looking forward on further developments. Will try some of these maps with a friend,s 700D.

I could probably change the MLP script to grab the correct pixel map by matching the size through exiftool. Let,s see when I get around to it.

[dfort]

@Danne

You will need to use the 700D build I posted in my bitbucket download area because the current nightly doesn't identify that camera properly in the MLV metadata. This commit needs to get merged into unified for the nightlies to get updated.

Of course if you're going to do everything the hard way like I described it in my previous post you can get by without it.

[DeafEyeJedi]

Gosh this is all incredible stuff and even at this pace it'll most likely get fully implemented w ease by the end of Spring if not Summer.

Great work by Dan and every one else onboard whom have wholeheartedly contributed into this!

[dfort]

Well let's not pop the cork just yet. I was doing some tests and a bunch of the files I posted aren't working. I've been going over my scripts and can't find the problem. Better take a break and come back to it.

[EDIT: Found the problem. False assumption on my part that since the pixel maps for the raw buffers were the same the crops would be the same too. Wrong. Of course this means even more dcraw "badpixels" files should be created and I think things need to be scaled back a bit. The scripts are working fine though so experimenters can still roll their own.]

On an upbeat note I asked my brother to help me figure out how to calculate the pan positions just using the image size for each video mode and he was able to do it.

For mv1080 the minimum size is:

x=640 panPosX=616
y=128 panPosY=543

So the formula is:

Code: [Select]

panPosX=616-((x-640)/32)*16
panPosY=543-((y-128)/2)
He also came up with some error checking in case an invalid image size is entered. This is when having a brother that studied science is cool. I studied art. 

[dfort]

By the way--several people downloaded the package of dcraw "badpixels" files. So--all were made using the pan information from a 700D with the exception of the zoom mode which was done with an EOSM. Why? because the 700D was the easiest working with the Magic Lantern menu and I have a button to center the crop area for the EOSM.

Anyway, I'm taking down that big batch and will probably post something a little less ambitious later.

[Danne]

Here is a MLP testbuild which works with your fpm files through you skillfull scripting. Works with MLV files. It is integrated and automated so end user doesn,t have to worry about anything. Very fine work dfort. The test files looked super clean.
MLP_pixel_fix
https://drive.google.com/file/d/0B4tCJMlOYfirM2lhSHpXQUxOTU0/view?usp=sharing

[dfort]

Great! The goal is to get to the point where focus pixels are no longer an issue. In the meantime, here's something that is useful for more than just experimenters. This script will create a dcraw formatted "deadpixels" list from an MLV file. The raw buffer focus pixel map files need to be in the same working directory as the script but the MLV file can be anywhere in the filesystem. The simplest way to use it is to open a terminal in your working directory, type ./mlv2badpixels.sh and the path and file name of the MLV file. On many terminals you can simply drag and drop the MLV icon right into the terminal window. There are some options. -m adds the MLP headers and -o allows you to enter a custom file name. This still a fairly simple script so don't use spaces in your paths or file names. [EDIT: When I first wrote this I got MLP and MLV mixed up--corrected.]

This makes it so easy to create the files that I may just post all the standard MLV sizes--once I get around to it. Of course it can be better. I'm working on supporting panning in zoom mode. Right now it only works if the focus box is centered.

Oh, and I also found the way to center the zoom area. Simply press the SET button. This should work on all but the EOSM. The Trash button is supposed to do it too but of course it brings up the ML menu. On the EOSM a quick press of the Trash button centers the focus box and a longer press opens the ML menu--provided that's the way the Canon custom menus are configured.

Anyway, here's the script. Have fun!

Code: [Select]

#!/bin/bash

# mlv2badpixels.sh
#
# http://www.magiclantern.fm/forum/index.php?topic=16054
#
# Create a dcraw ".badpixels" formatted file from
# an MLV file (Magic Lantern raw video)
# For removing focus pixels from Magic Lantern raw video
# files shot on on Canon 100D, 650D, 700D and EOSM cameras.
#
# The focus pixel map files (.fpm) for the raw video buffer
# need to be in the same working path as this script.
#
# Mode          Buffer Size   Notes
# mv1080      - 1808x1190  -  not available on the EOSM.
# mv720       - 1808x727   -  needs to be stretched by 1.67x
#                             vertically - up to 50/60 fps
#                             except on EOSM.
# mv640       - 1808x1190  -  basically the same as mv1080 mode.
# mv1080crop  - 1872x1060  -  highest resolution and largest
#                             sustainable frame sizes on all cameras.
# mv640crop   -            -  not possible.
# zoom        - 2592x1108  -  same 5x magnification as mv1080crop
#                             but can pan around sensor.
#                             Performance not as good as mv1080crop.
#
# Sorry but with zoom mode a new badpixels file needs to be made
# every time that the pan position changes.
#
# This script does not support filenames and paths with spaces
# and there is very little error checking.
# Hey, what do you want for nothing.
#
# 2016 Daniel A. Fort
# This is free and unencumbered software released into the public domain.

usage()
{
cat << EOF
Usage: mlv2badpixels.sh [-hmv][-o output_file] <input_file>
Parameters:
   -h           Show this message
   -m           MLP format
   -o filename  Customize Filename
   -v           verbose

example:
   ./mlv2badpixels.sh -mv -o M21-1747_1_2015-12-06_0001_C0000.txt M21-1747.MLV
   creates an MLP formatted file named M21-1747_1_2015-12-06_0001_C0000.txt
   that can be used to remove the focus pixels on the dng files extracted from
   M21-1747.MLV

This script will create a dcraw "badpixels" file
to remove focus pixels from an MLV file shot with
cameras that show their focus pixels in raw video.

EOS Rebel T4i / 650D / Kiss X6i
EOS Rebel T5i / 700D / Kiss X7i
EOS Rebel SL1 / 100D / Kiss X7
EOS M

EOF
}

MLP=
VERBOSE=
output=

while getopts “hmo:v” OPTION
do
  case $OPTION in
    h)  usage
        exit 0
        ;;
    m)  MLP=1
        ;;
    o)  output=$OPTARG
        ;;
    v)  VERBOSE=1
        ;;
    :)  echo "Error: -$OPTARG requires an argument"
        usage
        exit 1
        ;;
    ?)  usage
        exit 1
        ;;
  esac
done

shift $((OPTIND - 1))

MLV=$1

if [[ -z $MLV ]]
then
     usage
     exit 1
fi

if [ $VERBOSE ]; then echo input file = $MLV; fi

camera_model=`mlv_dump -m -v $MLV | grep Camera"[[:space:]]"Model | head -1 | sed -e 's/^[ Camera \s Model: \s 0x]*//'`

resolution=`mlv_dump -m -v $MLV | grep Res | head -1 | sed -e 's/^[ Res:]*//'`
pan=`mlv_dump -m -v $MLV | grep Pan | head -1 | sed -e 's/^[ Pan:]*//'`

IFS='x'
read -r width height <<< "$resolution"
read -r panPosX panPosY <<< "$pan"
unset IFS

cropX=$((panPosX + 7 & ~7))
cropY=$((panPosY & ~1))

if [ $VERBOSE ]; then echo Resolution = $resolution; echo Pan = $pan; echo Crop = $cropX"x"$cropY; fi

raw_width=`mlv_dump -m -v $MLV | grep width | head -1 | sed -e 's/^[ width]*//'`
raw_height=`mlv_dump -m -v $MLV | grep height | head -1 | sed -e 's/^[ height]*//'`
raw_buffer=$raw_width"x"$raw_height

fpm=$camera_model"_"$raw_buffer".fpm"

if [ $VERBOSE ]; then echo Camera Model = $camera_model; fi

case $camera_model in
    80000301)
        camera=650D
        ;;
    80000326)
        camera=700D
        ;;
    80000331)
        camera=EOSM
        ;;
    80000346)
        camera=100D
        ;;       
    *) exit 2
        ;;
esac

if [ $VERBOSE ]; then echo Camera = $camera; fi

case $raw_buffer in
    1808x1190)
        video_mode=mv1080
        ;;
    1808x727)
        video_mode=mv720
        ;;
    1872x1060)
        video_mode=mv1080crop
        ;;
    2592x1108)
        video_mode=zoom
        ;;       
    *) exit 3
        ;;
esac

if [ $VERBOSE ]; then echo video mode = $video_mode; fi

if [ -z $output ]; then
  output=$camera"_"$video_mode"_"$resolution".txt"
fi

if [ $VERBOSE ]; then echo output file = $output; fi

if test -f $output; then rm $output; fi

if [ $MLP ]; then
  if [ $VERBOSE ]; then echo MLP formatted; fi
  echo "-P ../../PRORES/A_lut_hold/$output" >> $output
  echo "-P ../A_lut_hold/$output" >> $output
  echo "-P A_lut_hold/$output" >> $output
  echo "" >> $output
fi

while read -r raw_buffer_x raw_buffer_y; do
  ((x = $raw_buffer_x - $cropX))
  ((y = $raw_buffer_y - $cropY))
  if (( "$x" >= 0 )) && (( "$y" >= 0 )); then
    if (( "$x" <= "$width" )) && (( "$y" <= "$height" )); then
    echo -e "$x \t $y \t 0" >> $output
    fi
  fi
done < "$fpm"


[Danne]

Nice progress. Did anything with the functioning of dots change from the first script? Does it work for all sizes in MLV that are not filmed in 3xzoom mode?
I like the MLP header -m option. However. For MLP to respect a pixel list file it has to be named dead_pixel_list.txt and be put in the A_lut_hold folder and first then it will cat the correct header path from the file.
Then again the experimental MLP version above automated a workflow around your script so that it converts and creates the pixel map for each specific MLV file from the affected cameras and puts it inside the folders of dng files without having to worry about it. This means there,s no need for the MLP header paths when using your script. I should erase them from your script in the MLP above to avoid confusion.
MLP will use the specific list created for each folder of dng files so you can also create prores files straight from the dng folder once it is processed from MLV to dng files. No need to reprocess the MLV file. The created file will be named dead_pixel_list.txt.

MLP calls you package of fmp files and the included mlv2badpixels.sh
loosely explained from MLP

In the mlv_raw.txt script

Code: [Select]

for FILE in `ls -tr -A1 *.MLV *.mlv 2>/dev/null`; do
pix=$(cat /tmp/magic_l_prores/list_dng) #cats the folder path
#Creating a pixel fix map
~/Library/Services/MLP.workflow/Contents/bmcc_ixml_luts/Pixel_Map_Files/mlv2badpixels.sh $pix/$FILE
doneThen moving to correct folder and renaming the file to dead_pixel_list.txt

Code: [Select]

mv ~/Library/Services/MLP.workflow/Contents/bmcc_ixml_luts/Pixel_Map_Files/*.txt ../${BASE}_1_"$date_01"/dead_pixel_list.txtthen a simple if, then, fi before transcoding

Code: [Select]

if ls "dead_pixel_list.txt"
then
dpf_a=$(echo -P "dead_pixel_list.txt")
fi
Processings scripts from MLP are
fold_prores.txt
fold_prores_02.txt
fold_prores_01.txt
process_01.txt


By the way. I added this to the path in your script so now you can simply drag the script to terminal instead of doing cd and ./ into the folder.

Code: [Select]

#!/bin/bash
workingDir=`dirname "$0"`
cd "${workingDir}"
Thanks for all your hard work on this.

[DeafEyeJedi]

Finally I'm on my way home from being on the road for this week ... Can't friggin wait to get my hands on a Mac and run this automagically script of yours! Thanks Danne for polishing up his fine ass script!

[dfort]

Nice progress. Did anything with the functioning of dots change from the first script? Does it work for all sizes in MLV that are not filmed in 3xzoom mode?

In the first script it didn't check if the file already exists so it would append the new list to the old list. Not very efficient. There were some other tweaks like taking all the information from the MLV file and naming the file by camera name, video mode and resolution. It works for zoom mode too but it doesn't support panning during the shot. That seems something that can be added.

By the way. I added this to the path in your script so now you can simply drag the script to terminal instead of doing cd and ./ into the folder.

The script needs to reference the raw buffer focus pixel map files. I'm going to have to experiment with your change to see how that works.

Of course it can be improved like supporting dynamic panning in a shot and adding an option to manually enter camera and video mode so that it can be used on RAW files or for MLV files that have corrupted metadata. I was thinking of putting up this script in bitbucket, sort of like a beginner's coding project.

[Danne]

How about simply grabbing the frame size from the RAW dng file and build a map file from that piece of information?

[dfort]

In addition the script needs information about which camera was used. Running exiftool on a dng created from a RAW file gives rather generic information.

Code: [Select]

Make                            : Canon
Camera Model Name               : Canikon


[Danne]

Aha, but you can find out camera brand from the color matrix(courtesy Chmee)

Eos M starts with  ColorMatrix1>0.6602 and I think 700D and 650D as well

[dfort]

Eos M starts with  ColorMatrix1>0.6602

If the color matrix can identify the camera model (we already know it is a Canon camera) plus the video mode, it might be possible to code something that will automatically work with RAW files. Are you sure that you can determine the camera model from the color matrix? No two camera models have the same matrix?

I did a little more investigating and here's what I found on DNG's that were converted processed from a RAW original with raw2dng:

Code: [Select]

Unique Camera Model             : Canon EOS M
Color Matrix 1                  : 0.6985 -0.1611 -0.0397 -0.3596 1.0749 0.3295 -0.0349 0.1136 0.6512
Color Matrix 2                  : 0.6602 -0.0841 -0.0939 -0.4472 1.2458 0.2247 -0.0975 0.2039 0.6148

So the EOSM starts with Color Matrix 1 0.6985 but hey--it looks like the camera is identified in RAW files. The image size is easy enough to get but what about the video mode?

More goodies for experimenters--I'm posting dcraw "badpixels" files for all of the MLV video modes and standard resolutions in my bitbucket download area.

(I saw someone jumped the gun and downloaded some EOSM files that were not quite complete. They should all be complete now.)

[Danne]

Well there is only one color matrix when using raw2dng. Then there is exiftool putting in stuff in post . Actually I think dcraw uses the color matrix 2 as color matrix 1(numbers used in raw2dng). Think Chmee or Andy600 can explain this.

So to identify Color matrix 1 run raw2dng from command line and check the dng with exiftool or use this little script snippet and put it in a command file and run it next to a RAW file. The script uses the export path from MLP but I think you got that installed already.

Code: [Select]

#!/bin/bash
workingDir=`dirname "$0"`
cd "${workingDir}"
export PATH=~/Library/Services/MLP.workflow/Contents:$PATH
for FILE in `ls -A1 *.RAW *.raw 2>/dev/null`; do
#This little trick in the script makes raw2dng only print out only one dng from the file then exits
raw2dng "$FILE" | awk '{ print $1; exit }'
exiftool 000000.dng | awk '/Color Matrix 1/ { print $5; exit }' > color
mx=$(cat color)
#rename the dng file to the first color matrice number(cam identifier)
mv 000000.dng "$mx".dng
rm color
done
#will close and exit terminal
osascript -e 'tell application "Terminal" to close first window' & exit
exit 0

[dfort]

I created a bitbucket repository for prototyping, experimenting and general dealing with focus pixels in raw video.
https://bitbucket.org/daniel_fort/ml-focus-pixels

That way we can play with ideas for supporting legacy RAW video files, building the raw buffer focus pixel map files on the fly and whatever you want to try out and then share your results on this topic.

Thanks to Walter Schulz for the help with the 650D. I updated the dcraw files for that camera based on his feedback.