Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
16th January 2005, 23:00 | #1 | Link |
Registered User
Join Date: Dec 2004
Posts: 16
|
Increasing Size and Apparent Resoluion!?
OK - here is a good one for all of the pros on this board. Bond I couldn't figure out where to post this so if you need to move it please do!
A while back there was a lot of work using fractals to increase apparent resolution bumping up the physical size of a scan. So is there any application out there that can take a Standard Def raw capture and convert to High Def with enough enhancement so it looks better than the original lower def capture? I certainly understand that it is physically impossible to tweak something that isn't there, but some people where trying to come close by using fractals and extrapolation. For instance, taking a progressive VGA letterboxed capture produces a standard frame of 648 x 368 pixels. You can easily resample that up to High Def at 1280 x 720 pixels BUT the apparent resolution stays at the lower level because there is no extra pixel information added - just an expansion of what exists. If there was some algorithm to tweak standard video coming from a direct source like the Cannon XL1, it would seem that this resulting "pseudo" high def would be much better than the original frame even though it would certainly NOT come close to the output of a native high def camera like the Panasonic AJ-HDC27. Yes I know there are line doublers / quadruplers out there that work with interlaced video but that doesn't have any application to this. This would be a cleaning and sampling process that is part of the compression. Any takers on this? Is this already out there? Not yet? On the way? In the worst case, any ideas on where to go to find this or a compression pro here whom I might be able to work with? BTW this it is the polar opposite of my last question on Joining 3GPP files. That is still hanging because of a problem with the AMR codec, so if anyone here can help on that - the discussion is here. Thanks guys - any help is appreciated! Last edited by tomb2; 17th January 2005 at 06:26. |
17th January 2005, 01:56 | #2 | Link |
Buffyverse Potternut
Join Date: Oct 2003
Location: U.S.A.
Posts: 72
|
The closest thing you're ever likely to get is Didee's IIP (Integrated Image Processor) script and anything built from it in the Avisynth Usage forum. Any input source can be upscaled and processed with a very intricate combination of Avisynth filters designed to remove noise and increase apparent detail, and output at almost any arbitrary size. To give you an idea of exactly how much work IIP does, with the settings I use it averages 0.8 FPS on a 2.4GHz P4--meaning it would require a hypothetical 72GHz P4 to process a 24FPS 720x480 stream in real-time! Since I'm a visual quality nut anyway I use it to clean my 720x480 analog NTSC captures of stuff that isn't on DVD, from cable or old media like laserdisc, VHS, and Beta, and upscale to a 1:1 PAR of 768x576 prior to encoding. They look fantastic on my 100" 800x600 projector system, much much better than the original unprocessed streams. You could upscale to a true HD res if you didn't mind the considerable added encoding time and extra storage space--but the processing time would not be increased, because IIP is already working internally at essentially HD res before outputting whatever res you specify.
As for such a process that's made part of the compression, processing and compression are two different steps and there's nothing I can see to be gained by integrating them except less flexibility. You'd still have to do all of the same taxing calculations to arrive at the processed and scaled image, and you'd still have to compress that image instead of the original source resolution to preserve the apparent detail enhancements. There are alternative schemes such as compressing the original unenhanced and non-upscaled image and trying to layer an additional stream on top of that to represent an approximation of the difference between the original image and the upscaled one, perhaps using wavelets, but this is a Rube Goldberg approach that would probably not save more space than just compressing the upscaled image itself, would definitely have less detail than just compressing the upscaled image itself, and would require a huge amount of unnecessary additional processing to generate during the encoding process and to utilize during the decoding process. It just doesn't seem useful and practical to do it that way. Last edited by Sergei_Esenin; 17th January 2005 at 02:13. |
17th January 2005, 02:52 | #3 | Link |
Registered User
Join Date: Dec 2004
Posts: 16
|
Sergei thanks for the tip and thoughts I will definitely take a look at Didee's IIP. But your jump was pretty small compared to what I am trying. It should be an interesting experiment! I actually have some HD raw scans from 35mm negative (it doesn't get any better) so when I get around to it I could do some pretty interesting comparisons as far as how good the "pseudo" looks compared with the same SD and HD files. In the case that I have to deal with now though, the original was shot SD progressive video and I need HD so that will be interesting too!
EDIT: WOOOO! This is going to take days to sort out! Unless I am at the wrong thread, there are pages and pages of developing commentary on iiP but so far no script, plug-ins or conclusions. I will continue to read and search, BUT it looks like iiP is more for damage recovery for highly compressed MPEG2s as found on DVDs and satellite feeds. I am starting out with clean source material in its raw format - it is just a quarter the res it should be. What I was hoping for was more of a frame rebuild based on pixel interpolation and the 400% increase in screen size the algorithm would have to work with. What I am hoping to find probably doesn't exist, but I will let you know! Last edited by tomb2; 17th January 2005 at 04:22. |
17th January 2005, 04:44 | #4 | Link | |
Buffyverse Potternut
Join Date: Oct 2003
Location: U.S.A.
Posts: 72
|
Quote:
Bear in mind that much of the improved image quality IIP provides isn't just from the upscaling, it's from all the denoising and detail enhancement the filters provide, so even if you specify an output resolution identical to the input resolution there will be visible improvements. Cleanness of source material is irrelevent, since all unprocessed video contains noise, unoptimized contrast, etc. This is probably *especially* true if your video really is "raw." While originally intended for a more specific purpose, it's become recommended for almost any video processing task where quality of output is more important than the time it takes. And if you keep digging through the threads, you'll find the latest version of the script. There's also a seperate thread for the IIP/LimitedSharpen combination script if you prefer a more advanced video sharpening. It takes a lot of time to process video with IIP, but the results are worth it. Last edited by Sergei_Esenin; 17th January 2005 at 05:05. |
|
17th January 2005, 12:19 | #5 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
I bashfully admit that gathering all relevant information about iiP requires thorough reading of the complete thread. At different stages of updating the function, I wasn't 100% sure that everything was OK, and left the older function revisions in the thread, for reference. And the description of new version's additional parameters is cluttered over the thread in the same way. (But if you run a pass with default settings, then you have more than enough time to read the whole thread ... )
Although we all know it already, let me remind once more that we cannot invent new information into the source by upsizing and whatever processing. But we can go ahead and (try to) achieve a better *representation* of the information that *is* there. As far as my scripts are involved, the possibilities for enhanced upsizing are: - iiP (actual version is on this page) - faster version of iiP (here, still 'inofficial', but should be OK. Remember to set "subpel=0.0" with this version!!) - LimitedSharpen (here), eventually together with BlindDeHalo|2 - waiting for LimitedSharpen-EX However, all of these functions are based on Lanczos resizing, as that's the most "precise" resizer we've currently available. One might want to give a go on EDI/fastEDI upsizing, too. But personally, I always found also artefacts introduced along with the better upsampling, be it (fast)EDI, SangNom or LSresize, or (rotate)doubled TDeint ... so I stepped away from it (for now). IMO, traditional processing of Lanczos(4)Resize() is sufficient for any upsizing up to 200%~250% /per axis. Speed & other considerations: iiP is pretty slow indeed. But then, if the source is rather clean, it can be sped up quite a bit: if noise and/or compressability is not an issue, then the denoising (by the slow PixieDust) can be completely ditched out, or be replaced with a faster denoiser (deactivate Pixie in iiP through "duststrength=0.0", and optionally use your own denoiser before calling iiP). Also, the deringing routine might not be needed on clean enough sources. Though it works rather good, it's somewhat slow as well, and eventually can get deactivated (by "dering=-1"), too. Lastly, the 'inofficial' iiP version replaces the internal performed SSX-Sharpen by LimitedSharpen. This requires much less supersampling - infact the 2nd SS will not be done at all, and the refinement is done on the 1st SS instance. This helps increase performance noticeably. Depending on how new the used version of the MaskTools is, the iiP script has to be searched for all instances of the "useMMX=true" parameter, which must be deleted when using recent MaskTools versions. (It wasn't really needed for older versions, either ...) LimitedSharpen itself is another possibility. It won't do as much enhancement as iiP on detail contrast, but will do a rather nice job on detail refinement. This processing might already be enough, depending on the source. LS won't do any denoising or deringing at all. That's the job of Quote:
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
|
17th January 2005, 12:45 | #6 | Link |
Registered User
Join Date: Dec 2004
Posts: 16
|
Didée - thanks for some great posts and information! I had no clue how powerfull Avisynth was - I had just used it as a frame server. I am learning a lot, but for noobs without experience in this area, it is pretty hard to follow. For instance you say above "denoising (by the slow PixieDust) can be completely ditched out, or be replaced with a faster denoiser." OK, sounds good. But what faster denoiser? In other words, this is pretty rough on someone who is just coming to this and doesn't have enough knowledge yet to understand your references. But that will come as I read more and you continue to post. I appreciate the work you are doing - is sounds like your script may be the conterpart to what would cost $10,000 in hardware!
As far as my original post, there was some work three years ago(?) where the processing actually WAS inserting new informaiton and that's what I was originally asking about. I seem to recall the name was Images Incorporated(?). They had or were working on a system for increasing the apparent detail of images using fractal methods, as well as fractal and JPEG compression and expansion. Last edited by tomb2; 17th January 2005 at 13:24. |
17th January 2005, 12:52 | #7 | Link |
Registered User
Join Date: Nov 2001
Posts: 9,770
|
moved to avisynth
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora | Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free |
Thread Tools | Search this Thread |
Display Modes | |
|
|