mlange-42 / chrono-photo Goto Github PK

In addition to processing image series, allow direct processing of video files.

Problem: Didn't find any pure rust library for decoding videos. There are bindings for GStreamer, but that would probably make the deployment process more difficult.

Possible crates (bindings)

• gstreamer
• ffmpeg
• libVLC

Possible crates (pure rust)

• ?

• Currently: Outliers are determined by their absolute distance from the median (in 3/4 dimensions)
• Proposal: Calculate distance, relative to some non-parametric spread characterization, e.g. inter-quartile range (range between 25th and 75th percentile)

Add option to use only a subset of matching input files, by range (e.g. use only 10th to 30th image).

Would also be necessary to create "chrono-videos".

Provide a command line option to allow for a grey-scale image as a mask

Trying to run it on Mac:

On OSx, from debug dir, and after generating test data, it fails to get second image of the folder:
./chrono-photo --debug --pattern test_data/generated/image-000*.jpg --output out.jpg

error: Found argument 'test_data/generated/image-00001.jpg' which wasn't expected, or isn't valid in this context

There's no problem with paths, as when I pass a single image as pattern argument, it builds OK the out.jpg file (generating same image as input, of course...):
./chrono-photo --debug --pattern test_data/generated/image-00000.jpg --output out.jpg

Maybe some problem with patterns and OSX?
Compilation worked without problems.

blend-outlier-<min>-<max> for option --mode: linear blending between background and outlier depending on distance from median.

Allow for optional sample-based pixel median calculation.

For very huge numbers of input files (thousands to ten-thousands), it may be useful to restrict median and quartile calculations to a sample.

Implement the primary/default algorithm based on outlier detection.

Similar to #22, but use "surrounding" instead of random frames.

Panics when the path / a folder in the search pattern contains -.

• Recording videos
• Preparing video material
• Creating chrono-photos
• Creating chrono-videos

When processing to video/image sequence, it may appear that only very few frames (e.g. 2) are used. Of course, outlier detection won't work here.

Try to find a solution.

On OSX (not tested in Windows), crashes if output contains no dir path.
Some versions before it has no problem with it:

./chrono-photo --pattern "test_data/generated/image-000*.jpg" --output test.jpg

Temp directory: "/var/folders/bd/4nwq6clx0px9w6t5kgj70gl00000gn/T/chrono-photo"
Time-slicing 25 images
Total: 27742 kb in 192 files
Processing 192 time slices
Saving output... 
thread 'main' panicked at 'Unable to create output directory "": Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:542:9

Instead, putting --output ./test.jpg works, but it's not very common. Also works OK puttin a dirname, because create it.
Problem is somewhere before create outputdir, should check if parent is empty or something like that.

Applies to compression of temporary time-slice files.

Particularly tiff...

Seems complicated to realize via generics (e.g. num_traits::PrimInt), as only u8 and u16 should be supported.

Requires help from someone with more Rust experience.

Provide the possibility to parse options from a file rather than from command line arguments

Syntax would be the same, but without the executable's path and '^' for line breaks.

I got that error at one of the executions while processing a 540 image set.
Don't know if it's really a bug, or some problem with filesystem or temp directory...

0.4.2
Processing 540 time slices
████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 185/540
thread 'main' panicked at 'called Result::unwrap()on anErr value: Custom { kind: InvalidInput, error: "corrupt gzip stream does not have a matching checksum" }', src/streams.rs:188:28

Multi-threading can be applied for time-slicing as well as actual processing.

• Time-slicing

For time-slicing, it is only possible to process image rows in parallel, while processing images in parallel is not (easily) possible, since rows are successively appended to temporary files.

The speed gain may be limited, particularly for low resolution images. Further, parallel writing to streams may be a bottle neck?

• Video frames

Calculating frames of a video is simple.

However, is increases memory usage.

• Camera shake analysis

Parallelize over frames. Increases memory usage.

• Processing

Processing itself could by parallel over image rows. However, this would require loading multiple temporary files into memory at the same time, which could be a problem for series of a really high number (really really high!) images.

Alternatively, processing of pixels in the same row could be done in parallel. The gain would be highest for large images, and particularly for large amounts of images in a series.

It should be principally possible to correct for camera shake.

Would be computationally expensive, but should be possible.

Probably, pre-processing of all images is required before any time-slicing or processing.

Currently, images are converted to temporary time slices row by row. E.g., the first temp file contains the first row from every image.

The amount of pixels from each image going into one temp file could be user-controlled, to

• increase: for better compression, less reading operations, and less temporary files
• decrease: for less RAM usage during actual processing (for processing really huge numbers of images; > 100k!)

Should create a series of output images, each created from a range of input images as explained in issue #9.

E.g. 1st output from images 1..10, 2nd from images 2..11, etc.

Frames in the beginning and the end of the sequence could be "faded", to produce less apprupt starts and ends. Could also be used for fading-out "movement trails".