|
|
| rjisinspired |
| Posted: Jun 16 2010, 03:40 AM |
 |
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
My digital 8 has a widescreen viewing mode which I will be experiementing with. My goal is to produce fake HD from an SD camera.
I think I had heard of 640 X 336 or something in this neighborhood for doing a widescreen crop with square pixels. In my case I use a digital 8 so I'm guessing about 720 X 336 for rectangular pixels?
|
|
| stephanV |
| Posted: Jun 16 2010, 07:23 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
The easiest is to just to wait and see how much you can crop of. 640x336 is a bit wider than normal 16:9.
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| rjisinspired |
| Posted: Jun 16 2010, 07:16 PM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
Example video in Vdub from Digital 8
My digital 8 does record in a 16:9 format. I thought the LCD screen was only a guide since the viewfinder didn't reflect what the LCD screen showed. Bad thing about this is I have to always open up the LCD screen to get an idea on framing while shooting.
The resulting in-camera crop is 720 X 360 viewable video area, cropped from a 720 X 480 window. This is cool!! Now to pull off somewhat HD results will be a different story.
I also found Gunnar Thalin's deshaker made for Sony Vegas but it seems like a hassle to set up and you have to have other versions of Vdub for it to work, this somehow works where Vdub works alongside Vegas but the Vdub version that comes with the installer is a lower version.
Seems kind of complex to setup:
http://homepage.ntlworld.com/a.edmiston/deshaker.htm
Would had liked to use deshaker within Vegas to save a step but for now I'll have to render to AVI in Vegas then use the filter for deshaker in Vdub since this is all I know in how to use that plugin.
Each program has functions the other one doesn't have so I use both Vegas and Vdub, 50/50. |
|
| Jam One |
| Posted: Jun 16 2010, 09:24 PM |
|
|
Advanced Member
Group: Members
Posts: 580
Member No.: 25518
Joined: 8-May 09
|
| QUOTE (rjisinspired @ Jun 16 2010, 10:16 PM) | | ... The resulting in-camera crop is 720 X 360 viewable video area, cropped from a 720 X 480 window. ... |
I think you're ought to do some further checks concerning the geometry.
I suspect you need to:
1) add borders to make it 720x486;
2) resize to 720x540
3) crop to 720x405
Alternatively, if you prefer to keep the interlacing untouched:
1) resize to 648x480
2) crop to 640x360
...or something. As far as I can think of it right now...
Since your '16:9 -in- 720x480' is not supposed to have square pixels anyways; it is supposed to be just a Letterboxed NTSC-DV Widescreen. |
|
| rjisinspired |
| Posted: Jun 16 2010, 11:03 PM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
Thanks Jam.
I'm going to save both interlaced and deinterlaced copies. Also going to have both versions with and without the top and bottom bars.
The "486" I'm not understanding what the 6 pixel increase is about? About adding the borders, sounds like you mean an extra 3 pixels for the top and bottom?
If I upscale the height to 540 while keeping the 720 intact won't this elongate/stretch the height of the image? Then by cropping to the 405 for height, this removes the bars. |
|
| rjisinspired |
| Posted: Jun 17 2010, 05:40 AM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
I was reading about the "486" height and one of my questions now would be: Why didn't they just make the DV (D1) format fit the NTSC resolution of 720 X 486 in the first place? If the hardware displays 480 then cutting off the extra pixels would be no big deal.
Here I was always reading and believing that NTSC was 720 X 480 which I'm finding out it isn't
In Vegas I would have to write a custom template for 486 since it is 480 by default. I think I will try this on this next project. So next time I should just change the 480 to 486 next time before capturing?
http://rjschat.dyndns.org:8080/Paranoha/AP...S/VDUB/ntsc.jpg
Someone on another forum said it's better for a program or hardware to cut off 3 pixels top/bottom then it is to increase them, going from 480 to 486. which brings up the issue of resizing.
Another issue was that of some blurring by resizing to the 6 pixels. I have seen this with still images, when I was a photographer, where one little nudge of a pixel value could distort and/or blur an image, warp it. Sounds logical to me since all video is is a bunch of still images crammed together.
Now in the example by Jam One, of bringing up the height of 486 to 540, I may be confused or not sure. Make a 3 pixel border for the bottom and top of the video while leaving the sides of the video alone, i.e. instead of just upscaling the extra pixels just add the border to make the height 486? Adding a border wouldn't be the same as resizing since it's only extra data added on to an already existing video?
Then....
Going from 486 to 540 while keeping 720 a constant will make the rect pixels more squared while keeping the full 720 size as opposed to going from 720 down to 640 horizontally and producing a slightly smaller image? Am I sort of on the right track here so far?
Then the crop for the height of 405 is for the removal of the bars? 135 pixels / 2 - top/bottom which would be 67.5 pixels, or 68 rounded, for the top and bottom bars. That is if I remove the bars. |
|
| stephanV |
| Posted: Jun 17 2010, 07:00 AM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| QUOTE (rjisinspired @ Jun 17 2010, 07:40 AM) | | I was reading about the "486" height and one of my questions now would be: Why didn't they just make the DV (D1) format fit the NTSC resolution of 720 X 486 in the first place? If the hardware displays 480 then cutting off the extra pixels would be no big deal. |
That's because codecs like to work with multiples of 16. By the way, standard NTSC is not really 720x486 either but the real active picture is 711x486.
I would accept a small AR error though. It is not sure that your camera actually respects ITU standards anyway.
If you are really interested this is a nice read -> http://lipas.uwasa.fi/~f76998/video/conversion/
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| rjisinspired |
| Posted: Jun 17 2010, 10:02 AM |
|
|
Advanced Member
Group: Members
Posts: 1256
Member No.: 20008
Joined: 12-October 06
|
Thanks Stephan.
|
|
| Jam One |
| Posted: Jun 17 2010, 11:33 AM |
|
|
Advanced Member
Group: Members
Posts: 580
Member No.: 25518
Joined: 8-May 09
|
| QUOTE | | sounds like you mean an extra 3 pixels for the top and bottom? |
No, pardon me, 2 pixels at the top and 4 at the bottom (or vice versa) -- otherwise the field order will change, and this most probably will be BAD.
The idea was: 720x486 D1 goes to 4:3 screen ratio with correct geometry. While 720x480 DV does not.
And 4:3 corresponds to either 720x540 or 640x480.
All this is needed to restore the Square Pixel.
Update: Taking into account stephanV's info above regarding the NTSC frame's active area, one may wish to consider to check the alternative routine (assuming your video is DV-NTSC):
Resize source 720x480 to 712x480; add borders to 720x486; resize to either 640x480 or 720x540 - whatever suites your taste best.
---
Historically, the 32x32 blocks were needed by hardware overlays in computer's videocards. If a video image was not dividable by 32, CPU used to get overloaded with the work videocard was supposed to do.
You may remember - there were days when they used to sell "MPEG2 video accelerators" as a separate hardware extension card. MPEG1 acceleration chip had been built into the the video adapter since Virge-DX and S3-Trio cards (as I recall).
This very "acceleration" was hard-bound to the overlay surface and needed the image to be dividable by 32 due to its architecture.
Later models learned to accelerate MPEG2 via overlay to the extent you didn't need to buy extra hardware, and became "happy" with divisibility by 16.
This post has been edited by Jam One on Jun 30 2010, 01:18 PM |
|
