This was bound to happen eventually. This isn't the only product I've bought with free upgrades for life either. I think this is about as classy a way of solving the problem as possible. Those that don't want to shell out for a new copy aren't being forced to do so, Mike's holding up his end. But if you want the what will surely be significant advantages to the ultimate edition you'll have to pay.

Redchairsoftware had a really good product in notmad which ultimately seems to have stalled out as they never resolved the issue of new purchases and then became irrelevant. Which is not something which anybody really wants to happen to Qimage.

That being said, it was perhaps in poor judgment to launch so soon with so very little in the way of additional features. Considering the lack of difference between the two at this juncture it might have made more sense to either delay or offer up a longer free upgrade period for the first few months to get things jump started with the yearly upgrades after that. And that many of us already have most of the functionality.

Indeed it is, and what havoc it can cause when dealing with passports. But, I think most people go with YYYY-MM-DD when it comes to things like this where sort order matters. The traditional ordering was from way before it made any meaningful difference. I've no idea why we do that, but since we write July 2, 2010, that's how we write it numerically.

I believe that depends somewhat on the type of formatting one does. With CF cards you should be doing a quick format, as in the format only touches parts of the disk necessary to declare it newly formatted, leaving most of the card completely untouched. Theoretically a format of that sort could be repeated as many times as one likes without damaging the data on the disk.

However that would not be the case if one were writing to every sector of the disk during the case of the format. While one can theoretically get data back after writing zeros to the whole disk, it does become a more risky proposition and at that point you may or may not be able to recover.

In the case you're mentioning, the key thing is that the filesystem information land in the same place each and every time, as any decent file recovery tool will allow you to ignore the FAT and do a sector by sector search for things that look like files.

I'd recommend getting at least 2 and keeping one in the camera at all times. That way if you ever leave with the camera or need it instantly you've got at least one card worth of storage. And once they're out of the return period, label them so you know which is which, at some point it may make a difference.

I have to admit that I kind of cringe when people suggest using canned air or otherwise pressurized air to clean a sensor. You don't have to be quite as paranoid about cleaning a sensor as one might think due to the fact that most cameras will have a filter mounted right over the top of the sensor that stays in place constantly.

However you do still need to be careful not to make the particles stick and to make sure that you're not scratching the filter. The main risk from the canned air is basically sandblasting and residue. As well as accidentally forcing particles into places in the body that they're not supposed to be.

If you're really, paranoid about dust, you can always get one of those portable clean rooms that are forthcoming. http://photipherals.com/?page_id=11

Cleaning the lenses themselves is largely another matter, you're mostly concerned about removing particles before wiping down the lens and with damaging the coating that most lenses these days have.

And neither did I, but the term is file sharing when you do that. I don't make up the terminology, there's a reason why MS and pretty much everybody else refers to those at "Network Shares."

And clearly you're not comprehending what I'm saying. SMB is terribly unreliable and while it will probably work most of the time in a home environment, you do run into these weird errors from time to time which I doubt that Flash Pipe is probably not really designed to handle. Sure it can and will double check that the files are the same, but that doesn't really address the other aspects like efficiency of transfer or proper handling of various delays and other weird glitches that the code has in it.

You want to be really sure that the local files get successfully saved and that things finished up properly, which involves operator interaction. Which obviously isn't FP's responsibility, but with something like this you pretty much have to assume that something can and will go wrong when you're supposed to have things more or less on auto pilot.

Nice to know we've made it that far, Fuji has pretty much always been my choice as far as paper goes since I started to pay attention to the difference. The metallic paper they make was always exquisite, and even the cheaper slide film was quite nice. Glad to see they've managed to bring it to home printing.

Jpeg 2000 was basically DOA, but it is nice to have support, I'm sure that there's a few niche applications where it's used. If it was going to be at all big it would've been somewhat mainstream by now. And I should point out that it's not the only designated replacement for JPEGs but it is the one with possible submarine patents on it. But that's neither here nor there.

The problem is most likely just a matter of the file extension, I'm not seeing it as one of the more or less approved extensions for the format and as Windows knows nothing of things like ELF and magic numbers that's where it gets its information about what a file is. I wouldn't surprise me if Qimage goes along with that sort of standard.

Any of the following ought to work: .jp2, .j2c, .jpc, .j2k, .jpx as they're sort of agreed upon albeit not totally.

I think though that the more important question ultimately is at what point one of the two technologies manages to outdo traditional print techniques. Admittedly I haven't been keeping up much with modern printing technology, but printing it yourself was never particularly cost effective. In general it always seemed like a waste of money when even the best printers that people would likely buy were barely keeping up with standard prints and for quite a bit of money.

Prints when stored in a reasonable fashion last a really long time and with some of the new papers have stunning results. I've more or less fallen in love with some of the newer semi-translucent papers that I've had used for my prints.

This works, you can also map the share to a drive letter as well. I'm not sure whether one way or the other has any particular advantage, but I suppose it depends on the environment. I would recommend though that anybody doing such things make an extra copy to the local computer or use a specialized utility to do the transfer aspect, since this type of file sharing isn't terribly reliable or efficient.

I'm fine with it being in some fashion optional but I really do think that it should default to downloading both of them to the same folder since it's a lot easier to delete files that exist than it is to recreate files that don't and the size of the THMs is typically small.

And of course I can do that and am, but I don't think that it's really the right way of doing it. While it's unreasonable to expect a set of defaults that everybody is perfectly happy with,  the defaults should be sane and tailored in some fashion to minimizing the downside. Given the relative small size of THM files, I'm not sure why it shouldn't just default to copying them over as well.

BTW, the article I read on it was from 2007, not that there's really any reason to update the content, as really very little has changed since then. There may be some programs that have reverse engineered the format sufficiently that they can do it. And it's really not a good practice to go monkeying around in RAW files, they're really meant to be read only, which is why QImage is so great for using it's own sidecar files to store the filters. Which is in and of itself one reason why I was so surprised that FlashPipe isn't aware of those files.

Nice article, I think that it points out a few things which have been evident for a while, if overlooked. 6MP is indeed enough for many purposes, and except for those that really need interchangeable lenses, a typical P&S is probably just fine.

The other thing though is that it's not just that more pixels aren't necessarily necessary, it's that we're going to the point now where the sensors are over resolving what the lens is capable of providing, and not just on cheaper lenses, mind you, but at some point we're probably going to hit the point where anything less than L quality is going to not really make the cut.

But then again, I'm sticking with my 10D because I really need better glass and by the time I upgrade my body, the much more important issue of noise on the sensor is going to be so much better than it is today. Even now I've seen some ISO 1600 images which were to my eye usable, not necessarily perfect, but somewhat better than my ISO 400 images off my current gear.

Eh, I don't agree. The two files both come from the camera and they belong together. The THM is where the writable meta data gets stored, and it's definitely more than just a thumbnail. That's where a lot of the information is stored and while you can regenerate them, you'll be missing potentially important information. It's also the place where applications often times store meta data since they aren't normally supposed to be able to do so with the raw file itself.

Hence, why I said that it isn't the right way to do it, the THMs are not supposed to be separated from the CRWs as that leaves you without the ability to edit any of that information without taking unnecessary risks.

If Mike doesn't want to make it default to doing that sort of thing, this really ought to be at least an option under the settings dialogue, just because of the potential for causing issues with image management.

Right one can do it, but it's really not the right way of doing it. There are a couple of problems, first off, that's not expected behavior. THM and CRW files belong together, as they each have information that the other needs most software I've used treats them as one file. And second it requires a person to specifically set it up in a way which doesn't necessarily notice if only half the files are being copied.

That doesn't work setting it to other ignores the CRWs and just copies everything else. I end up with paired files in different directories. I can set the path for other files to "Raw" and have it put them in the same place, but I end up with a few extra meta files and it's not really the right way of doing it and definitely not the most elegant way.