#Standard Frame Size
16 messages in this thread
Can anyone point me to the various image sizes and/or formats that would be
best to interface with the Amigas on? Been using 640 x 480 24 Bit JPEGs, but
I'm not sure that is optimum for comparison purposes on an NTSC source
conversion. That size is one of the PC mode standards, but what size would be
most representative for a 24 bit JPEG for the Toaster systems? Thanks.
Vince
Vince,
The 640 X 480 PC format is probably the closest and most commonly used for
conversion for NTSC display. However, Toasterpaint (and the resulting
Framestore or RGB files) have a different aspect ratio than your 640 X 480
files. You will need to first convert from Jpeg to standard 24bit RGB files,
then change the size and aspect ratio to 752 X 480. The software that will
handle the task on the Amiga is called Art Department Pro (ADPRO). It will read
your JPEG files directly and allow you to set the display resolution to the new
attributes needed before saving as a standard 24 bit RGB file that can be
loaded into Toasterpaint. You would then render the file to the Toaster's
framebuffer, and save the file as a framestore from the switcher interface. The
latest version of ADPRO will also allow you to save your files in Toaster's
framestore file format, thus saving you the step of loading first into
Toasterpaint, but the picture qulaity in the two procedures will be the same.
Hope this helps.
Regards
Frank
Frank, thank you for the information on this one. As I understand, keeping in
mind that I have no working knowledge of the Toasters or Amigas (okay, so I'm
out of touch, but trying to learn <g>), a 640 x 480 24 bit JPEG can be read
into the Amiga without difficulty, but the aspect ratio will be incorrect?
I've seen some of the files here in 736 x 482, 768 x 482, and a few others with
mention of "overscan" parameters. In linking the PC generated 24 bit stuff
back into the production switcher, we feed the analog R/G/B/S directly into the
TBC which interprets it as an "isolated field", because of the Fh*2 sync rate,
and internally transcodes to fully interlaced NTSC format, with exceptionally
good results. The only thing we can't do this with is a 256 color dithered
"real world" image, which creates a terminal case of the "wigglies" (aliasing),
an effect you might be familiar with. While the aspect ratio of 1.333 is
slightly off from the normal NTSC ratio, the difference is not critical (only
about 8 pixels). Basically, the question comes down to; what size and aspect
ratio should I use for PC mode generated images that are intended to be loaded
and viewed as a single frame in the Toaster Pro, or high end Amiga system?
And, if the single frame looks good, could the same specifications be utilized
in a series of frames that would be compiled into an animation to be rendered
by same. Again, I have no idea what I am talking about in the Amiga/Toaster
area and am trying to get a bit of an education here. All the PC mode graphics
generated, whether in the form of scanned, extracted from the TBC, or manually
generated are in the form of a 24 bit image. Those extracted from the TBC come
down as 72 bit data, but are converted to 24 bits. The component Y/Y-R/Y-B
modes are not currently being used in this application. Any information and/or
assistance is greatly appreciated.
Vince
If your PC 640×480 images fill the screen, stretch them to 752×480 (or 736, or
768). This will make the images fill the video frame from the Amiga, w/out the
unsightly black border in the overscan area. The Amiga's output at 480 vertical
resolution is actually 2 240 line fields interlaced at video scan rates. These
sizes will work on any frames. The Amiga's nominal resolution is 640×400, but
for video, one uses an overscan mode which will be 736×480, 752×480, or for
severe oversacn 768×482.
Arnie, got that info and appreciate it. Being an Amiga "Dummy", I really
didn't know about this until I got a message on it earlier. Have some new
files up at 752 x 480 and hope they will be more correct. Only thing I don't
understand is that aspect ratio of 1:1.5667, but I suppose the Amiga corrects
for it in the conversion to fully interlaced video. Is any of that overscan
cropped off or just aspect ratio corrected? Forgive my ignorance in this area
as I am still learning something totally new. Thank you for the pointer on the
sizes as it will be used for future reference. It also kind of explains some
of the frames that I've pulled from the forum.
Vince
It will be cropped off by your monitor somewhere, depending on the adjustment.
If you have a severe underscan video monitor, which engineers and video types
generally use to watch ALL their signal, you can see the whole thing.
Frank, forgot to ask the most important question of all on the Amiga Toaster
framestore images. What is the normal gamma value of the files produced? I
realize the NTSC standard calls for a 2.22 display gamma value, but are they
internally processed as linear data and saved as same to be corrected by the
software for display or are they handled at monitor gamma? One of those little
details that seems to make all the difference in the world as far as the
compatibility issue is concerned. Couldn't actually tell from the ones I
looked at with the exception of CADIMA.JPG, which appears to be linear.
Vince
A great question! Gamma is about 2.8 +- 0.3 for color TV, isn't it? That's
what we've used for some of our software.
John, actually, the NTSC standard calls for 2.222, which is a standard
camera/monitor value. It is only recently, since the solid state pickups have
become more popular, and capable, than the vidicon and other vacuum tube
pickups, that we've seen that "1.00/0.45" switch on the cameras. And, some of
the newer NTSC studio monitors that are R/G/B/S capable have started sprouting
the "1.00/2.22" switch on the control panels. Since various sources with
different linearity values have started integrating themselves with video
production equipment, the issue tends to become even more confusing. It seems
like all the various hardware and software manufacturers generally touch on the
subject of linearity, but none of them will go into any detail about it. One
can only guess on what value is what based on a comparison with a known source
value. Been placing a linear sweep in line 21 of both fields, don't need
captioning for stills, and using it as a reference for the digital conversion
to ensure linearity of the output since any processing, like resizing using a
resampling method, can only function properly with linear data. Also, to make
the JPEG processing work right with minimal losses, the data is assumed to be
linear. Actually, that sweep signal has turned out to be more than useful for
a number of other things too. Like, identifying repeatable absolute digital
value points between reference black and full white rather than just tweaking
until "it looks right". What might "look right" on one monitor may be really
bad on another <grin>. That sweep may be kind of a VIR for doing digital
conversions from NTSC, and, there may be a better way, but I've not found it
yet. Got a couple of pics in library 11 that were done using this method of
cross checking values and linearity, but haven't seen any comments from the
"real" Toaster gang yet. I can only guess at what they look like.
Vince
Vince:
I am a Toaster 3-D animator. I don't use my Toaster to work with 'real
live' video much at all, but I've been following your questions with some
interest. Unfortunately, it's been fairly quiet from the Toaster side, so
here's my $.02. . .
I DL'd the Toria.JPG picture and looked at it. It was clean, but didn't
have much high frequency information (the 'Headline News' logo was far
blurrier than I get off of the local cable feed of CNN [& I KNOW their
signal is pretty dirty]). I assume that was because it came from 3/4" ? I
will DL your new images and check them out.
I have never heard any mention of Gamma in reference to the way the
Toaster processes video. I have heard that the digital video inside the
Toaster is processed as D-2 (8bits @ 4xSub-carrier). My assumption would
be that the Toaster has a linear response curve (ie: the video level
coming out = the video level going in).
If you have included a single scanline grey ramp ('linear sweep' as you
call it) on these digitzed images, the best thing I can think of doing is
loading the image into ToasterPaint, saving it off in the Toaster
Framestore format, then re-loading the image and saving it off in the
original RGB format. I could then JPEG this file and send it to you. You
could then compare the grey ramps, and see if they have been affected by
being converted into Toaster Framestores. (As far as I know, the Toaster
Framestore format is basically a dump of the digital video buffer, so it
would be a good representative of what happens to video in the Toaster.)
I'll go ahead and upload the results of my tests along with a single frame
from an animated sequence I made using LightWave. The image should be of
particular interest to you since it is a freeze-frame from a laserdisc
copy of 'Terminator 2'. I was trying to duplicate the holes in the
T-2000's chest after he was first shot by Schwarzenegger in the hallway of
the shopping mall. The image held up pretty well for coming off of my 10
year old laserdisc player and having gone through the Toaster Framestore
buffers, into LightWave, and back out as an RGB image.
Hope this is of some use . . .
Keep On Toastin'
Erik Flom
Erik, thank you for your comeback on this issue. I do appreciate it. Well, as
you have probably guessed, my knowledge of the Toasters, along with the Amigas,
is nill, but I'm trying to learn something new. Toria was a bit soft, but that
is kinda normal from that feeder too. The 3/4 SP U-Matics may not be D1
quality, but more than adequate for the production work we do here (we still
use quads <g>). We are using the BVU-950 series and find the chroma stability
and accuracy to be superior to some of the newer analog formats that have been
showing up, but that is really all a matter of preference <grin>. Of course,
like an idiot, I stripped that sweep (ramp) off in the resizing process (habit
since I only use it internally) but will put another one up with it included
(great idea that I'd not thought of). In fact, it is part of a composit VITS
that is stuck in line 21 just for verification in the digital conversion
process which I could also put up as a full frame for reference if you think it
would help (would a LHAed 24 bit 640 x 480 TARGA format file be best for that
since JPEG would foul it up?). I'm still somewhat confused by the standard size
and aspect ratio of these simulated framestore images. One of the responses
pointed me toward a 752 x 480 size/ratio, which is what the new ones are speced
at, but I've seen 736 x 482, 672 x 560, and 768 x 482. It is really all
somewhat confusing at this point. I based what I saw on the CADIMA.JPG frame
from one of the libraries and was wondering if this was typical from an NTSC
freeze frame of a real world source. Like I said, trying to learn something
new <g>. Ten year old Laser Disk player? I've got one of those too <g>. The
LD1100 from an 83 purchase in the AAFES outlet at Clark AB, which doesn't even
exist any more. Still works and has been all over the world with me. Of
course, there are some others in use too. Even got one of those things from 80
that doesn't even have CX decoding that I picked up in Seattle for $20 for
parts. Funny thing was that it still worked and I didn't have the heart to chop
it up, so it's still here too. I would be interested in seeing your framestore
from the disk since it will probably be a good represeatation of what to
expect. Internally as D-2? That would be the 4:2:2 Y/R-Y/B-Y component
digitized, same way the TBC handles it internally. Could be wrong, but I
remember seeing somewhere in the service manual that preemphasis is applied
prior to digitization and deemphasis on the analog end for noise reduction and
probably a bit of smoothing. Originally, I was pulling the digital data out of
the TBC in component form and converting to R/G/B in the computer, what a pain,
but have discovered how to tell it to give me a transcoded R/G/B output as
24/24/24. It is still easier to get that down to an 8/8/8 format in the
computer, and, it is already linear. I'll put another image up tonight with
the inserted VITS in tact which may give a few ideas. Thanks a million, Erik.
I do appreciate all the assistance in this learning experience. Maybe we can
find an answer to that ellusive gamma question.
Vince
Yes, glad to catch you again!
I did the tests I said I would on the JPEGs you UL'd.
The results were quite interesting. . . .
The Gamma settimg of 1.0 looked best, though it was a little dark and
oversaturated. (As was the picture of Toria.)
By combining the output of the Toaster processed signal & the original
JPEG in ImageMaster, I was able to create a bitmap showing ONLY the
difference between the 2 images. The results were a virtually black screen
– indicating very little degradation in the processed signal. I then ran a
'Histogram equalization' on the image to optimize contrast on the data.
The results showed that the greatest signal degradation occured in the
high frequency portions of the image – the VERY SAME areas that would
suffer the greatest artifacting from the JPEG compression.
Please, do E-Mail me one of your test signals and maybe another 'real
world' image in TARGA, TIFF, or PCX format for testing. (I can resize it
from your default of 640×480 to the Toaster default of 752×480. I think
the standard aspect ratio for Toaster pixels is 1.1:1.)
I'll E-mail you the results of my tests, and upload the Terminator JPEG
into AmigaArts 24 bit files for general consumption.
D-2 is digital COMPOSITE video (8 bits @ 4xColor SC). D-1 is digital
component video (4:2:2 Y/R-Y/B-Y).
BTW, What's with this 24 bit per color per pixel stuff? Isn't that a skosh
extreme for NTSC? :^) (Just curious.)
Keep On Toastin'
Erik Flom
Erik, on your "extreme for NTSC?", perhaps, but it is the way the TBC dumps it
out in R/G/B mode while internally stored in memory as 24/12/12 component.
I've learned not to ask the Sony reps why, only to get any info I can from them
on it. It is one of the older models, vintage 1986 I think, and has extra
capabilities that I still don't know about <g>. The pull in direct R/G/B is
something new as I was previously doing it as component. Got the files from
E-Mail and will take a look at same and get something back up to you in the
mail as a 752 x 480 TARGA, along with the full frame VITS. I'm guessing that
LHArced is a good method to use.
Vince
Yes, LHA those files please. . .
BTW, I doubt I'll E-Mail many more images directly to you – WAY too
expensive. I'll just upload them to the libraries here.
Talk to ya' later,
Erik Flom
Erik, now that I can understand <grin>. One file can kill that monthly credit
on the first day, without even breathing hard <g>. If the SysOp has no
objections, that is probably the best way to go on the "big" ones. Look for
another one shortly and thanks for the assistance in this "learning" process.
Think I've got it confirmed that the Toasters work everything as linear and
correct for display, at least that's what the files are telling me. The
"Terminated" file is linear, and looks good. So good, that you can even
identify the overlay area from the film for the sfx. Later, Erik.
Vince
Erik, and new frame up as "LOPPY.JPG" as 752 x 482 with the VITS in tact.
Again, appreciate your time and assistance in my learning process.
Vince