JpegSource – advanced JPEG decoder for Avisynth 2.6

[filler56789]

Hummm, would it be "worth the effort" to (somehow) force a conversion to YUY2 or YV**, for dealing with «uncommon» types of chroma subsampling?

Example: http://forum.videohelp.com/attachmen...2-2x1-2x1).jpg

OT: ImageSource() works fine with RGB JPEGs (even the weirdest ones )

[SEt]

I see nothing special in that JPEGs: usual YV12.
As for conversions – see second example in first post. For unsupported chroma just replace UToY8/VToY8 by calls to JpegSource for planes 1 and 2.

JpegSource also works fine with RGB JPEGs – no problems so far.

[Reel.Deel]

Originally Posted by SEt

I see nothing special in that JPEGs: usual YV12.

Actually, filler56789 linked to a 4:4:0 encoded JPEG.

-----------

@filler56789

To convert 4:4:0 JPEGs to 4:4:4 (YV24) do something like this:

source = "image.jpg"

Y = JpegSource(source, channel=0)
U = JpegSource(source, channel=1).Spline36Resize(Y.width, Y.height)
V = JpegSource(source, channel=2).Spline36Resize(Y.width, Y.height)

YToUV(U,V,Y)

#ConvertToRGB24(matrix="PC.601") #Only needed if you want RGB output

Since Avisynth does not support 4:4:0 converting to YV24 is the better choice, with YV12 and YV16 you'll loose half the horizontal resolution in the chroma planes.

[SEt]

Oh, indeed it's actually 440. My other tool looked only at maximum sampling (2x2) and incorrectly guessed that it's 420. JpegSource detects this correctly, but I guess it also can get some more intellect in next version in case someone decides to use such redundant sampling with evil numbers like 3.

[filler56789]

@Reel.Deel — your recipe works ~ many thanks 4 that.

Spline36Resize()

In this particular case at least, shouldn't PointResize() be sufficient and adequate?

[SEt]

Originally Posted by filler56789

Spline36Resize()

In this particular case at least, shouldn't PointResize() be sufficient and adequate?

It all depends on how much you treasure chroma. In case you don't care (like many JPEG decoders) – yes, PointResize is enough.

[filler56789]

Originally Posted by SEt

It all depends on how much you treasure chroma. In case you don't care (like many JPEG decoders) – yes, PointResize is enough.

Thanks for the lesson, sir, I really need to drink more coffee

Regarding the Wiki...... I think it should include more "real-life examples" ---

--- based on the last script posted by Reel.Deel, here is what works for a "pathological" RGB file created w/ cjpeg.exe:

source = "zRGBsamplefile.jpg"

G = JpegSource(source, rec=0, channel=1)
R = JpegSource(source, rec=0, channel=0).Spline36Resize(G.width, G.height)
B = JpegSource(source, rec=0, channel=2).Spline36Resize(G.width, G.height)

MergeRGB(R, G, B, "RGB24")

As you can see, it's rather convoluted when compared to:

ImageSource("zRGBsamplefile.jpg", fps=25, end=249)

[Reel.Deel]

Originally Posted by filler56789

Regarding the Wiki...... I think it should include more "real-life examples"

When I get some time I'll gladly add some more examples. One good thing about the Wiki is that anyone can add useful information.

Originally Posted by filler56789

--- based on the last script posted by Reel.Deel, here is what works for a "pathological" RGB file created w/ cjpeg.exe:

source = "zRGBsamplefile.jpg"

G = JpegSource(source, rec=0, channel=1)
R = JpegSource(source, rec=0, channel=0).Spline36Resize(G.width, G.height)
B = JpegSource(source, rec=0, channel=2).Spline36Resize(G.width, G.height)

MergeRGB(R, G, B, "RGB24")

That example is wrong. The following examples are correct (and identical).

Simple:

JpegSource("RGBimage.jpg")
MergeRGB(last, UToY8(), VToY8(), "RGB24")

Convoluted:

JpegSource("RGBimage.jpg")

R =  last
G = UToY8()
B = VToY8()

MergeRGB(R,G,B, pixel_type="RGB24")

Originally Posted by filler56789

As you can see, it's rather convoluted when compared to:

ImageSource("zRGBsamplefile.jpg", fps=25, end=249)

You know you can always make a function and then autoload it.
Something like this:

function JpegSourceRGB(string file, int "rec", int "length", float "fps_num", int "fps_den")
{
JpegSource(file=file, rec=rec, length=length, fps_num=fps_num, fps_den)
MergeRGB(last, UToY8(), VToY8(), "RGB24")
}

Then use it like this and be done with it:

JpegSourceRGB("RGBimage.jpg")

[filler56789]

Originally Posted by Reel.Deel

That example is wrong.

It does work for the file I have, so how on Earth can it "be wrong"?

The following examples are correct (and identical).

Simple:

JpegSource("RGBimage.jpg")
MergeRGB(last, UToY8(), VToY8(), "RGB24")

OK, if I try to open the script above in VirtualDub,
I receive the following error message:

Avisynth open failure:
JpegSource: unsupported multi-channel configuration - use one channel mode

Conclusion: don't assume all RGB Jpeg files are "4:4:4".

More sample files:

http://forum.videohelp.com/attachmen...ene421-ycc.jpg

http://forum.videohelp.com/attachmen...ene421-rgb.jpg

http://forum.videohelp.com/attachmen.../Nene3xRGB.jpg

http://forum.videohelp.com/attachmen.../Nene3xYCC.jpg

[SEt]

^ these are good examples of "evil" JPEGs.

While I might support passing 444 RGB JPEGs to Avisynth as RGB24, here you'd have to do the conversions yourself. The idea of this source filter is to provide the actual data encoded in image without any colorspace conversions or resizes (that are usually really poor quality in decoders), and Avisynth colorspace support is quite limited.

Reel.Deel's idea is correct: you can write script function that does required resizes automatically. Just get max width and height and resize all components to them. (Well, in reality it's a bit more complicated as you would also need to account for components cut in the middle of sampling block.) Is it RGB, YUV or some other colorspace file you's have to know yourself, as there is no way now for plugin to pass such metainformation to script.

[wOxxOm]

Originally Posted by SEt

there is no way now for plugin to pass such metainformation to script.

FFMS2 sets global variables for that. You can also make some auxiliary function(s) that return this metainfo.

[Reel.Deel]

Originally Posted by filler56789

It does work for the file I have, so how on Earth can it "be wrong"?....
....Conclusion: don't assume all RGB Jpeg files are "4:4:4".

I did not understand what you meant with "pathological RGB" and you did not mention that it was not a 4:4:4 RGB encoded JPEG so I assumed it was a 4:4:4 RGB encoded JPEG.
Now that you uploaded some examples I can see they're not 4:4:4 and indeed the script you posted is correct.

[SEt]

Global variables are not a solution (for example, there could be several sources with different properties). We need real clip metadata support.

[wOxxOm]

Originally Posted by SEt

Global variables are not a solution (for example, there could be several sources with different properties). We need real clip metadata support.

Even with global variables you can do it I think.

JpegSource("1.jpg")
csp1 = JPEG_SOURCE_CSP
.......
JpegSource("2.jpg")
csp2 = JPEG_SOURCE_CSP
.......

Of course an auxiliary function would be even better:

JpegSource("1.jpg")
csp1 = JpegSourceInfo("1.jpg",info=0)
dpiX = JpegSourceInfo("1.jpg",info=1)
dpiY = JpegSourceInfo("1.jpg",info=2)
......

[SEt]

I don't think there is any guaranteed ordering of execution in Avisynth language so you can you it in such imperative way. Also, global variables are evil.
Auxiliary functions would work, but it's still bad extremely redundant way of getting information.

[wOxxOm]

Welp, that's the reality of AviSynth.

[StainlessS]

Here some observations about order of execution in non MT versions of Avisynth (no idea about MT versions):
http://forum.doom9.org/showthread.ph...54#post1594454

Here some posts starting with Filker's post about extracting jpeg EXIF info
http://forum.doom9.org/showthread.ph...41#post1587641

EDIT: A couple of functions added to RT_Stats might assist if modifying linked scripts,

RT_FindStr(String S,string Substr,bool "Sig"=True,int "Pos"=1)
 Finds unnamed string Substr in unnamed string S.
 Optional bool Sig: Default=True, does case significant comparison, insignificant if false.
 Optional int Pos: Default=1, is start position in string S to find string Substr. If Pos smaller than 1 or greater than length of string s,
  then will return 0, Not Found.
 Returns position (1 relative) of found string within the FULL LENGTH string S, or 0 if not found.
 Differs from Avisynth FindStr in Sig and Pos args and in that if either string S or string Substr is "" then will ALWAYS return 0, 'Not Found',
 Avisynth FindStr always returns 1 if SubStr="" even if S is also "".

RT_TxtFindStr(String S,string FndS,bool "Sig"=True,int "Pos"=1,int "Start"=0,int "Lines"=0)
 Finds unnamed string FndS in unnamed multi-line text string S, starting at line 'Start' and searching 'Lines' number of string lines.
 S: is a multi-line text string, ie a newline [CHR(10)] separated list of strings.
 FndS: is a single string and will be considered terminated early at the first carriage return [Chr(13)] or newline [Chr(10)],
 carriage returns and newlines will not be findable using this function.
 Sig: Default=True, does case significant comparison, insignificant if false.
 Pos: Default=1, is the character start position in an individual line of the multi-line string S to start searching
   for the FndS string. Allows you to skip search on first Pos-1 characters within all single lines of multi-line string S.
   If Pos less than 1, then will return -ve number (usually -1), Not Found.
 Start: Default 0, is the 0 relative starting line where the searching begins within the multi-line string S.
 Lines: Default 0(all lines). Number of lines in multi-line string to seach, starting at line 'Start'.
 A -ve return is 'Not Found'. On success returns the line number of the first instance of a found string in the Start and Lines
  range of lines. An empty "" FndS will always return -ve result, ie Not Found (as will all errors).
 see RT_TxtQueryLines, to inquire number of single lines in a chr(10) separated multi-line string.
 see RT_TxtGetLine to extract a single line from a multi-line string [without trailing Chr(10) or Chr(13)].
 NOTE, Character position 'Pos' is 1 relative whereas multi-line line 'Start' index is 0 relative.

RT_FileFindStr(String FileName,string FndS,bool "Sig"=True,int "Pos"=1,int "Start"=0,int "Lines"=0)
 Finds unnamed string 'FndS' in 'FileName' text file, starting at line 'Start' and searching 'Lines' number of text lines.
 FileName: Name of a file containing text to search.
 FndS: is a string and will be considered terminated early at the first carriage return [Chr(13)] or newline [Chr(10)], carriage returns
 and newlines will not be findable using this function.
 Sig: Default=True, does case significant comparison, insignificant if false.
 Pos: Default=1, is the character start position in an individual line of text to start searching for the FndS string.
   Allows you to skip search on first Pos-1 characters within all lines of text.
   If Pos less than 1, then will return -ve number (usually -1), Not Found.
 Start: Default 0, is the 0 relative starting line where the searching begins in the text file.
 Lines: Default 0(all lines). Number of lines text to seach, starting at 'Start' line.
 A -ve return is 'Not Found'. On success returns the line number of the first instance of a found string in the Start and Lines
  range of lines. An empty "" FndS will always return -ve result, ie Not Found.
 see RT_FileQueryLines, to inquire number lines in a text file.
 see RT_ReadTxtFromFile to extract a range of lines from a text file.
 NOTE, Character position 'Pos' is 1 relative whereas multi-line line 'Start' index is 0 relative.

[foxyshadis]

SEt, I know it's been a while, but would you consider releasing this as source+lib (32 & 64)? I'd like to make an edition that works with imagesequences, like ImageSource, and with MJPEG videos, and maybe a native VS binding as well.

As an aside, this reconstruction technique should work almost identically for DV, if it was tweaked for that, right? Or even the I-frames of MPEG-1 and -2, all basically the same tech. That'd be an interesting way of potentially improving old videos, because the difference is definitely visible.

[SEt]

I'm not planning to release it as source or lib atm. No 64-bit version yet at all as there is plenty of x86 asm there. Will likely add sequence import later. MJPEG probably can be losslessly converted to JPEG sequence so unlikely to be implemented. The last thing I'd want is native VS bindings...

No idea about DV, but the technique can't be directly applied to MPEG-1/MPEG-2 (I would definitely like to have such MPEG decoder though).

[ajp_anton]

Any plans on making a 64-bit version of this? Loading and transforming lots of big images needs more memory...