GIMP Resynth vs. Photoshop Content Aware 269
aylons writes "Just after Adobe released videos showing off the content-aware feature of Photoshop CS5, the GIMP community answered by showing the resynthesizer plugin, which has been available for some time and can do a similar job. However, are they really comparable? (In original Portuguese, but really, the images are pretty much self-explaining.) Compare them side by side removing the same objects from different kinds of images. Results do vary, but the most interesting part may be seeing the different results and trying to understand the logic of each algorithm."
Re:I'm sure... (Score:5, Interesting)
Re:I'm sure... (Score:2, Interesting)
It is plugin. As such, you have to know it exists in order to get it.
I even know it exists, what it's called, where it's website is, and I still have no idea how to download or install it. I've been using Arch Linux for several years, I can build packages, I can do ./configure or ./autogen.sh installs, I'm not retarded. I admit I haven't done much looking into it, but I have no idea how the plugin system works on Gimp, and it certainly isn't intuitive. I would say the barrier to entry for this functionality is even higher than you suggest.
OT: GIMP scaling seems broken. (Score:3, Interesting)
I know this is off topic, but I am not going to bother joining a GIMP forum.
I installed GIMP (windows) yesterday. I wanted to downscale some images and do a light USM, but GIMP downscaled images came out looking over-sharpened before I even got to the USM step. I know downscaling does make images appear sharper if the original was a bit soft.
But this is compared to downscaling in other programs. GIMP output looked over-sharpened with artifacts.
I could find no setting that indicated it was doing any USM on scaling, so I promptly un-installed GIMP, since it can't do something this basic without degrading the image.
Re:I'm sure... (Score:5, Interesting)
People will find a new pet issue to criticize. What most of them really mean is "I don't care, I don't want to try anything new", but that doesn't sound good, so they will always find a new issue as long as GIMP isn't a carbon copy of the latest version of Photoshop. For the record, there are no serious UI issues beyond it being unfamiliar, there is a ton of minor ones, but to see them you actually have to spend some time with the program, so unsurprisingly they are not the target of much criticism.
Oh dear, TWO people reading what theywant (Score:1, Interesting)
Oh dear, TWO people reading what theywant. Please tell me where I said that all printers will do RGB? And, please, tell me how wrong it could be for a printer to use, say AdobeRGB or sRGB as it's colourspace and then render that, thorough THE SAME FRIGGING PROGRAMS that do RGB->CMYK on your calibrated print into CMYK could be absolutely wrong?
If anything, since this would be a million-dollar printer for long runs, getting the most expensive and well tested RGBCMYK conversion would be a trivial thing. It's not like it has to worry about phosphor changes if you're using an iliama or Sony CRT or crap like that.
So WHY wouldn't you trust the printer of a professional printing company to do RGB/CMYK mapping but you WOULD trust the free software your monitor or printer manufacturer gives you to make RGB/CMYK conversions in your work?
I'll give you the simplest explanation: it allows you to ignore GIMP because it doesn't do CMYK.
I also note neither of you had anything saying that PS wasn't good enough for professional work before it got CMYK...
Doodads are great (Score:3, Interesting)
I am a proponent of FLOSS and I want the gimp to be great. But it does not matter until Gimp gets the basics right. Until the underlying pixel engine of Gimp can give Photoshop's pixel engine a run for it's money then the gee wiz features don't mean squat for anyone trying to do real work. Bottom line get back to me when the gimp can do full 16 bit per channel images throughout the entire program as quickly and efficiently as Photoshop can.
This is one of the biggest problems with FLOSS the volunteer programmers go and work on the neat gee wiz stuff because that's whats more fun and easier. Getting people to do the hard unsexy stuff just does not happen in a timely fashion. The number of people who are good enough at the engineering to build a really solid pixel engine are quite rare. And the number of those people who are willing to do that in their free time gratis appears to be even more rare. I say this in a goading manner because I want someone to take up the challenge.. someone that can really make that happen.
I smell FUD... (Score:3, Interesting)
Re:I'm sure... (Score:3, Interesting)
I've logged way more hours (as a hobbyist) in GIMP than I have in photoshop. I still dislike it mostly for the window management (which i've heard is better or at least changeable recently, but I haven't had a reason to go check) but a lot of other things (eg the file saving process) strike me as clumsy.
On a non-UI note, I wish it'd use multiple cores the way Lightroom (and I presume photoshop) happily will.
Re:Moot point (Score:3, Interesting)
Damn right, people are completely unaware of exactly what increasing the number of bits in a fixed-point format will do. They are assigning magical properties to it. It does nothing except make the problems a bit smaller and harder to see, possibly hiding them until it is too late and they bite you.
If you are using 16 bits on modern processors you should be using half floats, representing the linear value of the color (ie double the value makes the image twice as bright or doubles the exposure). Using integers means you are living in the past, floating point has been faster than integers on modern CPUs for 10 years or more now, and hardware support for half floats is on most GPUs now and will probably appear in CPUs very soon.
I have no idea what GECL (sp?) does but I do hope they have seen the light and support half and full float data as linear.
8 bits encoded as sRGB is a nice compression format and there is nothing wrong with supporting that. But taking this flawed format and pretending that wasting more memory on it will "fix" it is stupid and shows that you have not studied the problem at all. But photo professionals have proven to be stupid over and over again, just look at them regugitating the same junk right here, whether they want to insult Gimp or Photoshop.
Re:I'm sure... (Score:4, Interesting)
If 'some time' is more than 10 minutes.. sure.
I use The GIMP. A lot. Almost exclusively, in fact. My secondary editor? Picture Publisher 5.0a from 1995. It's 16bit. No, that's not the color bitdepth - that's the "Was made for Windows 3.x" bit. Only reason is because it still does some things better/faster. (Tertiary is a toss-up between several.. actually, if IrfanView would count as an 'editor', it'd be 3rd).
I'm familiar with its interface, I'm familiar with how it differs from Photoshop, I simply moved the floating dialogs around on the screen with a big central window to get a more familiar feel.. no problem.
But it still only took me 10 minutes to realize there's a -huge- UI-related workflow issue with The Gimp...
No. Unified. Transform tool.
In The Gimp, you may:
A. Scale
B. Rotate
C. Shear
D. Distort (called the Perspective tool, but as each corner point is independent, I'm not too sure about that term).
Pick any one - but only one.
No, you can not scale down -and- rotate*. You can scale down - and then you can rotate. Two operations - twice the filtering. In fact, you'd probably want to rotate first, and -then- scale, just so the rotation operation has more data to work on for a higher quality result.
( * unless you want to get crackin' with a calculator and determine the new corner pixels and use the Distort (perspective) transform. )
Apparently it's on the list for 2.8 - so here's hoping.
( I'd point to the gui.gimp.org topic on the unified transform tool, but that site is - once again - blank. )
Ideally it would never actually put anything into pixels until you requested it to be (so that a layer scaled down to 10% and then back up by 1000% would simply yield the original image give-or-take some float precision errors), but that's much further away and not really UI/workflow related.