For me, scalers are only an occasional diversion from my daily grind....
For what it's worth, a 'blur factor' option is on my list of things to
add to y4mscaler; I imagine it would simply scale the size of the kernel
to lower the spatial cut-off frequency.
Right now, I think all the scalers out there tie the bandwidth of
their filtering to the decimation factor. All I'm really suggesting
is to decouple the two - allow the user to specify the cutoff of the
filter (or even passing in filter coefficients would be nice) and the
decimation ration separately. Then with no decimation y4mscaler could
be as a spatial lowpass filter to remove some noise, without changing
the size of the frame (since we only have a few options for DVD).
Also for what it's worth, the "cubicB" kernel in y4mscaler (corresponding
to a 'classic B-spline'), has a more gradual roll-off than the default
"cubic" kernel --- I imagine it will give a bit more smoothing on sharp
transitions. (I should go make a test page of impulse/edge responses.)
In my work, we usually want sharp (frequency-domain) transitions, but
I'm quite unclear at this point what sort of transitions look "good"
in images and video. Part of the problem is that images are so
routinely undersampled spatially, and I think the eye/brain actually
uses the aliasing constructively in some cases.
...
>But how to deal with chroma in interlaced frames - field-by-field?
>And just where exactly in space and time are the subsampled chroma
>pixels located? I'm never sure if 120 rows go with each frame, or if
>240 go with one frame and none with the other.
Concise answers to those questions: http://www.mir.com/DMG/chroma.html
Yep, that does it. Thanks.
>For efficiency, though, you might want to use fft-based convolution
>instead of direct/transposed form. Asymptotically the former is
>O(nlog n) rather than O(n^2) for the latter (or something like that;
>I'm being sloppy). There is a mjpeg-based scaler out there that does
>this in 1-D (I forget the name).
What is "n" up there?
In 1-D, isn't it:
O(n log n) to do an FFT/inverse-FFT, where n is the number of
samples; but O(nk) to do a convolution, where k is the length of
the kernel?
If that's the case, FIR wins, since it is linear in 'n'. In 2-D,
convolution becomes O((nk)^2), but won't the FFT square as well?
Convolution still wins.
I told you I was being sloppy! I was (inadvertently) thinking of the
(common for me) case of filter lengths on the same order as the data
(pulse compression), so n~=k. With small kernels you are quite right.
There are other (better) ways to do fft-based convolution than 1 big
fft: overlap & save or overlap & add methods do the computation in
blocks on the order of size k, so you have roughly n/k fft's of length
k (with some padding), which I guess is asymptotically O(nlog k).
Since k is not really going to be big, this still doesn't make fft's
attractive.
Anyhow, asymptotic performance isn't so important here, since a current
reasonable bound on n is 720. Would the constant factors further kill
the FFT's performance, or help?
I don't know where roughly asymptotic performance kicks in, that's
very implementation-specific. I suspect the offset in the performace
curve would further degrade the fft approach. Also, the
direct/transposed form approach is a lot easier to do strictly
integer. Forget I mentioned fft's....
Dan
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
