#Wish list
11 messages in this thread
Gary, on November 27, you replied to Rudy Mantel that it's possible to
rotate at sub-1o increments by typing in the rotation amount in the Key Info
dialog. Uh, have you ever actually TRIED that when you have a lot of rotations
in progress at some point in a path and so you have lots of decimal place
digits in the X, Y, and Z boxes as well as the Angle box? Trying to compute a
precise straight-X, Y, or Z-axis rotation without disturbing the other
rotational axes is ridiculously difficult for those of us who aren't
trigonometry experts. Remember, 3DS reduces the three axes of rotation to a
single resultant axis which often passes diagonally through the pivot point at
really weird angles which have little apparent relation to X, Y, or Z.
What Rudy and I and others want is the ability to rotate around one of the
main axes in the Keyframer just as we can do in the 3D Editor and Shaper and
Lofter at angles less than 1o. The others have ~o increments. Why doesn't the
Keyframer? Why should we be expected to do heavy math ourselves when this is
what computers are for in the FIRST place!?
November 27th, huh? Are you sure that wasn't the 26th? 28th? <g>
(What's your name, anyway?)
Regarding keyframer rotations. Here's the deal… The KF uses
quaternions to derive the rotation transform, and the Editor/Lofter
uses Euler angles. That's why things are different between them.
It's been one of our internal wishlist items for awhile to allow
either kind of rotation if you so desire, and I hope to get that
capability into the next release (along with your "object cameras").
– G
Object Cameras in the next release!? YIPPEE!! And here I've been trying to
figure out how to go about using KeyScript to transform and copy Rotation keys
from a Dummy object and translate them to appropriate Roll keys for a Camera
linked to the Dummy, in effect doing my Object Cameras in a round-about way…
It looks like the next release is going to have some REAL New Features and
thus be the REAL Release 4, whereas the current is at best Release 3.5. <grin>
Speaking of features, remember WAY back when when I asked you about the
4:1:1 Subsampling being done in the JPEG output? JPEG can support either
4:1:1, 4:2:2, or 4:4:4 (in order of increasing image quality and decreasing
compressability — the latter is effectively no subsampling at all). By
hard-coding 4:1:1, Release 3 generated JPEG files which simply could NOT be set
to the best possible image quality no matter how high the Q-Factor (Quality vs.
Compression) slider was set to. Note also that NTSC and I believe PAL video
perform 4:2:2 subsampling in their own YUV encoding, so that 4:1:1 is lesser
image quality than NTSC standard, so ANY JPEG FILE OR SERIES OF FILES CREATED
WITH 3D STUDIO CANNOT BE CONSIDERED "BROADCAST QUALITY"!! They must have at
LEAST 4:2:2 to be Broadcast Quality!
I asked that an interim release be made which would if nothing else at least
add a 3DS.SET file parameter "JPEG-SUBSAMPLING" which could be set to 1, 2, or
4, for 4:1:1, 4:2:2, or 4:4:4 subsampling, respectively. The default would be
1 for compatibility, but the default included in the sample 3DS.SET file and
commented out would be 2 for minimal compliance with NTSC broadcast standards.
You said you would do this, remember? No such interim release has come out.
When we got (so-called) Release 4, I eagerly read through its new
parameters, and NO "JPEG-SUBSAMPLING" parameter, or anything else! I was
hoping that Release 4 (which in my opinion we have yet to see — what we have
now is Release 3.5 and I will NOT back down on that, but I do digress here…)
would have an actual "Subsampling" set of radio buttons or slider or spinner
control with available values of 4:1:1, 4:2:2, and 4:4:4/None in the
Render/Setup/Configuration box when JPEG is selected, just as it now includes
the Q-Factor slider, since you told me that it was Autodesk's policy that
changes to the user-interface, however minor, had to wait until the next major
Release and couldn't be included in any interim Releases, which is why some
additions in Release 2.1a had to be implemented as 3DS.SET file parameters.
But not only did we not get that, we didn't even get the 3DS.SET file
parameter! Or if we did, it wasn't documented. What gives!?
If you want to add your own type of JPEG output/subsampling, the BXP interface
makes it extremely simple to do that.
– G
Oh? And here I thought that .BXPs were keyed off of extensions, so that the
only way to do that would be to use a non-standard extension for the new,
more-controlled JPEGs, seeing as ".JPG" is already taken by the r3/"4" built-in
JPEG processing. Not to mention that .BXPs can't have a user-interface, so
just how is the user going to specify the subsampling OR the Q-factor for that
matter? I suppose I could link a .PXP to it for the user-interface business.
Can .BXPs read 3DS.SET? I don't see why not, so it should be possible to
provide my own parameters in there for the JP2.BXP or whatever it'd have to be
called. Then there's always .IXPs, but that slows down rendering considerably.
You'd use a new extension (JP2, JPX, whatever) and build a PXP that controls
the parameters, just like CHKED_I.PXP controls the CHK_I.BXP parameters.
– G
Ah… excuse me but there is no CCIR standard for JPEG, and while comparing
ratios you're not taking into account differences in encoding schemes, which
makes your comparison of 4:1:1, 4:2:2 etc. with JPEG basically irrelevant.
And just so you know, the proposed standard for JPEG offers data compression of
between 10 and 100 times with three levels of processing defined, the baseline,
extended and lossless encoding. So even if your analogy was accurate the JPEG
encoding scheme employed by 3DS would easily conform.
PMJI Gary.
John
Not so. When JPEG performs subsampling, it looks at "u" and "v" pixels of
chrominance information for every "y" pixels of luminance info and considers
them ONE pixel of chrominance (averaged from the "u" and "v" values of those
pixels). The format for specifying subsampling is "y:u:v:" so "4:4:4
subsampling" basically says, "For each 4 pixels of luminance, take the
corresponding 4 pixels of chrominance and treat them as 4 pixels." In other
words, don't subsample at all. The chrominance values of the four pixels are
treated as individual pixels.
But the human eye is more sensitive to abrupt changes in luminance than in
chrominance, so long ago the broadcast experts who designed the NTSC system
figured out that they could save bandwith by treating every two pixels' worth
of chrominance as if it were only one. (Actually, they didn't call them
"pixels" back then — being analog, it was more along the lines of cycles of
the 3.58MHz color burst reference sine wave attached to the front porch of NTSC
scan lines.) Thus we have 4:2:2 subsampling in NTSC broadcast signals. This
basically means that the luminance can change every pixel, but the hue and
saturation can only change every other pixel. Due to human visual perception
limits, this is an acceptable compromise for the bandwidth gained. (Actually,
it's not hue and saturation per se, but "redness" and "blueness," but that's a
LOT more complicated and it's much easier to think in terms of hue and
saturation. The basic point I'm trying to make is the same either way.)
So if JPEG subsamples at 4:2:2, the chrominance averaging is no more than
that performed by NTSC anyway. Nothing is really lost (except some possible
Nyquist artifacting, but that's not likely to be noticed at 30 frames per
second), and quite a bit of extra compressibility at a given quality level can
be gained.
But when JPEG is set to 4:1:1, then we have FOUR pixels of chroma info
averaged into one, over the space of four pixels of luminance info! So hue and
saturation are basically held to the same value over FOUR pixels of changable
luminance! This is TWICE the subsampling that NTSC itself does, so the
chrominance detail of the image IS noticeably reduced when brought to NTSC.
The three various values of subsampling for JPEG exist because there are
different things people do with JPEG. 4:1:1 may be just fine for CD-ROM
animations for games, for instance. It would save more room and reduce
luminance artifacting from JPEG at the expense of less-noticeable chrominance
detail, since CD-ROM animations have to be compressed quite heavily to fit in
the 300kB/sec. bit rate that MPC2-spec double-speed CD-ROMs require. For
output to prepress for glossy magazines, 4:4:4 may be the only acceptable
value, since NTSC isn't involved here and there is no maximum data rate or file
size, and JPEG would be used at all only to save a little disk space over other
lossless compression schemes.
But for true broadcast-quality NTSC, 4:1:1 is unacceptable. 4:2:2 is
acceptable but may result in Nyquist artifacting in the chrominance data.
4:4:4 may be overkill for most situations, but would not permit Nyquist
artifacting to occur in the chrominance data (not that any but the most
highly-trained eye would notice if it did).
Its just common sense that if JPEG used the same algorithms that it would
conform to CCIR 601 specs and it doesn't. In fact the sampling is different,
and there are algorithms to prevent rounding errors seen as artifcats, which
are necessary when compression is used for moving images, which JPEG doesn't
incorporate. And to prove the point, the proposed standard by JPEG ISO/CCITT is
for stills only.
>> The three various values of subsampling for JPEG exist because there are
different things people do with JPEG. <<
You really went out on a limb on this one. The three levels of processing I
mentioned were specifically proposed for Television by the same committee.
Its obvious you understand the concept, its in the details of how its being
implemented for Television that the gaps exist. You might want to call the
United States Advaned Television Test Center, in Alexandria VA. It would be
better than hashing it over on the forum. In other words I decline to debate it
with you, as the information is readily available if you or anyone else wants
it.
John
No, John. The three types of subsampling and the three levels of the
proposed television standard are NOT only NOT the same thing, they aren't even
RELATED CONCEPTS! You're confusing your apples with your igneous rocks here.
>> The three types of subsampling and the three levels of the proposed
television standard are NOT… the same thing. <<
In _context_ "three levels of proposed television (processing) standards" was
in reference to:
" The PROPOSED STANDARD (for JPEG, for Television) offers data compression of
between 10 and 100 times and THREE LEVELS OF PROCESSING are defined: the
baseline, extended and lossless encoding. "
If we had been talking about Proposed Television Standards and JPEG I can see
how you might have gotten confused.
John