Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×

Comment Re:Holy flawed methodology, batman... (Score 1) 378

True, except there is no indication that they did this. On the contrary:
  • They selected 1,000,000 random pics from the web, without any selection for compression quality. And srsly, are they trying to tell me that *google* doesn't have access to a sufficient number of raw images?
  • They compared the algorithms at PSNR around 40, which is not that highly compressed.
  • They make a big deal out of the fact that the advantage of using their algorithm is greater for small (low-res) pics... I would assume (without any data to back me up) that low-res pics on the web tend to be more highly compressed to begin with. I'm assuming this because small pics would tend to not be photographs, and because if you use low resolution, you're probably trying to save bandwidth and web space, so compressing more would be logical.

And anyway, these are by no means the only problems with what they're doing.

  • As others have pointed out, where are the standard pictures everybody uses to compare compression quality?
  • Why did they arbitrarily compare the algorithms at PSNR=40?
  • Comparing with jpeg at this point is like kicking a puppy. The comparisons with j2k is meaningless (see above).
  • If they're just trying to create a better alternative to jpeg without the patent hassle, they should say so. But in that case, what's wrong with promoting any of the existing algorithms?
  • The main problem with jpeg is that it's used blindly for all kinds of images, and it was simply not designed for that. Suggesting that one new algorithm should take over everything that jpeg does right now is idiotic. The right replacement at this point depends on what the image is you're trying to compress. E.g. j2k is good for large photographs at relatively high bit rates. Png is actually very good at things like line drawings. Etc...

Comment Holy flawed methodology, batman... (Score 2, Insightful) 378

They're comparing webP to jpeg by testing how well both algorithms can recompress (a set of almost entirely) jpeg images? Really? Really???
More to the point, jpeg compression artifacts (discontinuities) are a *nightmare* for wavelet coders, so this is in no way fair to jpeg2k.

Also, from TFA:

Predictive coding uses the values in neighboring blocks of pixels to predict the values in a block, and then encodes only the difference (residual) between the actual values and the prediction. The residuals typically contain many zero values, which can be compressed much more effectively.

WTF, this is exactly what a wavelet coder like jpeg2k does, only in a much more sophisticated way.

This whole thing is so far below any accepted standard of image compression research, it should just be silently ignored.

Comment Time for a /. poll (Score 1) 911

(1) I know how to patch a Linux kernel and I own/want an iPad
(2) I know how to patch a Linux kernel and I don't want an iPad
(3) I don't know how to patch a Linux kernel and I own/want an iPad
(4) I don't know how to patch a Linux kernel and I don't want an iPad
(5) I'll buy one right after Cowboy Neal

I'm pretty sure some people here would be surprised...

Comment Re: I guess they've never heard of Orson Welles... (Score 1) 217

Not the 'cultural sensitivity police' just proving a point, proven further by the fact that you didn't know who al-Majali is. Rather than dismissing it as someone I made up, a simple search would have educated you. Yet you expect Jordanian's to know not only who Orson Welles was, but what similar historical prank that he was involved in well over 70 years ago. Meaningless to many contemporary Americans, let alone Jordanians.

I don't see how that proves any kind of point whatsoever. First, the reference to Orson Welles was not there so Jordanians should get it, it was there for the /. crowd. (not that there's no intersection). Second, the implication that Jordanians should know about the War of the Worlds scare was clearly a joke -- but wouldn't it have been useful if they had? Third, again, how are you not comparing apples and oranges? Give me the name of a Jordanian film director who was involved in a prank that, if known in the US would have been highly useful in avoiding an embarrasing similar occurrence there. Then we'll talk.

Not exactly a nobody, but *you* didn't know who he was, did you?

No, I didn't know who he was. Yes, I did look him up, as you might see from the fact that I referred to him as a political figure, not, say, a member of a Jordanian boy band. And no, I wasn't serious when I said you made the name up. There should really be an irony tag.

Comment Re: I guess they've never heard of Orson Welles... (Score 1) 217

Wow, how culturally sensitive of you.

Ah, the cultural sensitivity police. Where would we be without you guys.

And you're right, referencing a highly similar and relevant story that happened in the US is just the same as arrogantly assuming that everyone everywhere needs to know obscure political figures with funny names that, frankly, I think you made up.

Comment Re:Idiot. Seriously. (Score 2, Interesting) 623

Not to mention that he can't grasp the awesome power of 300 APIs (sorry, "technologies") each with three letter abbreviation names starting with J that make up the resume of a typical Java programmer.

Agreed, but the problem is that most of those "technologies" are bloated, designed by committee, buzzword-loaded crap. The problem is *not* that we have found better ways to share code than we used to. I mean, I'm all for crafting beautiful, optimally efficient snippets of code that do one thing perfectly. But have you ever noticed that you can do things in a couple of hours now that 10 years ago would have taken weeks? Being able to cobble together a prototype fast is *hugely* useful and important. Now who was it again who said that premature optimization is the root of all evil? Hmmm...

Image

California Legislature Declares "Cuss-Free" Week 262

shewfig writes "The California legislature, which previously tried to ban incandescent light bulbs, just added to the list of banned things ... swear words! Fortunately, the measure only applies for the first week of March, and compliance is voluntary — although, apparently, there will be a 'swear jar' in the Assembly and the Governor's mansion. No word yet on whether the Governator intends to comply."

Comment Re:Salary (Score 1) 289

31,000 euro for a _kernel_ developer?? Probably closer to 3 times that. I know it's an average, but do you really think the maintainer of a memory system, or the scsi stack, etc are worth less than 6 figures?

Keep in mind that that kernel developer would be working on the scsi stack of a commie plot...

Comment Re:Metastable Flip flops still have bias (Score 5, Informative) 395

You're confusing Shannon entropy and true randomness. If you have a string of bits that are created by a process that is truly random but has a bias, it's easy to transform it into an unbiased (but shorter) string.

The problem with pseudo-random generators is that they're really not random at all: They're determinstic functions that map a seed onto a sequence of random bits. If you know the function and the seed, you can predict all of it, which leads to potential vulnerabilityies. The point of truly random numbers is that there's no possible information you could have that would enable you to predict it.

Comment Re:How about Alice? (Score 1) 214

I was a TA for a class that used Alice a while back ("Computer Literacy" -- intro to computing for non-majors). My impression based on teaching 3 labs a weak is, and I really can't put this strongly enough: Alice is misguided, it's counterproductive, and it's lame. Alice sucks.

Alice is a very snazzy graphical system that seems to try as hard as possible to keep people from learning anything whatsoever about what programming is, how it's done, and most of all what it's good for and why it's fun.

One underlying principle of Alice seems to be that, instead of exposing people to important concepts directly, we should make it all easier by sugar-coating everything with an elaborate GUI that lets you do everything by pointing and clicking and picking options from convenient pull-down menus. "Look mom, I created my very own virtual method by dragging the gum drop onto the candy cane!" Ok, I made that part up, but it definitely feels like that.

In the end, the reality is that coding is hard, and some concepts you just have to wrap your head around. Alice doesn't help with that; it tries to make things easier and ends up teaching nothing at all.

A good introduction to programming should not pretend that programming is easy. It should show students that it's hard but it's not magic. It's hard, but it's not so hard that everyone can't learn it. Most of all, it's hard but it's worth it, so students need to see real and useful and cool things you can do -- and this is, I think, the most important way in which Alice fails.

With Alice, instead of doing something that could conceivably have any connection at all to real problem solving, students learn how to manipulate graphics objects in a virtual world. So basically, after the first class, they'll be able to make a badly rendered turtle spin around three times and then suddenly get very big, or something. Whee.

Sure it's done using OOP concepts, but how is anybody supposed to understand what's useful about them by manipulating turtles? Also, do you expect students to get excited about that and stay after class to keep playing?

So please, for the love of God, stay away from Alice. Python is simple and elegant, it doesn't force you to use advanced concepts early on (but they're there if you want them later), and you can do really cool things with a few lines of code. Perfect.

Java is probably ok too -- although, do you really want the first line of code you ever see to be "public static void main(String[] args)"?

Anyway. Thanks, I feel better now :) Good luck!

Slashdot Top Deals

No man is an island if he's on at least one mailing list.

Working...