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

Processing
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
198

I agree you have changed my mind what was I thinking 35C here in southern Ontario so Cold beer all the way…Although if bars were open I could be found with a margarita :slight_smile:

2 Likes
199

Isn’t all the confusion in this thread due to lack of understanding of what does it mean a scene referred workflow?
EDIT: This is not a reply to @Soupy as it shows in the post (don’t know how to undo the _reply to _ action), just a general question
EDIT2: It seems to me that current darktable scene referred defaults aim just at scene reconstruction, as in

Scene Referred simply means the image data is maintained in a format that as closely as possible represents the original scene, without effective restriction on colour or dynamic range. This is not necessarily the same as the ‘raw’ image data as exported from the camera (after any necessary debayering, etc), but attempts to ‘correct’ the image to better match the scene the camera was originally pointing at, which may include white point correction, gamut correction, etc. Theses processes are often referred to as ‘Scene Reconstruction’ processes. (LightSpace | ACES)

Personally, as a non expert user, I’m totally satisfied with this when editing images in dt.

2 Likes
200

I still don’t understand what the fuss is all about. We’ve got both options in Darktable already. No one’s talking about ripping one out AFAIK or coming into your house and making you use the other one. ¯_(ツ)_/¯ As far as I can tell everyone is pro having the option for either.

Since most camera firmware is a closed source black box it’s impossible to really completely duplicate the looks in Darktable, Lightroom or on your internet connected microwave. The basecurve seems to get close enough to camera JPEG styles most of the time and that’s really all you can ask. If you don’t like or want that you can cut it off and be happy with the flat look starting point. What are we arguing about again?

Edit: if you really want to see post processing software freak out and screw the pooch try processing stuff lit in the UV or with strong gels. Wooo boy nothing knows what to make of that and you have to make your own style and row your own boat there.

3 Likes
201

After reading 200 posts on this matter, there is little that hasn’t been discussed.

I will add one thing, however: There are plenty of commercial and noncommercial alternatives to Darktable. If Darktable’s defaults are not to someone’s liking, use one of the alternatives.

Personally, I am not a fan of a neutral, flat default, and often don’t have the time to invest into image editing as Darktable so often requires. Which is why I have taken to use a different software, that suits my (current) needs.

Which, honestly, can feel a bit like betrayal. “Why can’t this tool, which I have invested so much time and effort in, sserve my purpose?”. But this is the wrong conclusion to reach. I learned an enormous amount in my time with Darktable, and wouldn’t want to miss that experience for a second, even though it has led me away from Darktable, at least for the moment.

And quite frankly, there are enough opinionated, “automatic”, “easy” tools out there already, Darktable does not need to become another one. I’d rather it be its own thing, even if that particular thing is not perfect for me.

7 Likes