JVC Everio GZ-MG575 review

Last week, I bought another camera: the JVC Everio GZ-MG575. It set me back € 995. I'll be returning it today, and I do not have time to write a full review like I did with the Panasonic NV-GS320. But I can give you an impression. Short story: Do not buy this camera. Ever.

Contents of the package

Apart from the camera, the most important part is the dock, which connects to the through a single connection at the bottom. There is the mandatory remote control (including battery). The Dutch manual is translated quite badly and there was no English version in my package. There's an USB cable, an A/V cable, a power adaptor and a shoulder strap.

Picture quality

The picture quality is reasonable, but not outstanding. Widescreen is fake, simply chopping off the top and bottom of the picture. Instead of making the view angle wider, it is actually made less tall.

The picture looks a bit greenish, and there's no setting to correct for this. It is not a matter of white balance.

The (digital) image stabilizer only works if your picture is already nearly still, and even then results in a motion that feels choppy. Once you've worked with an optical, physical stabilization system, you realize how much better that works.

Autofocus is very slow. It focuses solely on the centre, and does not pay attention to other factors, so apart from slow it is also stupid. As is to be expected without an optical viewfinder and a lens ring, manual focus sucks. Your only option is to point where you want to focus, wait for autofocus to kick in, then switch to manual focus to lock the focus.

Auto white balance detection is reasonable, but… it is not smooth. When walking from inside to outside, for example, it will instantly switch the white balance from indoors to outdoors. Something you definitely do not want.

Low-light performance

I haven't tested the low-light performance, but I expect that it does a pretty good job here, judging from the large lens opening.

Photographs

In a well-lit room, with big windows and a lot of outside light, setting the aperture to F3.5, the camera tried to use a shutter speed of… 1/5 second. In case you're not into photography: it will be impossible to get a sharp picture at that speed, and even cheap and crappy compact cameras like mine do a lot better. I did not bother trying to take any more photos after this insanity.

Audio

I haven't tested the internal microphone thoroughly. If it turns out to be crap, you at least have the option to plug in an external microphone.

Recording medium

The camera records to a hard disk. Compressed like a dvd. Even on the maximum quality setting. You're probably going to export to dvd sooner or later anyway, so it may not be a big problem, but I like to start with the highest possible quality of material.

There's also an SD card slot that I haven't tested. Apparently you can record photos as well as video to this card.

LCD

The LCD has a pretty limited view angle, especially in the vertical direction. I haven't tested it in direct sunlight, but if it fails there's no viewfinder to fall back on.

Usability

The user interface is downright horrible. Let me give you an example. When set to manual mode, with the little wheel at the top, you can switch to manual focus by pressing the joystick downwards. Now switch to, say, S mode where you can set the shutter speed. Manual focus is retained. But you set the shutter speed—you guessed it—by pressing the joystick up and down: you can no longer turn off manual focus!

The menu wraps around like a cilinder, so you don't know when you've seen all options. All menus are animated, and rather slow and annoying too.

All buttons seem to be in just the wrong places, and there's no way you can control this camera with one hand. Many buttons have different functions depending on the mode. All of it just fails to make sense.

There's a “drop detection” that will shut down the camera when it detects a falling motion, to protect the hard disk. It also shuts down if you simply lower it a bit too quickly. So I turned the feature off; the best way of keeping your hard drive intact is still simply not dropping it. But at startup, the camera keeps warning me that drop detection is off, and an annoying blue icon keeps flashing on the screen all the time.

Battery life

I'm not sure how this compares to other hard disk cameras, but in itself, I found the life of the accompanying battery quite limited. Apparently there's a good reason that the box (that you see even before you buy the thing) already states: “Don't Forget A Back Up Battery!”

Capturing and editing

Here's a point where I do like this camera. It comes with a dock, to which you can connect a power supply, USB, FireWire, S-Video and AV. A welcome change from having to plug in two or three cables each time.

The camera shows itself to Windows as the hard disk it contains. You can simply copy off the .mod files. These are, according to the manual, a “proprietary format”, but actually they are simply .vob files like on a dvd. After renaming, Premiere has no problem importing them. No external software is needed.

I had expected editing to go less smooth with compressed material, but I haven't noticed anything of the kind. It all works just as well as with raw DV videos, as far as my (admittedly quick and short) editing session could tell.

Conclusion

Horrible usability, and the picture quality does not make up for it. Do not buy. Definitely not worth your money. I'll be going back to my good old Panasonic, external microphone input or no.

Side note: during the entire time I'm writing this, the camera is erasing its hard disk. Although it says “formatting”, I hope it is actually overwriting all the bits seven times, because nothing else accounts for half an hour of formatting time…

Equality checking on interrelated objects

Most, if not all, object-oriented programming languages allow you to define what it means for two objects to be “equal”. In C# and Java, this is done by overriding the Equals or equals function, respectively.

But what to test when comparing two objects? You'll obviously want to compare (most) instance fields, for example the name of a person or the number of wheels of a car. But it's less obvious when an object is (conceptually) part of another object, or dependent on it in some other way. I ran into such a situation today.

Consider the class Pig. A Pig is associated with a Farmer, the owner. Each farmer has, in turn, a list of ownedPigs. (I use Java capitalization conventions here to make a clear distinction between types and fields/methods.)

Suppose we want to check whether two Pigs are equal. (Do not just return true. Some animals are more equal than others.) Clearly, two Pigs are not equal if they are owned by a different Farmer, so we need to compare their owner fields. Reference equality on this field is not enough: if we can have multiple Pig objects representing the same pig, then the owner fields may well refer to different objects representing the same farmer. So we do a value comparison of the owner fields, by calling owner.equals.

Of course, two Farmers are not equal unless they own the same Pigs. We have to call Pig.equals for each owned pig. This, in turn, calls Farmer.equals, which calls Pig.equals … and so on ad infinitum (which is Latin for “stack overflow”).

How to solve this problem? The key is, when equality of type A depends on equality of A's fields of type B and vice versa, to check not the entire B objects for equality, but only compare the parts we're interested in.

For example, a Pig couldn't care less what the social security number of its owner is. It does, however, care where he lives: a pig on the South Pole will have very different life circumstances from one in the Sahara. In Pig.equals we would then only compare the addresses of the owners, and not the entire Farmer objects.

With this modification, the cycle is already broken. We could also tackle the problem from the other side: the Farmer cares only about how fat his pigs are, but not about their political preference. When comparing two Farmers we could look only at the weight of all their ownedPigs, disregarding their vote field.

I admit this example is a little contrived. I'm not programming an animal farm. But if you ever do, and your Pig.equals method gets called with a Farmer object, remember to return false.

My goal in life

The standard impossible-to-answer philosophical question, which has become very much a cliché, is “What is the meaning of life?” I've answered this for myself ages ago: life has no meaning by itself. Everybody can create as much or as little meaning for his or her own life as they please.

It helps to have an ultimate goal in life. For every decision you need to make, you can check whether it aligns with your life goal. Having a goal also gives your life purpose and motivate you to keep going.

When I read a post by Steve Pavlina a couple of months back, I was reminded of this. What was my goal in life? Steve suggests to write down potential goals until one makes you cry — that is the goal you're looking for. I discovered I didn't need this: the answer popped right into my head, and had probably been there for a long time.

All that remains is to write it down. My goal in life is to continuously keep improving myself, and thereby the world around me.

I'm a pretty altruistic person. Yes, I want to improve the world. But I also have a selfish part. I want to grow, to learn, to become a better person in every sense. These goals don't have to be in conflict. A “good” me also cares about his surroundings, helps other people, tries to make a difference for the better. That's the person I want to be.

Checks, exceptions and assertions

When programming in most modern languages, there are basically three different ways to deal with errors or abnormal situations: checking, exceptions and assertions. However, some people seem to misunderstand when to use which.

A check is the oldest trick in the book. It's simply an if (or equivalent) statement that checks whether a certain error condition holds. An exception can be raised (thrown) at the point where the error occurs, and then handled (caught) by any function lower down the call stack. An assertion is also a sort of check, but usually in the form of a library call or a language construct. A failed assertion usually results in terminating the program. Assertions can often disabled by a compiler parameter.

Now here's the flowchart that'll tell you which way of error handling to use:

1. Do you think this error will ever occur?
   1. No » Use an assertion.
      Assertions reflect a claim made by the programmer: “this will never happen”. If it does happen, it must signify a bug. If you use assertions for anything else than validating things that you think must be true, you're using them incorrectly. Also, it's perfectly okay for a program to abort (with a meaningful message, mind you) when it encounters a bug during testing.
   2. Yes »
      Will this error occur in normal circumstances?
      1. No » Use an exception.
         Exceptions are made for, well, exceptional circumstances. They're meant for situations that you overlooked, or chose to overlook because they seemed (rightly or wrongly) rare enough that a check wasn't worth the effort. The great thing about exceptions is that they can be handled at a much higher level than the place where the error occured, a power that simple checks don't have. You can use this to catch the rarer errors at a high level, not having to scatter error checks all over the place.
      2. Yes » Use a check.
         Verify whether a file given on the command line exists. Do make sure that a person's last name does not contain any quotes. These are things that are actually expected to fail occur once in a while, even under normal circumstances. You can nearly always handle them locally, so there is no need to throw an expensive (performance-wise) exception around.

It's quite simple, really.