Opening RAW in Avisynth with Sashimi plugin

Started by tin2tin, June 07, 2013, 11:03:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

tin2tin

I came across a plugin which deals with all sorts of RAW files: https://sites.google.com/site/ourenthusiasmsasham/soft#TOC-Sashimi
The docs are quite detailed of various raw formats and also on bitrate conversion(source included too).

This shows some resemblance with the original image, but I haven't found the correct way to open the files yet.
LoadPlugin("Sashimi.dll")
RawReader("M03-1651.RAW", "RGB", 1280,720,packing="14")


There is a packing parameter, but I don't know the "packing" of Magic Lantern Raw. Would be great if Avi/Vapour-synth could import those files for further correction.
Avisynth is 8 bit only, but Vapoursynth supports higher bitrates too.

The thread on doom9.org: http://forum.doom9.org/showthread.php?t=154830

tin2tin

Here's a bit of the docs:
Quote
Common parameters

string filename : The path (both relative and absolute are okay) to the file to be read or written to.
No default, must be specified.

format : This specifies the format of the raw file. Options are:

"RGB" or "rgb" - 24 bits per pixel (3 bytes) in order. When reading a raw file, the output of the filter is an RGB24 clip.
"BGR" or "bgr" - 24 bits per pixel (3 bytes) in order. When reading a raw file, the output of the filter is an RGB24 clip.
"RGBA" or "rgba" - 32 bits per pixel (4 bytes) in order. When reading a raw file, the output of the filter is an RGB32 clip.
"ARGB" or "argb" - 32 bits per pixel (4 bytes) in order. When reading a raw file, the output of the filter is an RGB32 clip.
"BGRA" or "bgra" - 32 bits per pixel (4 bytes) in order. When reading a raw file, the output of the filter is an RGB32 clip.
"ABGR" or "abgr" - 32 bits per pixel (4 bytes) in order. When reading a raw file, the output of the filter is an RGB32 clip.
"Y8" or "y8" or "GREY" or "grey" or "GRAY" or "gray" - 8 bits per pixel (1 byte) greyscale. When reading a raw file, the output of this filter is a YV12 clip, with all colour information set to neutral. Native Y8 content is not presently supported in AVISynth (planned feature for v2.6, current version at time of development is 2.58).
No default, must be specified.
packing : A packing format string, FEATURE IN BETA - PLEASE REPORT ISSUES.
The format is a list of of triples, optionally with whitespace, separated by semicolons. Each triple (the second and third numbers are optional) spells out the total number of bits, then inside that total, how many to skip, and how many to use, ie:
"total:skip:use; total2:skip:use2; etc".
So in a total of 12 bits, if you want to skip the first 3, and use the next 5 (ignoring the last 4), you would use "12:3:5" - that's XXX4 3210 XXXX to give the bit positions.
Because AVISynth only keeps / represents 8 bits, the "use" value will be treated as 8 even if more is specified. More can be specified because it makes specifications much easier to write, and because future versions of AVISynth might allow more.
The packing resets at the end of every row, so trailing bits are skipped over and the next row starts at the next full byte.
Any packing specified for a planar format will be applied equally to each plane, not to the elements of the plane in order, so if you have, for example, 12-bit luma, but 8-bit chroma, you will need to read or write your file in multiple passes. See Read Exotic and Write Exotic.
Examples:

16-bit "High Colour" is packed as 5 bits of red, then 6 bits of green, and 5 bits of blue. The packing string is "5;6;5", equivalent to "5:0:5; 6:0:6; 5:0:5". Format "RGB".
10-bit v210 raw format would be "12:2:10; 10; 10" (the repeating happens for free). Format UYVY I think - I can't obtain a sample file. Use RawReadInterleaved("UYVY") or RawReadInterleavedUYVY() or RawWriteInterleaved("UYVY") or RawWriteInterleavedUYVY().
16-bit video is not a good example - you can just load it without a packing string and use TurnRight().AssumeFrameBased().AssumeTFF().SeparateFields().SelectEven().TurnLeft(). It may even be faster - you'd have to benchmark it. If you want to use it, say packing="16:0:16" or "16:0:8" - they're equivalent.
Default = No string, or "". Packing defaults to 8-bit samples.
filehead : When reading, it is the length (in bytes) of a file header to skip over. When writing, Sashimi will insert this many null bytes at the start of the file.
Default = 0.

framehead : When reading, it is the length (in bytes) of a a frame header to skip over. When writing, Sashimi will insert this many null bytes before each frame of data.
Default = 0.
So maybe it is just a question of how the ML RAW is packed and specify it for the plugin. Is there anywhere I can find this info?

deleted.account

Ok, so I love Avisynth and use it a lot, including the LSB/MSB stacked for 16bit. But got to say I think that it's the wrong tool for the start of a workflow better for the latter stages, like temporal noise reduction, luma sharpening, upscaling to 720P and 1080P, interframe and motion blur etc in YV24 and YV12 then going to final encode.

There is a debayer plugin for Avisynth, doesn't appear to offer best quality, http://forum.doom9.org/showthread.php?t=132238 and the sashmi plugin I think can output stacked LSB/MSB for 16bit processing in avisynth.

But unless using dither tools for 16bit stacked LSB/MSB, there are many filters that don't work in RGB or limited number at YV24, are only 8bit processing so you'll have to keep jumping in and out of 8bit to stacked 16bit to 8bit to use certain filters.

Processing is very slow, very little is GPU assisted and 16bit LSB/MSB processing can be slow and unstable.

I've already looked at this a bit, I know I lot of what I'm saying is negative and sure probably some use for Avisynth from the outset rather than latter stages but feel avisynth is a predominantly YCC tool and filters with little support for 32bit float linear processing available in other free tools that can be used on the CLI for batching like UFRaw, Rawtherapee and Darktable.

Looking forward to you pursuing this, as when I looked at it a few weeks ago I basically thought there's better to ways to do the raw development and instead feed raw developed image sequences using Darktable into Avisynth for the reasons mentioned above to process before encoding.

Good Luck. :-)

tin2tin

Thank you for your insights. Like you I love Avisynth, but it is probably better to accept it's limitations for now.