Does anyone else know a good image browser program that doesn't charge $50? Open-source or free = great.
That's the only reason? I look forward to your next thread, "Photoshop sucks".
Irfanview is okay, assuming you're using Windows.
http://www.irfanview.com/ - much more powerful than you'd think for something that small. Also, regardless of platform, there's always the Gimp for photo/image editing. http://www.gimp.org/
Gwenview for the win!
Needs more piracy.
No, my reasons are:
A) It crashes far too frequently to be usable as an application (I need reliability)
B) It expires after 45 days and I don't want to pay for it (I need cheap as free)
C) It takes over my entire system and whenever I uninstall it, I have to reassign all my images back to other viewers (It's bloatware)
I don't want to pirate if I don't have to.
ViX is an ACDSee clone used by many Japanese, and is free.
homepage1.nifty.com/k_okada/index_e.htm
>>6
Or... use an older version!
2.43 for the win! Yes! XD
>>8
I personally favor (and use) 3.1. :)
Later versions take forever to load or require to be in memory at all times.
I like 3.1 because it can convert BMPs to PNG, which IIRC the earlier versions can't.
ACDSee 3.1, which I've used for years and years, has only ever crashed on a few really horribly mangled images. It has never crashed in normal usage. I can't speak for the newer versions - as I said elsewhere, I've been avoiding them. The older versions will as far as I can remember ask what image formats you want it to take over, and my main complaint has usually been that it is not agressive enough in keeping them.
ViX has potential, but it suffers from two flaws:
Here's hoping the author fixes those two issues.
I've never had 2.3 or 2.43 crash on me. There must be something out there that will nuke them, but I've yet to see it.
I used to disassemble file formats. One thing I'd often do is reconstruct image headers and throw the resulting files at acdsee until I got it right.
Like a rock (it's a Chevy!).
Oh, wait, I do recall making one image that killed 2.3.
3.1 will "crash" on some jpgs that are from some digital cameras. Tho it doesn't really crash, it asks if you want to stop using that format for the rest of the session.
Using ACDSee 2.43, crashes on corrupted GIFs easily.
GIFs? who uses those?
Uh, millions of people?
I believe >>16 wasn't entirely serious there.
My 3.1 doesn't crash on bad GIFs, but one gets a blinking last frame that doesn't show in a browser. Also, 3.1 has problems rendering some optimized GIFs - the backgrounds that are supposed to be transparent are shown, and it looks ugly. Has this been fixed in later ACDSee versions, or is it that those GIFs are broken and the browsers are too tolerant?
>>18 I might HBT, it is true.
Use Picassa2 by Google
or
FastStone Viewer
Picassa2: used it, didn't like it.
For a DAM it's mediocre. Maybe in a couple more versions it'll be decent.
DAM: Digital Asset Management.
http://www.world4ch.org/read.php/img/1103952311/71,75-80
I could go into great depth about DAMs. They're the only real solution for those of us with large image archives.
> They're the only real solution for those of us with large image archives.
I remain unconvinced. I see the appeal, but I've yet to see an implementation I could get behind.
First, alwasy having to access my images collection from a single program seems limiting to the point of uselessness. What if I'm running Photoshop, and need to open up a specific image? Do I need to open up another program, find the image, have that program tell me where the image is, and navigate there from Photoshop?
I'd obviously much rather have the functionality built into the OS. But that leads to problems with moving the data to another platform later (a problem I might also have with using just a stand-alone program, of course). Mac OS X and Spotlight are working in this direction, but they're not there yet, and Spotlight is nearly unusably slow for me - I have on the order of hundreds of thousands of files on my machine, and Spotlight just crawls. If I could limit Spotlight's searching to just images, that would help, but as it is now, even if you limit it, it'll read the entire database.
Second, categorizing images with keywords or whatever puts a huge strain on the user. I have to remember the list of keywords (sure, the program can display a list of them, but to quickly tag images, I'll need to remember them by heart), and unless I design the perfect list of keywords from the start, I'll have to keep going back and adding keywords to older images when I think up a new one. Finally, I'm fucking lazy, and categorizing images is a pain.
> What if I'm running Photoshop, and need to open up a specific image?
A decent DAM does not alter the filename or its location. If you know what you're looking for, it'll be right where you left it.
If you don't know where in an archive the image is, you'll have to find that image, won't you? My archive is also several hundred thousand images strong, and finding something in there is a real pain.
I didn't start using a DAM for shits'n'giggles.
> I'd obviously much rather have the functionality built into the OS.
So would I, but it isn't.
> But that leads to problems with moving the data to another platform later
EXIF, ITPC, XMP. Reconsructing sets from metadata is simple.
> categorizing images with keywords or whatever puts a huge strain on the user.
Oh yes, it does, but I'm not aware of any alternatives. There are the image query systems similar to imgSeek, which are a great start, but I still want to attach additional metadata to an image.
Short of developing an AI, I can't see any solutions to this. Image creators can't be relied to provide the metadata, so we must do it if we want it.
Ah, as to the words used for querying: http://www.controlledvocabulary.com/
WAHa: I don't know just what it is you propose. With a statement like "I remain unconvinced. I see the appeal, but I've yet to see an implementation I could get behind." (re: DAMs), I just can't imagine what you want.
Categorising requires the user to do the work. I can't see a way around this either, short of, as already suggested, some sort of crazy AI that just reads your mind and knows how to find stuff.
Way I see it, a categorising/tagging DAM seems like the best option we have. Any sort of sorting or management system will require the user to know something about the system. There's no way around that. Mentally organising images is great, and if that works for you, then so be it, but it's going to fail when your collection gets big. It's also non-portable. :)
(I currently have in mind two "systems" I read described:
correction to point 1: I can't remember exactly how it worked, but obviously 00 to FF is not 1024 at all! It was something like that, though. Perhaps it was a hierarchy two-deep.
> A decent DAM does not alter the filename or its location. If you know what you're looking for, it'll be right where you left it.
> If you don't know where in an archive the image is, you'll have to find that image, won't you?
Yes, but realistically, I'm not going to keep both a well-organized directory structure and a metadata database. So it means that if I use the metadata, I am forced to always go through the database, since the directory structure is bound to turn into a mess real fast. And without a system-wide DAM interface, that means it's slower for me to find the images, because I have to launch a separate app to find the filename, and then navigate to it conventionally.
Now, for some images, this will still be less work than finding it manually in a directory tree, but ones image library is seldom homogenous. There are parts you use a lot more often than others, and know well. Here, the DAM might just slow you down instead.
> EXIF, ITPC, XMP. Reconsructing sets from metadata is simple.
Modifying the files seems iffy to me. I'm not sure I want a categorizing program to start mucking about with the data in the files. That'll break checksums, for one thing.
>> categorizing images with keywords or whatever puts a huge strain on the user.
> Oh yes, it does, but I'm not aware of any alternatives. There are the image query systems similar to imgSeek, which are a great start, but I still want to attach additional metadata to an image.
> Short of developing an AI, I can't see any solutions to this. Image creators can't be relied to provide the metadata, so we must do it if we want it.
All true. Which is why I see the concept as possibly being fundamentally flawed. I want something better, but I don't know what it would be either.
> I don't know just what it is you propose. With a statement like "I remain unconvinced. I see the appeal, but I've yet to see an implementation I could get behind." (re: DAMs), I just can't imagine what you want.
The only thing I am proposing is that I'll stick with my directory hierarchy, which is a deeply flawed method for organizing my data, but not really much worse than the alternatives. There are advantages to a DAM, but I don't think there are enough of them to make the switch worth it.
The biggest flaw that I can see (apart from the huge amount of work) is that I don't want to tie myself down to use some specific program. So many of these things seem entirely proprietary. I can copy my directory structure between computers and OSes without problem. I am nowhere near as sure about a metadata database.
> Yes, but realistically, I'm not going to keep both a well-organized directory structure and a metadata database.
I do both, for four reasons:
a) My DAM takes directory structure and metadata into account when querying.
b) The directory structure can't represent certain relationships.
c) I can add arbitrary additional metadata if I so desire.
d) I don't need the original files mounted anywhere on the filesystem.
e) I can access files either by DAM or filesystem, when available.
That said, I'm pretty lazy about it.
> And without a system-wide DAM interface, that means it's slower for me to find the images, because I have to launch a separate app to find the filename, and then navigate to it conventionally.
Spotlight does not represent all DAMs. I've never used it, but I hear it's poor. Don't extend your experiences with it to other packages.
With a decent DAM you don't need to navigate to an image conventionally. If I want to fire up ACDSee or Photoshop in MediaPro, I click on the image. File associations take care of the rest.
> Modifying the files seems iffy to me. I'm not sure I want a categorizing program to start mucking about with the data in the files. That'll break checksums, for one thing.
While your other arguments all hold merit, this is a bit ridiculous. Images are images, not porcelain. An image with metadata is more valuable than one without (unless the metadata is wrong... whoops). It also solves the tied-to-one-app/tied-to-one-filesystem problem.
DAMs are used by professionals, so if there was any chance of corruption, they wouldn't use it. Some DAMs get around it by only writing when they're certain the modified image is sane, others actually write a seperate file, check it, then replace.
> All true. Which is why I see the concept as possibly being fundamentally flawed. I want something better, but I don't know what it would be either.
I think we're coming from opposite directions: you're waiting for perfection, I use what's available. Nobody said it wasn't fundamentally flawed.
YMMV?
In other news, I can't count.
> Spotlight does not represent all DAMs. I've never used it, but I hear it's poor. Don't extend your experiences with it to other packages.
No, Spotlight is the one that does do just what I want - it's just too slow to be useful.
> With a decent DAM you don't need to navigate to an image conventionally. If I want to fire up ACDSee or Photoshop in MediaPro, I click on the image. File associations take care of the rest.
What if I wanted to post it on an image board? Not an uncommon occurrance. File associations won't help me there.
> DAMs are used by professionals, so if there was any chance of corruption, they wouldn't use it. Some DAMs get around it by only writing when they're certain the modified image is sane, others actually write a seperate file, check it, then replace.
I didn't say I thought the image would get corrupted. I said I don't want to change the bytes in a file, because that means the file is now different, and has a different checksum. If I was the only one who would ever use that image, it's not a big deal, but it is annoying for others if I spread it, and there are several different version of the otherwise exact same file floating around, with different checksums and sizes.
> I think we're coming from opposite directions: you're waiting for perfection, I use what's available. Nobody said it wasn't fundamentally flawed.
I use what's available too, which is a directory hierarchy. I just don't think a DAM offers enough incentives to switch to it, with its flaws.
> Spotlight is the one that does do just what I want
Yet a lot of counterexamples you bring up sound like personal experience. If it's not Spotlight, then where are you getting some of this stuff?
> What if I wanted to post it on an image board?
I can't argue that. Mind you, you'll be navigating to the directory where the image is anyway when you click "choose", so I'm not certain what the difference is.
> but it is annoying for others if I spread it
Maybe, but maybe you're increasing its value to others. Most serious users don't use hashes anyway, they use something fuzzier (OTOH, they usually don't check the metadata either).
This is a valid point though. At least with bit-identical images I don't need to eye them.
>Maybe, but maybe you're increasing its value to others. Most serious users don't use hashes anyway, they use something fuzzier (OTOH, they usually don't check the metadata either).
Possible relevant example: the duplicate image checks on *chan boards will be fooled. If everyone uses systems like these (and chan users have a lot of potential use for them, but will use individual descriptions) duplicate image checks will stop working completely. : (
Also, random question: If I wanted to transfer an entire conventional library into my computer, would I need metadata at all in order to retain the order/hierarchy?
> Yet a lot of counterexamples you bring up sound like personal experience. If it's not Spotlight, then where are you getting some of this stuff?
No, I have nearly no personal experience with DAMs, I am just making what I hope are reasonable assumptions about how they work - for instance, that you need to launch a program to use them.
> I can't argue that. Mind you, you'll be navigating to the directory where the image is anyway when you click "choose", so I'm not certain what the difference is.
The difference is that in one case I navigate to the directory, in the other I open up my DAM, find the image, find out its location in the file system, and THEN navigate to it. It adds quite a bit of overhead.
I can think of several workarounds for this (other than integrating it tightly into the OS). For instance, creating a virtual filesystem out of the keywords and such. I've not heard of anyone doing such a thing though. (And why do so many modern OSes make it such a pain in the ass to extend the filesystem? I miss my Amiga.)
> The difference is that in one case I navigate to the directory,
Which only applies if you know where exactly the image is. Otherwise you'll still be using other software, like ACDSee or Xee.
I don't think I've ever uploaded an image without using ACDSee first, even before I had a DAM (and I had nicely sorted directories and naming too).
I think BeOS had something like the filesystem you mention.
It's dead, Jim. :/
>>39
"The difference is that in one case I navigate to the directory, in the other I open up my DAM, find the image, find out its location in the file system, and THEN navigate to it. It adds quite a bit of overhead."
You could just copy the path out of the DAM and dump it in the "upload file" box. Works for me.
Virtual filesystem out of keywords: I saw an imagescript thing which used some very heavy Javascript, but notably, I think it put the attribs into the filename. I could be wrong, but that occurs to me as being painful.
I had meidokon using PATH_INFO to have a virtual folder hierarchy before, but it was too nasty to work with. Far^2 too much hacking to make it work.
>>41
Lies! LIES! :)
>>38
Provided you use an interface to maintain consistency, a seperate metadata library is nice. On one hand, you've got the standard "files in a folder", which you can transfer anywhere. You can still use them without the metadata library, but you wouldn't want to.
Then you've got the metadata associated with it, which you can move and utilise seperately.
Apologies if I'm not sounding coherent, but I hope that makes sense.
> You could just copy the path out of the DAM and dump it in the "upload file" box. Works for me.
No, I can't, since Safari has no upload text box. You're making assumptions about special cases there, and missing the point.
Okay, point noted, and my apologies. (I'm working on a mac right now; I believe you. :P)
Yes, it misses the point, so what this means is there needs to be an interface between the DAM and the "client" program. Not always possible...
Some applications might support drag'n'drop.