I think still there is this thought or mindset out there that the raw is just a better version of the jpg “waiting” to happen and that the role of the raw developer is to reproduce that and then let the image be pushed from there harder than the jpeg. When this is not the case then there is criticism. As many times as you say it that a raw file is the merely the digital data captured by the sensor I don’t think the reason for shooting raw with many people is actually to target that feature because they want full control…people really are after a superior jpg… of course this is a blanket statement but as you see the questions regarding the mismatch of raw and jpg over and over its hard not to think this is at least a bias that exists
3 Likes
I agree, completely. If I simply wanted to mimic the OOC jpgs, I could dispense with all of this and just use OOC jpgs.
1 Like
To expand on @priort’s point, a lot of people come to RAW editing from jpeg editing. They take some snaps that they’re not 100% happy with and do some basic tone curve or levels adjustments to the OOC jpeg in GIMP. Then they read somewhere that so much more can be done with RAW files. But somewhere along the way they miss the point that the RAW file is a different beast and that the jpeg already has a lot of processing baked into it, which they now need some skill to reproduce.
It’s understandable that, coming from the “RAW=better” expectations, they will be disappointed that, at least to start with, “RAW=worse”. We just need to keep offering encouragement, user-friendly documentation and suggestions and have some sympathy with the learning curve that we’ve all at one time had to grapple with.
5 Likes
Well stated and one small thing to add. I have pushed some really old crappy keepsake JPG files to much better versions with DT tools. Corrected bad WB, tweaked blurry ones …improved overall tone and contrast and I am talking about 10 year old 3mb jpg’s . So I can only imagine that many people with a newer camera shooting jpg at the highest quality will still have considerable room to improve those files at least until they develop a knack for raw editing and maybe that will be a better overall route for many if they like the camera result and take a great photo…maybe an edit to the jpg will be more suitable and closer to what they expect…
I’m not convinced by this or at least not 100%. I think people understand that RAW is different but somehow they think that JPEG is the canonical view, it is the truth, it represents the scene perfectly. And all those assumptions are just plain wrong.
The jpeg from Canon, the Jpeg from Nikon, from Sony, the DNG or any RAW are just a representation of the scene and all of them are just that. A representation with all the bias coming from the sensor, software, lens… etc. So at the end there is no truth, and one must do the work to create its representation of the scene, another one with the bias of the photographer and this is at the end the beauty of the photography !
And remember even your brain is not the truth of the scene you have seen as we have all a different representation of the colors.
1 Like
I agree with what you say but I think there is still this sort of underlying thought that if you have a profile or whatever that the raw software can and should recreate the jpg that came from the camera and then offer the ability to further "improve " on it …almost like a raw is a 16 or 32 bit tiff with the transfer function of the camera baked in but with a bit more information to edit it in shadows etc…basing this on comments and or threads like this one…again focused on reproducing some part of a jpg look…RAW sharpness with darktable
- the camera firmware has a lot more information about the scene than what we have in darktable,
- as such, a purely programmatic way of producing a quick JPEG preview has more chances to succeed if it is done by the firmware rather than by any third-party raw editor,
- plus, the camera JPEGs are already used as proofing views during the shoot, so the photographer can adjust them for clarity if needed, right on set,
- the purpose of the OP is to not spend a single billable minute on editing pictures that the customer has not explicitly approved because time is money. So the goal is to let a 100% programmatic method deal with the communication of proofs, get customer feedback, and invest editing time where there will be profit.
- it is super efficient to extract the JPEG thumbnail from the RAW from darktable’s lighttable, since the consistency of metadata and names can be kept between both. So when customer says "please edit
shoot-client_DSC0018.NEF", darktable knows what picture it is and where it is. exiftools is not a workflow app and has no such link between database and extracted thumbnail. And again, from dt’s point of view, it’s a simple matter of doing an export pipeline that only reads the thumbnail in the EXIF and writes that in a JPEG buffer. - shooting EXIF+JPEG for that purpose is overkill and tends to increase buffer I/O thus lags during the shoot.
It’s a professional workflow here. In that context, efficiency is key and pictures are products. We are not talking about enthusiast photographer looking to milk the JPEG for cheap editing shortcuts.
Photography is already a scarce and unfair business, who are we to ask professionals to spend more time on unpaid work ? Again, the request here is perfectly legitimate.
BTW: the old in-focus preview in darktable already uses the JPEG thumbnail.
6 Likes
Good context…reviewing the thread I think we got a bit off topic of the actual question…
2 Likes
It’s a skill set of mine… 
1 Like
I think it is because this is what people see when they are taking the pictures.
While I agree that in the film generation there was no preview at all. In DSLR and mirrorless - I don’t recall seeing anybody who would completely ignore the previews on the camera’s lcd.
The cameras have different profiles portrait / scenery etc. Looking at these previews is what guides a few people in deciding if they like the photo (as a starting point).
With proprietary software - often the user is given the option to apply the manufacturer’s preset then tweak on top of that or completely ignore the preset and start from the beginning. I don’t think we have such an option in DT. So the path forward is always start from beginning.
Personally - I accepted this approach. There have been a numerous times however when I end up asking myself - what did I like about the picture when I took it. The OOC preview is generated, it is there and I would have liked to see it - not all the time but as an option. I can live without it and it is not a show stopper for me. But if such an option exists - yes I would appreciate it. At the end - each user is different. I understand whatever one likes maybe not relevant to another.
4 Likes
Thank you for understanding and verbalizing 100% accurately what I was trying to explain and say. I have literally nothing to add to that except I think you meant shooting RAW+JPEG instead of EXIF+JPEG in the point 6. Otherwise, perfectly explained!
1 Like
Sorry this is wrong as I explained already. i’ll stop this discussion it is going nowhere.
@vbs You get the idea for the second use case I was proposing.
If it’s there, then why hide it? Someone might make good use of it. If we can take a peek at those previews while shooting, why not while grading?
And to add to this, those previews are useful for color grading. Some people prefer to keep the “Camera look” and grade the raw in that direction on some images.
I may be oversimplifying this but; just ask videographers why do they prefer one camera over the other and why do they like Canon or Ari colors etc. It’s their interpretation of the captured light, their “color science”, their color tones and light tones. And since ppl mostly shoot log, they provide a LUT to give you that iconic look as a quick starting point.
So why not have the option to just see that embedded preview image of the look people spend their money for. And if you don’t need that then you don’t have to see it, just don’t click it (the imaginary show embedded preview button).
It’s not like we need a new complicated process to create those images automatically, they are already there and available in your raw file even if you don’t like the OOC preview grade. You are already storing them anyway in your metadata weather you like it or not.
Because they buy a camera for its “color science”. And because why not? It’s there and available, isn’t it? We’re storing it weather we like it or not. We might as well use it for something if we want to. And people have different grading practices. Videographers often use a particular camera for its colors or tones rendition in video. Photographers are not immune to that with photos.
No one is stopping the color grader from going their own way or suppressing their creativity. It’s just there to provide the manufacturer’s and the firmware’s “opinion” in addition to camera’s (a raw file without a grade).
But this thread is actually more important for the use case that @anon41087856 explained better than I did. And that would be imo the best use of those jpegs. It has almost nothing to do with actual art of color grading. Just a huge time saver before the actual color grading.
This is pretty much a done issue, right? It already exists as a lua plugin, and IMO, this is what the lua features are for, growing the editor into what you want it to be without bloating up the main code base.
@wpferguson has done a nice job with the lua stuff, thanks!!
3 Likes
Clearly not an issue, just an exchange of ideas. Don’t mistake this for a GitHub feature request. It’s a highly unpolished thing. People coming with different ideas, views. Some negative, some positive. Hence posting on a forum, not GitHub issues.
Yes, for embedded preview extraction and importing. As far as I can tell the discussion kinda went outside of the scope of this plugin and went into should we or should we not use those previews and what for to identify all the potential use cases just so we can gain some more perspective.
That’s a highly subjective opinion. Clearly there are both opinions for and against the idea.
A nice job indeed 
Good point.
Also fair. One person’s bloat is another person’s must have.
I still think this is what lua is for in darktable, and I say that as a person who has been struggling to modify a lua plugin to get it to for what I want ;D
Thanks for your reply. I remembered this setting and double-checked that it is off (and I found out that the disk backend for full preview was inactive). Nevertheless, when culling it seems to me that the embedded jpeg is not used for images, which have already been processed, and they seem not to be used, when I zoom into the image.
The embedded jpg is used until you open the image in darkroom. At least this is how it works when scene referred workflow is selected.
No, the behavior is controlled by an option in the preference.