Software defaults, looks and starting points - Not software specific discussion

Processing
178

@nosle I understand where you are coming from, and I have to admit I was in your camp a long time ago, too. Give the user something “beautiful” as a starting point.

But over time I have come to appreciate things that slap the user in the face and tell them right there from the beginning:

“Dig in, you have a lot to learn, this is gonna be fun. Here is a good starting point for your creative vision. We do not try to sell you the latest in fancy, we have no style agenda, we give you a tool to accomplish your own vision. If you want pretty out of the box … go somewhere else. But if you stay with us there is a whole community of people that will help you make the best of it. And all you have to do is put in some effort.”

2 Likes
179

That’s not my camp though at least not if beautiful means punchy :slight_smile: I haven’t had an opportunity to articulate my camp because of 160 posts misunderstanding the issue, and now my rendering is coming to an end :cry:

I like @agriggio s arguments. Before I heard them I would say as “correct” as possible (obviously lots of work do define what is correct) managing highlights and shadows while respecting the in camera exposure. Enough colour and contrast to feel like the real scene.

Thanks for the “vision” it adds to an idea of an approach.

1 Like
180

There is no correct. :slight_smile:

As soon as you try to find out about good usage there will be others that have very good arguments against that because their use case differs. They even might have multiple opposing use cases.

Getting a default handle on all light situtations, cameras and their behaviour and so on is a massive undertaking. And it will have to involve automagically applying settings to images based on experience, circumstances, image analyses, content detection and so on.

Phones do massive amounts of computational photography. But even your olde (D)SLR¹ has a low resolution sensor in the prisma to record the scene, compare to it’s internal database of images and set exposure and other things on the fly long before you have pressed your shutter button.

All that to create brand awareness with the ultimate goal to earn money for the stakeholders². I do not know the numbers, but I bet you that any major camera and/or image processing software company have spent more man hours on color look branding science³ alone than what went into the software packages you’d like to improve.

And then there is the core principal of any profession: never create a feature you are not willing to maintain at least for the foreseeable future. Especially if you are doing this on your own clock.

¹) the Nikon F5 from 1996 is the first camera I am aware of that had an imaging sensor to evaluate the scene for exposure. Please correct me if I have that wrong.

²) the customers that any corporation is catering to are the ones earning money from the corporation. End-consumers are crowd sourced money providers which get a tool in return for their donation. Nothing wrong with that, but it helps if one understands where the priorities are directed to.

²) it’s working the numbers until the marketing departement approves them

181

That sounds like defeatism.

They spent thousands of hours honing their defaults, so we should spend none at all and instead languish in mediocrity.

And changing the defaults isn’t really something that requires active maintenance. Heck, it hardly requires coding skills at all.

1 Like
182

… once you have painted about a hundred bike-sheds in the process, that all have to match together, everything will be fine.

I just think it is not worth the effort unless someone comes along and really tackles that project.

Why? Because it is all opinion and no facts.

Just look at this thread, it is almost 200 messages long and we can not even agree upon a general approach.

Me thinks a topic like better defaults can only be solved if there is a very strong entity that has absolut power to cut through any bike-shedding. Otherwise it will just create discord.

183

Yes:

2 Likes
184

I usually put scare quotes around it “correct”. Which means attemting to deliver something as close to the scene as possible. Using tools and settings following best practice to achieve that and finally making careful subjective judgements with this goal.

But his assumes that a good default is about getting a pretty image regardless of what was captured. That’s quite the assumption. Lots of tools attempt to smoothen mistakes/gear limitations but how much of that to apply must be the result of discussions taking other parameters such as transparency in mind.

Current defaults exist. There is no difference. A better overview of why defaults look like they do coupled to an idea about workflow and usability brings clarity.

2 Likes
185

I think there is a difference. Open source development is based on losely connected individuals. One sits down, writes a tool, puts it out in the open, some experimenting users try it out, provide feedback from their personal usage, the developer puts a mix of all that input as a default and the software ships with it.

So individually every tool as a pretty much “correct” default.

The overall default is the result of those.

But giving all those tools a coherent and decisive default requires a dictator that decides what is good.

Or everyone can share their full default settings which they consider best and the community can vote on that or something like that.

186

That’s fine, in fact that’s what I’m trying to encourage.

187

While testing out Filmulator, I eventually discovered that we have an objective non arguable “feature” in some apps, which change the pixel size in the image, from the default captured in the raw image.

I was definitely not expecting this, and a good number of photo editors I also checked with, do NOT make any changes to the pixels, which is what I would expect.

So when you mention “default” long before we get to the look, we have to contend with some easily measurable defaults that each app has chosen to use with respect to the image pixel size, which should not be a subject of debate.

If photo apps cannot agree on the exact image pixel dimensions of a digital image, obtained from an exact copy of the raw image capture, this is the kind of challenge we still face in 2021 with digital photography.

I am shocked about this, because I did not expect it. I should be able to trust a photo app to NOT add its own impression size wise, to the image.

So lets start with the simple defaults, the easy pickings, the default image size (pixel dimensions), should be correct.

I have pointed this out to the developer of Filmulator, in pretty precise detail, at the link below, in another thread.

But Filmulator is not alone in this issue, Darktable also modifies the image pixel dimensions. RawTherapee gets it right.

Continuing the discussion from Filmulator v0.11.0 released!:

188

There is no “correct”.

afaik every tool crops into the full sensor data because the outer pixels are used for reference stuff.

1 Like
189

If you read my comments in another thread, I sincerely beg to differ with concrete evidence.

All of the following tools get the pixel dimensions 100% correct, from the raw image source.

  1. Adobe Photoshop Express
  2. Capture One Express for Sony
  3. Sony’s own Imaging Edge
  4. RawTherapee, which is open source.

This should not be something subject to debate. All other apps apps should also get this right, and at least let us know up front if thy have chosen to deviate, then we can make our own informed decision to accept their choice or not.

For me this has clearly changed my decision on which app to use as my starting point in “developing” an image from raw. I will not be able to use an app which “distorts” from the pixels captured by the camera. I must trust what I am using, espcially for things as simple and well defined as image pixel dimensions, which are right there in the raw image exif.

But of course this is Pixls, so who knows, as I have come to discover,opinions may differ!!

190

Or you discuss, perhaps on a forum, what over arching goals make sense. What principles might guide the choice of settings. What use cases and learning processes are important. What settings will give devs grief. What starting point is ideal considering all the above and how the software sees itself.

Of course someone could take it on as an issue and guide or manage it. Why a dictator?

191

I’d rather use as much of the image area as I can.

And no, they are not in the exif data.

192

They all just mimic the behaviour of the in camera JPG. If you think that is correct, then use it. Do not complain about someone giving you a choice if you do not want a choice in the first place.

My best argument against your ideal behaviour is this:

My Nikon D500 can shoot RAW in sizes L, M and S.

Nikon defines them as:

L = 5568 x 3712
M = 4176 x 2784
S = 2784 x 1856

but in darktable I get this:

L = 5596 x 3724
M = 4796 x 3188
S = 4196 x 2788

So the S in dt is larger than the M you get if you stick to “100% correct”.

How come? Because those are the “real” pixel dimensions of the raw file saved in the camera. The Nikon software reads the settings and will scale them down. Probably for processing speed reasons in the camera.

I am glad I can use software that ignores those hacks from the manufacturer and gives me the option to shave off a few hours of my editing time because the smaller files process faster. Something you definitely feel on a laptop.

193

There are plenty of reasons for the size discrepancy from manufacturing, quality or historic reasons to tradition or standards compliance to in-camera processing needs. Raw processors have varying degrees of control over this; you could change the defaults (for raw masks, crops, etc.) to suit your needs.

194

If you understand what is going on under the hood, you can appreciate that this is not clear-cut at all. What does “100% correct” pixel dimensions mean to you?

You might think that all the photosites the physical sensor has, must be the amount of pixels you see on your screen. However, some photosites produce garbage data (tbh, I don’t know exactly why). Other parts of the sensor might not even be exposed to the scene. All these garbage and black pixels must be cropped off. You don’t want the user to think about this, so it’s done automatically.
Then you might think “surely, all remaining photosites must make up the raw image I get to see on screen”. But most sensors use a color filter array, so you get raw pixel values relating to just one ‘color’ (R, G or B) for which the remaining two components must be interpolated. This demosaicing process is trickier to do at edges, so many programs opt for an automatic safety-margin of a few pixels to prevent interpolation artifacts to bother the user. The choice of how large the safety margin must be, is completely up to the developers (and some, like RawTherapee and ART, give the user control over it).
“All right, but now we must have everything!” Wrong again. Camera manufacturers may give the camera user the option to choose a specific aspect ratio to shoot in, e.g. 3:2, or 16:9, or 4:3 or 1:1 or … whatever. But mapping this ratio to the physical dimension of the sensor means that a lot of pixels are irrelevant. Those get cropped away as well. Or would you like to shoot in 4:3 and still be presented a raw file in your editor with 3:2 aspect ratio?
“I see, that’s it then”. Well, no, although this last one is more of a whim than something I know for sure. People like ‘nice numbers’, for example 4000x3000 pixels instead of 4032x3024. Camera manufacturers may process their OOC JPEGs in such a way that they end up with such ‘nice’ dimensions.

So, what’s 100% correct? I’m not 100% sure.

Eh? There are ImageWidth, ImageHeight, RawImageSize and ImageSize tags at least. There’s also PreviewImageBorders that may tell you how much to crop off.

195

Perhaps foolishly I have read every single post in this thread and it was never clear to me that the above quote was the original question. This is the closing point of the initial post:

This seems quite clear that the original purpose of the thread was to try and find a default that mimics the sooc jpeg / commercial defaults. If not exactly that, then at least to find a “better” default than what is already provided.

But as others have pointed out, there is no “better” that suits everyone or for all types of photo, so surely the simple answer is for everyone to create their own defaults/presets from what the developers choose to give you.
If darktable or RT/ART, Fiimulator or any other software does not provide a starting point that works for you, then there are plenty of other options to choose from. Is it not this simple?

It’s all well and good to want a discussion, but if this was supposed to be more of a philosophical discussion, it should have been clearer from the outset. If more of a solution was wanted, then I think there has always been one (see paragraph above).

5 Likes
196

My suggestion would be for everyone to go outside for a nice walk maybe take a few pictures have a coffee. That would be the best set of defaults for the day. This whole discussion is really pedantic and really not doing much but providing entertainment for a couple of individuals that seem to enjoy banter. 35C and sunny I’m going outside…later…

5 Likes
197

@priort I don’t agree that coffee should be the default, so maybe we need to define what a good neutral beverage should be? :smiley:

3 Likes