Slashdot Mirror


User: Rui+del-Negro

Rui+del-Negro's activity in the archive.

Stories
0
Comments
780
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 780

  1. Re:In this case, don't RTFA on In-Depth Look At Video Codecs · · Score: 1

    Well, using the "must play anywhere" metric, I'd say MPEG-1 ranks the highest.

  2. Re:We Don't Care!! on In-Depth Look At Video Codecs · · Score: 2, Insightful

    I don't know who the "we" you're talking about is, but some people do understand that different situations correspond to different needs. Sometimes you need lossless quality, sometimes you need the lowest possible data rate, sometimes you need a format that can be decoded with very little CPU power.

    Do you also think that there should be a single type of paint, a single type of tire, a single type of lightbulb, and so on...?

  3. Re:Theora?? on In-Depth Look At Video Codecs · · Score: 1

    "AVI" is a container format, AVI files can use hundreds of different codecs.

    If you want the best possible quality, stick to the original format (ex., if your source are DV tapes, use DV-compressed AVI or MOV files).

    If you want the best quality vs. size ratio, a MPEG-4-based codec (ex., XviD, x264, etc.) is probably the best choice. Using an AVI / MOV container will give you compatibility with a lot of existing software.

    Good luck using Theora with video editing / compositing software...

  4. Re:In this case, don't RTFA on In-Depth Look At Video Codecs · · Score: 1

    Glad you liked them.

    The original plan was to write a single article with two pages or so, but then I kept thinking "normal people won't understand this, I have to go more slowly / add more examples / start further back / etc.", and then "well, since I've included X, I might as well mention Y and Z", so they kept growing.

    They're still pretty vague on implementation details (except for RLE, which is probably simple enough that everyone will understand), but I hope they'll at least give people an idea of the differences between the various "families" of algorithms.

  5. Re:AVP beats ASP, no surprise. on In-Depth Look At Video Codecs · · Score: 1

    Saying that could seem to imply that H.263 was "extracted" from MPEG-4, which was not the case. It would be more accurate to say that MPEG-4 part 2 was drafted in such a way that it covers everything required to decode "baseline" H.263 (there are some variations of H.263 not covered by MPEG-4).

    In other words, basic H.263 is "covered" by MPEG-4 part 2 (but the two are not identical), whereas MPEG-4 part 10 (AVC) and H.264 are identical (they're separate standards, but there's a working group that keeps them "in sync").

  6. Re:AVP beats ASP, no surprise. on In-Depth Look At Video Codecs · · Score: 1

    Not really, beyond telling him to read the H.263 specification...

    http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T -REC-H.263-200501-I!!PDF-E&type=items ...where he won't find any reference to the MPEG (let alone MPEG-4, which was published after H.263).

    MPEG-4 is "H.263 compatible" in the sense that a basic H.263 stream can be correctly decoded by a "complete" MPEG-4 video decoder, but MPEG-4 decoders aren't required to be "complete" (which is not to say that a lot of them don't cover what's required to decode ITU H.263). And a MPEG-4 encoder certainly isn't required to produce H.263-compatible streams.

    Of course, he might be saying just that the full MPEG-4 standard "covers" everything you need to decode basic H.263, in which case he's correct. But H.263 is not "a part of MPEG-4" (it was developed before MPEG-4, by a different organisation), unlike H.264 which was atually developed along with and is part of the MPEG-4 standard (it's "part 10", a.k.a. "AVC").

  7. Re:Image Algorithms on In-Depth Look At Video Codecs · · Score: 2, Interesting

    Yes, I was talking about stereo (which is still how >90% of music reaches the end users).

    For audio production, lossy compression is a no-no (bandwidth and space are seldom issues), so there's no point in comparing lossy codecs.

    For the vast majority of consumers, what matters is their perception of quality.

    The point of quality comparisons is not to say "I recognise this version as the uncompressed one". It's to listen to several versions and pick the "best" one. And for that you don't need to know the piece at all. In fact, I'd argue that if you know a particular recording of that piece, you won't be judging abstract "quality"; you'll just be judging similarity to the version that you're used to.

    In other words, like you say, (in a proper double-blind test), you'll only see consistent results if something "encodes really badly" (i.e., has obvious compression artifacts).

    For image and video, where compression is often a requirement due to bandwidth and space issues (even during the production stages), it makes more sense to do comparisons to the original, rather than abstract "quality" evaluations. Which is not to say that consumer perception isn't still important. For instance, point & shoot digicams frequently over-saturate and over-sharpen images, because many consumers prefer that "look". Professional photographers prefer raw (or at least rawer) images, because they preserve more of the original information.

  8. Re:AVP beats ASP, no surprise. on In-Depth Look At Video Codecs · · Score: 1

    Not exactly. H.263 is not the same as the MPEG-4 ASP. XviD is indeed based on the MPEG-4 ASP, and can also produce H.263 files, but the two things are different (albeit similar, especially if you consider H.263 v2).

    Also, bear in mind that video compression standards focus on "what" the encoders must create, not "how". Even if a certain standard supports more advanced features, a "smarter" encoder using a "lesser" standard can produce similar, or even better results.

    As H.264 encoders improve, they should clearly surpass MPEG-4 ASP, but right now that is not necessarily true for all encoders, at all bitrates, with all types of footage.

  9. Re:AVP beats ASP, no surprise. on In-Depth Look At Video Codecs · · Score: 1

    H.263 is indeed not the same as MPEG-4. H.263 was published in 1995 by the ITU, MPEG-4 (first "official" draft) was published in 1998 by the MPEG. H.263 is based on H.261 and MPEG-2, but was developed without the MPEG's help.

    It uses similar concepts to MPEG-4 (all BMC-based algorithms do), but several details in stream structure are different (which is not to say parts of a MPEG-4 codec can't be used to accelerate H.263 compression or decompression).

    H.264, on the other hand, was developed by the ITU in partnership with the MPEG, but it's still not "the same" as MPEG-4. MPEG-4 is a generic term for a set of guidelines that are somewhat flexible and effectively still under development. No codec (soft- or hardware) that I know of implements all of it. Anyone implementing a part of MPEG-4 (no matter how limited) can claim they have a "MPEG-4 codec".

    If you want guaranteed (well, sort of) compatibility, look specifically for "H.264" or "AVC", not the generic "MPEG-4" term. Most modern software decoders will chew through any MPEG-4 flavour, but hardware codecs (on set-top players, etc.) expect a more constrained standard.

  10. Re:The description of DCT is pretty funny on In-Depth Look At Video Codecs · · Score: 5, Informative

    And so you should describe it as "dividing numbers by two and then multiplying them again"...? In other words, a "simple" description is preferable, despite the fact that it's completely wrong...? Hell, "dividing numbers by two" isn't even an accurate description of quantization, let alone of a DCT.

    I think I made a pretty decent job of explaining what "frequency space" is, and why it can be used to improve compression, here:

    http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=109739-2

    (scroll down to "The transformers")

    It also explains why DCT isn't a form of compression per se, it simply makes it possible to use quantization in a way that does not affect quality as much as it would in "pixel space".

    Several "non-techies" have read that and, although they realised the transform itself is not something trivial, they understood what it did and what it was used for. Something that you can't really say about the Atomic article (or its author).

  11. Re:Image Algorithms on In-Depth Look At Video Codecs · · Score: 1

    If by "similar" you mean "completely clueless", yes, I know a few, but can't really see the point in propagating them. :-) If you want an article with some theory and a visual comparison of JPEG and JPEG-2000, here:

    http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=109739

    (disclaimer: I wrote it, but I don't get any $$$ from page views... unfortunately :-P)

    There are lots of articles about sound codecs, but most of them seem a bit too "mystical" to me (as is typical with all things audiophiliac).

    In double-blind tests most people can't really tell the difference between uncompressed audio and the main codecs (WMA, MP3, OGG, etc.), beyond a bitrate of 256 kb/s or so. Some people can, but most just think they can... and get it wrong half the time (which is why double-blind tests are important).

  12. Re:In this case, don't RTFA on In-Depth Look At Video Codecs · · Score: 5, Interesting

    God, I've just read his description of DCT. It's even worse. He seems to think that DCT consists of "dividing numbers by two" (he doesn't even use the word "quantization", that probably has too many syllables). And people complain about Wikipedia...

    Time to shamelessly plug my articles about compression. Some parts are simplified (they're aimed at "end users") but, compared to this Atomic article, anything is flawless:

    Lossless (data, image, audio)
    http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=106309

    Lossy + Hybrid (image, audio)
    http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=109739

    Video (lossless, lossy)
    http://digitalproducer.digitalmedianet.com/article s/viewarticle.jsp?id=125089

  13. In this case, don't RTFA on In-Depth Look At Video Codecs · · Score: 4, Interesting

    I've just read a bit of the article and the only thing I can think of is to paraphrase Stanislaw Lem: "it always amazes me that people need a license to drive a car but can write and publish all sort of nonsense without any clue about the subject".

    His descriptions of "temporal compression" and "motion compensation" (to name just two of the fundamental building blocks of modern video codecs) are so wrong they don't even qualify as an error. He confused delta compression with motion compensation, thinks MPEG1 lacked the latter, doesn't understand why the former is virtually useless for video... sigh... even trolled Wikipedia articles manage to be more accurate than that.

    I feel truly sorry for the people who read that and think they've learned something about the subject.

  14. Time (not processing) is the constant on Pitting a Mac Plus Against an AMD Dual Core · · Score: 2, Insightful

    The real issue here is not if an "AMD system" is faster than a "Mac". For that, they would have to test exactly the same software, not different versions of it. The issue is if modern software, running on modern hardware, is faster than old software, running on old hardware.

    For "interactive" tasks it usually isn't, and for a good reason.

    No one cares if a program takes 1.4 seconds to complete a find & replace instead of 0.8 seconds. No one cares if a program takes 5.4 seconds to start instead of 3.9. If it took 20, then yes, people probably would care. You see, for interactive tasks, time is the fixed value. Specifically, the time that people don't mind waiting (which varies depending on how common that task is, of course).

    This article just proves Murphy's laws of computation: data expands to fill all available space, processing expands to fill all available time, etc..

    It's the same thing with games. I could probably take a game from 1995 and run it at 400 fps on my modern hardware. But if I can run a much better-looking version at 60 or even 30 fps, I'll probably pick that one instead. If it ran at 5 fps, I would rather play the old one.

    There is a point beyond which "more features" (or "prettier graphics" or whatever) is worth more than an increase in "reaction speed".

    That is why CPU-intensive tasks (the ones that never feel "fast enough") are the right way to test hardware; because they tell you how fast the thing can run, and not how fast the developers decided it should run to avoid annoying the user while appealing to as many people as possible (by including extra features).

    The article's conclusion that there is "zero advance in productivity" is meaningless. Even if we take one of the most common operations (find & replace), does anyone really believe that, if it completed 1 second faster, people would be noticeably "more productive"...? In this kind of task, "productivity" depends 99% on the human part of the system.

  15. Is anyone surprised? on PC World Editor Resigns When Ordered Not to Criticize Advertisers · · Score: 1

    Seriously, is anyone surprised? Nearly all magazines, TV networks and big websites work like this. Even a lot medium-sized ones do it, because they rely on freebies from the manufacturers. You post something bad about the latest Intel CPU, and you can forget about getting free chips when the next generation comes. Write anything bad about an EA game and EA won't let you see the demo of the "Next Big Thing", which means your site gets less hits than the "cooperative" competition, which means your advertisers pull out. When was the last time you saw a game from a major publisher get less than "75%" at any "professional" (meaning ad-funded and with access to early previews) review site?

    This is, unfortunately, one of the effects of everything becoming "free". If a site or magazine can't depend on what the readers pay, they have to get money from somewhere else to stay in business. And since IT magazines are mostly read by people interested in IT, those are the advertisers they get.

    If you trust any free website that advertises the same type of products it reviews, or any site that relies on free samples from the manufacturers, you're very naïf.

    Smaller "amateur" hardware sites, sometimes affiliated with a particular retailer, are far more reliable (not necessarily competent, but at least not as biased). First, because they don't need to please the people paying them. And second because the products they get for review are just like the ones everyone else can get, not a hand-picked "perfect" one sent by the manufacturer.

    I'll take The Inquirer, Dan's Data and Old Man Murray over DailyTech, Tom's Hardware and Gamespot any day. If I just want to read press releases I can go straight to the manufacturers' sites.

  16. Why Apple CAN'T buy AMD on Why Apple Should Acquire AMD · · Score: 1

    Because AMD (after the ATI takeover) is roughly 5 times the size of Apple. And I doubt AMD could raise enough cash to buy Apple, either. Then there's the fact that all current Apple systems are designed for Intel CPUs, so that would only add short-term R&D costs.

    In other words, this is another piece of news straight out of the reality distortion field.

  17. Re:Opera helps on Virus Writers Target Google's Sponsored Links · · Score: 0, Offtopic

    I don't find the interface awkward at all. That might be because I've been using it since version 4 but what I see is the other browsers copying Opera's interface and features, not the other way around.

  18. Opera helps on Virus Writers Target Google's Sponsored Links · · Score: 1

    The links appear just fine in Opera, with no need for plug-ins or to disable JavaScript.

  19. Re:It's possible. on Digital Camera Vs. Camera Phone · · Score: 1

    If you shoot in "raw" mode, you can adjust the white balance at any time (ex., when loading the image into your editing software) with as much accuracy as if it had been set perfectly on the camera to begin with. If you shoot in JPEG mode, you should try to get the white balance as close to right as possible, because any changes can cause a degradation in image quality (mainly "banding").

    Usually just selecting manually between the 4 or 5 white balance presets (tungsten, sunlight, shade, fluorescent, etc.) before you take the picture is enough to get the shot within a range that can be fine-tuned later (with a "color balance" filter).

    Also, note that mixed-light situations (ex., tungsten lit interior with sunlit exterior visible through the window, or with a TV or PC monitor) have no "magic" solution. Our brain can mix multiple white balances into a single "mental picture" but cameras can't. The only way to make the colours look right in that kind of photo is to manually select and adjust each area. In those cases, pick the white balance that matches the most important part of the image, so that part will lose less quality when you make the final adjustments.

  20. Re:Next article on CNet... on Digital Camera Vs. Camera Phone · · Score: 1

    For these people, the "burnt highlights, blotchy shadows, lens distortion and digitally over-sharpened edges to disguise the lack of real resolution" still might look better than the actually superior results of a quality camera.

    As I wrote above: "if you really like that look, you can always tell your photo management software to apply it to all your pictures automatically [at the same time as it resizes them]".

    The silliness of this article has to do with the premise that "most people" take pictures with the utlimate purpose of resizing them (presumably to 540x360 - the resolution used in the article) and uploading them to Flickr (which, BTW, isn't actually mentioned in the original article, only on the Slashdot "summary").

    I'm pretty sure that, even on Flickr, most images are larger than 540x360 pixels (that's less than 20% of the size of a desktop monitor, these days), so the article doesn't even provide a good comparison for _that_, let alone for photo "archival" or printing.

    Anyway, looking at the pictures, I definitely prefer the ones taken by the 400D, despite the slightly incorrect white balance (too orange), which can easily be fixed. The N95 might have slightly better auto white balance for tungsten (still not right, though - too blue), but there are annoying sharpening "halos" around the edges of the figures (noticeable even after the reduction), which no magic filter will get rid of. And in the flash photos the 400D is so much better than the N95 that it's really no contest.

    most people will say that the Nokia cellphone produced "better" pictures than the dSLR

    Really? If you actually read the article you know that its authors acknowledge that the 400D delivered the most detail (even after such a big reduction in size - imagine the difference in the original), and that it handled the flash much better (in every aspect: detail, focus and colour). They never said the cellphone took better pictures. So I guess your definition of "most people" doesn't include the article's own authors.

    My criticism has to do with their premise and methodology (assuming an unlikely goal and resizing to a very low resolution); their conclusions from the actual photos are pretty much correct: the 400D is the best, with the exception of incorrect auto white balance in that particular shot. I suspect that if they were using sunlight, the 400D's white balance would have been more accurate than the N95's (but both would probably still benefit from a small manual adjustment).

    What their premise and methodology don't show is just how big the advantage of the 400D is in terms of image quality. If anything, this article shows that even after you resize the images from 10MP and 5MP down to 0.2MP, the photos taken with the dSLR still show more detail. Unfortunately, some readers might think that's due to the 5MP advantage, when in fact a 10MP version of the N95 would probably produce even worse results. The real advantages of the dSLR (and even most P&S digicams) over the cellphone are the lens quality and (physical) sensor size.

    And this is with a "consumer-level" dSLR and the best cellphone camera in the market.

  21. Re:Next article on CNet... on Digital Camera Vs. Camera Phone · · Score: 1

    the expensive manual cameras are designed for photographers who will exercise a lot of control for the best effect (whatever they're looking for), and so often their automatic settings aren't as good at providing what the point-and-shoot photographer would consider "pretty".

    What a digital camera creates is only one part of the process (much like film still needs to be devloped, outside the camera). When you import the images into your PC (whether you're going to upload them to a website or e-mail them or print them), you have a chance to perform more adjustments (some cameras and even cell phones now have built-in photo editing, BTW).

    If you're going to scale down the image, there is no reason why you can't increase or decrease contrast, saturation, brightness, colour temperature, etc., and a lot of "photo album" software does this automatically (even Photoshop will "automagically" decide the "best" settings when importing raw images, although it will not change JPEGs unless you specifically tell it to - anyway, Photoshop is not what most people use to organise their photos, so it's an extreme example).

    A camera that artificially increases the saturation or contrast before saving the photo makes it impossible for the user (or automated software) to recover any information lost in that process. On top of that, that extra processing takes time and decreses the camera's battery life. It's much more efficient to do the processing when the images are imported to your "photo album", whether automagically or manually (and do it only on the images that you intend to use).

    I own a cellphone with a built-in camera, a P&S digicam and a dSLR (all of which were "high-end" a couple of years ago). Photos taken with the dSRL in "fully automatic mode" are at least as good as the ones taken with the P&S, and a lot better than the ones taken with the camera phone. And I'm talking absolutely no post-procesing; just JPEGs straight out of the camera(s). The more post-processing I apply, the more noticeable the advantage of the dSLR (even in JPEG mode).

    Now, a dSRL is bigger and more expensive, and in a lot of situations the P&S is (more than) "enough". But no, the automatic mode in dSLR's isn't "worse" than the cellphone camera in any way, unless your defintion of "worse" means "lacking burnt highlights, blotchy shadows, lens distortion and digitally over-sharpened edges to disguise the lack of real resolution". And if you really like that "look", you can always tell your photo management software to apply it to all your pictures automatically.

    P.S. - Not a single person I know uses Flickr. Maybe I'm just not part of the photographic elite, like the folks at CNet... o_O

  22. Re:Next article on CNet... on Digital Camera Vs. Camera Phone · · Score: 1

    Depends on sensor technology, too, so it's not really a hard number. But 3 MP is all you need to get good quality at all (non-insane) screen resolutions, and it looks great printed at 10x15 cm (and still very good at 20x30 cm). So it doesn't make any sense to pay more for extra pixels on the same sensor size. It does make sense to pay extra for a (physically) bigger sensor, because it will perform better in low light, and generally have less grain.

    I have an EOS-300D (and I also use a couple of Nikons as part of my work). The 350 / 400D's grip is too small for my paws. Except for very long exposures, the 300D's quality is on par with the newer models, and I don't really need more than 6 MP for the sizes I print. I might get a 40D if / when it comes out (meaning a 400D with a "pro" body), but probably not before I "complete" my lens line-up (last two I got were the 70-200 2.8L IS and the 17-55 2.8 IS - the latter is great, the former is just unbelievable). I still need something to go below 17mm (maybe the 10-22), plus an MP-E 65 for extreme macro and a tele-extender that works with the 17-55 and the 70-200 (so I have the 55-70 range covered, and can go up to 400 or so)

  23. Re:Next article on CNet... on Digital Camera Vs. Camera Phone · · Score: 3, Insightful

    It's not a matter of providing superior quality. They are deliberately limiting the quality by assuming that everyone's final goal is to post scaled down pictures on Flickr. Hence the comparison with video scaled down to a point where the original quality is irrelevant. 64x48 pixel video is worse than DVCPRO HD but my point is that it's also worse than VHS.

    Most people (especially the ones with two X chromosomes) like to be able to print their pictures, and most camera phones can't really produce acceptable results above 15x10 cm (6x4"), regardless of their resolution. Their sensors are simply too small and too noisy. In fact, for the same sensor size, a 3MP sensor is likely to have better quality than a 5MP model.

  24. Re:Next article on CNet... on Digital Camera Vs. Camera Phone · · Score: 3, Funny

    You're right. I completely forgot that 87% of home users and 95% of broadcast professionals use YouTube as their "master" format. ;-)

  25. Re:It's possible. on Digital Camera Vs. Camera Phone · · Score: 2, Insightful

    Depends. Some cameras try to cram so many pixels into such a small sensor that you end up with a noisy, grainy, blotchy piece of crap even with loads of sunlight.

    Unfortunately "megapixels" are the "megahertz" of digicam marketing (same goes for lower reaction times in LCDs, often achieved at the cost of image quality and colour accuracy), and people don't realise that, for screen viewing, they're unlikely to ever need more than 3MP.

    Also, cameras with "angled" light paths (ultra-compacts without lens extension) tend to have very, very bad distortion and CA.

    There are several great compact digicams out there, but there are also a lot of really, really bad ones.