Gimp...

[Ysarex]

You old farts should really give Krita a shot! it's also free and runs native on Linux, has a lot of features Gimp is lacking and isn't nearly as much of a clusterf*ck from a development standpoint.

Krita is a very nice app -- excellent raster image editor.

OVERRIDING NOTE: This is a photography forum and as photographers we are better off to the extent that we can avoid ALL pixel pushing editors which would include Krita, GIMP, Photoshop, Photoshop Elements, Affinity Photo, et al.

In an ideal raw workflow a pixel editor typically adds a destructive element that makes our work no long 100% non-destructive and then forces us to create and maintain huge RGB image files -- avoidable if we can complete our editing using a parametric editor. We can't always do that and so we need to keep a pixel editor around for the hopefully odd occasion, but if we're making heavy use of a pixel editor we should re-examine our workflow.

Joe

 

[Derrel]

Parametric editing....saves TONS of space on edits...no more 128 megabyte files...instruction sets are super-small, measured in kilobytes! For lots and lots of raw file corrections! The space savings are immense!

 

[480sparky]

You old farts should really give Krita a shot! it's also free and runs native on Linux, has a lot of features Gimp is lacking and isn't nearly as much of a clusterf*ck from a development standpoint.

Krita is a very nice app -- excellent raster image editor.

OVERRIDING NOTE: This is a photography forum and as photographers we are better off to the extent that we can avoid ALL pixel pushing editors which would include Krita, GIMP, Photoshop, Photoshop Elements, Affinity Photo, et al.

In an ideal raw workflow a pixel editor typically adds a destructive element that makes our work no long 100% non-destructive and then forces us to create and maintain huge RGB image files -- avoidable if we can complete our editing using a parametric editor. We can't always do that and so we need to keep a pixel editor around for the hopefully odd occasion, but if we're making heavy use of a pixel editor we should re-examine our workflow.

Joe

I have yet to lose a sale due to a potential customer demanding NO PIXEL EDITING.

 

[unpopular]

Well, you might if they demand press-ready CMYK ... suit yourself

 

[unpopular]

You old farts should really give Krita a shot! it's also free and runs native on Linux, has a lot of features Gimp is lacking and isn't nearly as much of a clusterf*ck from a development standpoint.

Krita is a very nice app -- excellent raster image editor.

OVERRIDING NOTE: This is a photography forum and as photographers we are better off to the extent that we can avoid ALL pixel pushing editors which would include Krita, GIMP, Photoshop, Photoshop Elements, Affinity Photo, et al.

In an ideal raw workflow a pixel editor typically adds a destructive element that makes our work no long 100% non-destructive and then forces us to create and maintain huge RGB image files -- avoidable if we can complete our editing using a parametric editor. We can't always do that and so we need to keep a pixel editor around for the hopefully odd occasion, but if we're making heavy use of a pixel editor we should re-examine our workflow.

Joe

Uhm. I’m not really sure I understand. Most photoshop users will be using adjustment layers pretty heavily, and pl32 and krita even have robust filter layers that are even more flexible than smart objects. Shouldn’t this essentially serve as a non-destructive workflow? Furthermore most parametric raw processors are going to be pretty limited in their masking options, and using channel information to generate masks is an extremely powerful technique.

I would love to see a genuinely procedural, node-based approach, something like Nuke or Fusion, as a raw processor, something that would give low-level control over the whole pipeline. Layer-based compositing is super annoying and out-dated, though adobe hasn’t quite received that memo.

 

[480sparky]

Well, you might if they demand press-ready CMYK ... suit yourself

That statement just proves there's more than one market out there in the big, wide world. You have yours, I have mine.

 

[Dao]

I am mainly use my old LR v4 (upgrade from 3) with DNG converter for most photo post productions (like Derrel). I believe that was the last version before Adobe moved PS and LR to subscription based. I have GIMP and using it for other stuff which is more on graphic creation or editing purpose.

In some situation, I may need to fire up the old PS I had from within LR to do certain effect. To be honest, I have not need to use PS for my photos for years.

 

[Ysarex]

You old farts should really give Krita a shot! it's also free and runs native on Linux, has a lot of features Gimp is lacking and isn't nearly as much of a clusterf*ck from a development standpoint.

Krita is a very nice app -- excellent raster image editor.

OVERRIDING NOTE: This is a photography forum and as photographers we are better off to the extent that we can avoid ALL pixel pushing editors which would include Krita, GIMP, Photoshop, Photoshop Elements, Affinity Photo, et al.

In an ideal raw workflow a pixel editor typically adds a destructive element that makes our work no long 100% non-destructive and then forces us to create and maintain huge RGB image files -- avoidable if we can complete our editing using a parametric editor. We can't always do that and so we need to keep a pixel editor around for the hopefully odd occasion, but if we're making heavy use of a pixel editor we should re-examine our workflow.

Joe

Uhm. I’m not really sure I understand. Most photoshop users will be using adjustment layers pretty heavily, and pl32 and krita even have robust filter layers that are even more flexible than smart objects. Shouldn’t this essentially serve as a non-destructive workflow?

Almost, but the prize is 100%. The very fact that you're using layers in PS (or GIMP or Krita or Affinity) means you've already given up on the disk storage issue. For example my current camera raw files are average 48 megabytes saved to disk. When I complete an edit of one of my images in C1 my disk storage space is 48 megabytes: raw file + edit. If I create a variant of the edit (one with grain and one without) my disk storage space is 48 megabytes: raw file + edit1 + edit2. If I also add a B&W option to that my disk storage space is 48 megabytes: raw file + edit1 + edit2 + B&Wedit. Care to add that up for one of the pixel editors above (and make sure all saved files stay 16 bit in case a future change is required).

But more important is the issue of a 100% non-destructive and non linearly re-editable raw workflow.

The goal: Start with a raw file. Complete all necessary editing of the image. Retain the ability to return to that edit and make any change/adjustment/variation to any part of the editing without having to redo any or all of your work. That's possible with a parametric editor but as soon as you throw a rasterized layer into a PS et al. layer stack that goal is broken and the 100% prize is lost.

Now in your next comment below you hit on the problem -- parametric editors are more limited and can't achieve the degree of precision available in a pixel editor. That's been true but is also gradually changing. The parametric editors continue to improve and I'm to the point now that I rarely need to resort to a pixel editor to do something I couldn't get done in C1 or LR or DarkTable. I don't see that we'll reach a level of equivalent capability and so the pixel editor needs to remain available. Thank heaven I hardly need one.

Joe

Furthermore most parametric raw processors are going to be pretty limited in their masking options, and using channel information to generate masks is an extremely powerful technique.

I would love to see a genuinely procedural, node-based approach, something like Nuke or Fusion, as a raw processor, something that would give low-level control over the whole pipeline. Layer-based compositing is super annoying and out-dated, though adobe hasn’t quite received that memo.

 

[unpopular]

That definitely does make sense. And I'm finding myself not needing PS much with the latest version of LR - which is really *really* good compared to where I left off five years ago. I'll reiterate though, I wish that there was a node-based option, something that lets you dive deep into the raw processing pipeline - something that would give you very technical control even over things like debayer and interpolation so that you can fine-tune every aspect.

One thing I don't like about these "black box" raw processors is how little control you have. If you don't like how your raw processor deals with your file you're pretty much stuck. There's definitely some super interesting options on the GPL side, iirc Raw Therapee (or was it Darktable?) gives some pretty deep control, but I don't think it'll ever be what it could without a node-based workflow.

I think part of the problem is the attitude that raw files and raw processing is a "means to the end" rather than an integral part of digital photography.

 

[Ysarex]

That definitely does make sense. And I'm finding myself not needing PS much with the latest version of LR - which is really *really* good compared to where I left off five years ago. I'll reiterate though, I wish that there was a node-based option, something that lets you dive deep into the raw processing pipeline - something that would give you very technical control even over things like debayer and interpolation so that you can fine-tune every aspect.

One thing I don't like about these "black box" raw processors is how little control you have. If you don't like how your raw processor deals with your file you're pretty much stuck.

AMEN! I probably go into a cursing rampage about once a week over that. Why in the name of Heaven would I want to open a raw processing app and then have to try and wrestle back my raw file from the software engineers' attempt to make it default open and look like the camera JPEG I don't want because why else am I editing the raw file!! Bleep, bleepin' bleep bleep BLEEP!

I just had a case of that with C1. My Fuji XT-2 has a L ISO setting for 100 (base ISO is 200). Fuji does absolutely nothing in processing the raw files between base ISO 200 and ISO 100L to cause them to be different. Therefore if you manually set the same exposure on the camera and take the same photo at ISO 200 and again at ISO L100 RawDigger shows you that the two raw files are totally identical. Goodluck trying to get C1 or LR to open them and display them the same. BLEEP! Keep your bleepin' JPEG stained hands the bleep off my photos!!!!

Joe

There's definitely some super interesting options on the GPL side, iirc Raw Therapee (or was it Darktable?) gives some pretty deep control, but I don't think it'll ever be what it could without a node-based workflow.

I think part of the problem is the attitude that raw files and raw processing is a "means to the end" rather than an integral part of digital photography.

 

[Dikkie]

I'm using Gimp for years already. I even have a few scheme scripts to automate a few tasks, such as adding borders or stuff like that.

And last couple of years I'm using RawTherapee for converting RAW photos.

 

[Dikkie]

You old farts should really give Krita a shot! it's also free and runs native on Linux, has a lot of features Gimp is lacking and isn't nearly as much of a clusterf*ck from a development standpoint.

Perhaps I should give it a try.

I use Gimp as pixel editor, already long time and I have my habits in it...
And for drawing, I use Inkscape as vector image editor.

Both should be possible in Krita... wondering if a pixel and vector editor go well together in one app...
If I google comparisons for krita vs gimp or krita vs inkscape ... mostly inkscape and gimp win, also due to the bigger community behind it.

 

[Ysarex]

I'm using Gimp for years already. I even have a few scheme scripts to automate a few tasks, such as adding borders or stuff like that.

And last couple of years I'm using RawTherapee for converting RAW photos.

The problem with that two app solution and the finishing app being a pixel editor is you lose the possibility of a 100% non-destructive raw workflow and you're forced to commit to a (roughly) 75% storage increase. If you're work leaves you no choice so be it, but most general photography can avoid those liabilities by working with a parametric editor.

Joe

 

[Dikkie]

.....

Yes Ysarex, we know.
In each post where Gimp or any other pixel editor occurs you repeat this same explanation.

We know.

 

[Ysarex]

.....

Yes Ysarex, we know.
In each post where Gimp or any other pixel editor occurs you repeat this same explanation.

We know.

You know, but there's lots of new people here, like the OP, who may not know -- just trying to be helpful...

Joe