Mostly, USB cameras will work anywhere. I know only one camera that doesn't, which is a cheapo E.Image or something. It caused a kernel panic on MacOS X immediately on plugging it in. Never seen that happen with _anything_ else.

Marco

On Thu, 22 May 2003, Carol Spears wrote:

is there a list of cameras that absolutely need windows software any where online? or some good search words for google ....

carol

Marco Wessel wrote:

Mostly, USB cameras will work anywhere.

Might you define 'anywhere?' If you mean any OS, this is not correct. There are a host of usb cameras that are not supported on Linux, for example.

I know only one camera that

doesn't, which is a cheapo E.Image or something. It caused a kernel panic on MacOS X immediately on plugging it in. Never seen that happen with _anything_ else.

Marco

On Thu, 22 May 2003, Carol Spears wrote:

is there a list of cameras that absolutely need windows software any where online? or some good search words for google ....

carol

_______________________________________________ Gimp-user mailing list
Gimp-user@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user

_______________________________________________ Gimp-user mailing list
Gimp-user@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user

Most digital cameras these days behave like USB Mass Storage devices. They _should_ Just Work (tm). Perhaps this is different for non-removable media (compactflash, smartmedia, etc.) devices, but these are becoming more and more rare.
In fact, I even have a printer here that accepts smartmedia, compactflash, and memory sticks for directly printing digital photos.

Marco

On Thu, 22 May 2003, Geoffrey wrote:

Marco Wessel wrote:

Mostly, USB cameras will work anywhere.

Might you define 'anywhere?' If you mean any OS, this is not correct. There are a host of usb cameras that are not supported on Linux, for example.

I know only one camera that

doesn't, which is a cheapo E.Image or something. It caused a kernel panic on MacOS X immediately on plugging it in. Never seen that happen with _anything_ else.

Marco

On Thu, 22 May 2003, Carol Spears wrote:

is there a list of cameras that absolutely need windows software any where online? or some good search words for google ....

carol

Carol Spears wrote:

is there a list of cameras that absolutely need windows software any where online? or some good search words for google ....

Marco Wessel < wrote:

Mostly, USB cameras will work anywhere.

As Geoffrey's pointed out, the answer depends on your definition of "anywhere". The definition of "need" is also relevant...

One issue is getting the image files from the camera to the computer. Many USB cameras these days will appear as Mass Storage devices, which makes reading files off them easy. But _MANY_ don't (e.g. some of my Canon DSLRs). But that's irrelevant to me - why hook the camera up to the computer and consume its batteries when there's a faster and easier way?

With all of my cameras I read the files off the memory cards via PCMCIA, USB, or Firewire card readers. As long as the camera puts files in the standard DCF format (i.e. FAT-12/16/32 filesystems) then there are no support issues. Of course if the camera does not use removeable media then there are probably going to be some Windows dependencies...

There are other areas where Windows support comes in:

Configuration With my EOS cameras, I *need* Windows to configure things like the Contrast/Sharpness/Saturation parameter sets (on the D30) and the Owner Name field via USB. But I only need to do that once, and then I boot back to FreeBSD.

Tethered operation Some cameras can be set up attached to the computer via USB or Firewire (e.g. in a studio environment) and the captured images directly downloaded to the computer (and in some cases the shooting controlled from the computer). There is no real standard for the way this is done, so vendor-supplied software is usually your only option. For the Canon D30/D60/10D you can use Breezebrowser, but it uses Canon DLLs so isn't really a non-Windows option.

RAW formats If the camera creates JPEGs or TIFFs (at least "standard" TIFFs) then accessing the images is straightforward. Some cameras give you the ability to capture RAW images, where the camera saves the sensor's data without interpolating to full colour. The interpolation can be done on the computer later, with full control over things like white balance. On cameras with RAW formats the sensor usually captures more than 8 bits per pixel (e.g. 12 bits) and this gives you options for exposure compensation and extended dynamic range (e.g. capturing the shadows and the highlights of a sunset).

Of course the raw formats are proprietary, so initially you're stuck with vendor-supplied software. But a lot of work has been done on these. Currently I decode the CRW files from my EOS cameras with my own software (based on David Coffin's work) and then edit the resulting 16(48)-bit files in Film Gimp before passing them to the normal Gimp.

Most of the time I shoot on JPEG so I pass the 8-bit files directly to the Gimp, but life would be simpler all round if the Gimp preserved 16-bit data!!!

EXIF data Similarly, some of the shooting data stored within the image files (e.g. shutter speed, aperture, etc) is stored within a vendor-specific data area (called "MakerNote" in the EXIF standard) and special handling is required to decode the data. This isn't much of a problem though, as people such as myself fairly quickly decode and publish these formats.

What are you trying to achieve with this list of cameras? __
David Burren

The above dialog got me thinking about my Fuji MX-2700 and the program I use to download my images to my Linux system, which is fujiplay, via RS-232. This program by default saves images as *.jpeg and I believe that jpegs are lossie and therefore that I could be loosing some quality. Is this possible ? I do not believe that the image on the camera's SmartMedia is jpeg

---

Regards, Alf Stockton www.stockton.co.za
Certified Linux+ Professional & C Programmer Mustgo, n.:
Any item of food that has been sitting in the refrigerator so long it has become a science project. -- Sniglets, "Rich Hall & Friends"

Carol Spears wrote:

On Fri, Apr 23, 2004 at 11:23:32AM +1000, David Burren wrote:

Using Photoshop 7 on my wife's XP machine which is a 1.8GHz version of my System A seems OK, but I haven't done a lot of work with it as she keeps wanting to use it...

i am curious. do you think that if the adobe geniuses could make their software compile on linux, if it would slow it down.

No. In fact they've got it to compile on a Unix (ie. MacOS X) and it runs great. I don't believe it's inherent in the OS that the application is running on. I do think that Photoshop currently does a better job at managing its memory resources, but that's at the appliction level.

i am not sure where gimp is losing this "race" of yours but the fact that i can run gimp on linux and can not run photoshop (any flavor or version) to compare gives photoshop some weird edge.

Interesting. I'm sure you and I have different requirements so we'll come to different conclusions.

As an opensource developer (primarily on BSD platforms - both in the OS/kernel and at the application level) I would love it if the Gimp was able to do all the tasks I need of it.

But as a photographer trying to earn a living (I currently supplement this with short-term Perl and SQL development contracts) I can't afford to be without the tools that Photoshop provides me (the most high-profile of which are complete ICC support and 16-bit files). Now that I'm happy that OSX has progressed to a point that I'm happy to use it, the fact that Photoshop is available for it is reason enough for me to move to OSX instead of BSD or Linux.

I look forward to the day when the Gimp or CinePaint come up to speed on the features I need, but I can't afford to wait.

My observations about memory consumption behaviour between the Gimp and Photoshop have been coincidental to that. It's not the reason I started using Photoshop, but it's a pleasant side-benefit.

is the very fact that the linux community shared with YOU part of what slows gimp down?

Now this sounds like you getting all "snooty" for no good reason (these snide comments have never been good for your image Carol).

In fact I wasn't aware that the LINUX community shared with me. The GIMP community that I have been a part of for years (as a Unix user, even if using NetBSD/FreeBSD instead of Linux) has shared the Gimp with me, and I've been grateful for being part of that community.

But that's completely irrelevant to the discussion at hand...

Cheers __
David

On Fri, Apr 23, 2004 at 01:50:39PM +1000, David Burren wrote:

i am curious. do you think that if the adobe geniuses could make their software compile on linux, if it would slow it down.

No. In fact they've got it to compile on a Unix (ie. MacOS X) and

Slightly off-topic, because it relates to photoshop and MacOS X: MacOS X is rather far away from unix (or even posix), and, while the X Window System is not officially "unix", it's basically the GUI standard on unix.

So, as a matter of fact and a matter of expectancy, they didn't get it to compile on a unix by porting it to macos x.

Still, darwin supports a large subset of posix and unix, but when developing apps for it, you don't have to use it, and I suspect that adobe didn't.

it runs great. I don't believe it's inherent in the OS that the application is running on. I do think that Photoshop currently does a better job at managing its memory resources, but that's at the appliction level.

That could well be true. Unfortunately, it has been difficult so far to actually measure this. There are reports from people claiming photoshop is much faster, and reports that photoshop is slower, or that it depends on the case.

I experimented wiht photoshop about 2 years ago, and found it quite a bit less responsive on large images than gimp on gnu/linux on the same machine.

One possible reason for the perceived problems could be that gimp requires more tile cache to work efficiently than photoshop (especially multiple undo steps cost a lot of memory), and by default the tile cache size is conservative.

However, more exact and espeiclaly reproducible reports are needed to find out wether this is the case, or under what circumstances gimp gets slower.

My observations about memory consumption behaviour between the Gimp and Photoshop have been coincidental to that. It's not the reason I started using Photoshop, but it's a pleasant side-benefit.

These were certainly very interesting. Also, gimp should certainly not grow unbounded. Maybe you are just hitting a bug somewhere?