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.
Thing is, if the main use case for those extracted previews is “fast presentation to 3rd parties”, then there are already adequate independant tools for at least ms-windows and linux. Which diminishes the need to have that capability built into dt.
Add some scripting, and you could automate a few more things, like:
- resizing, adding watermarks,
- adding metadata : ownership, granted rights (none…), intended receiver, project, etc.,
- moving to a specific directory (to avoid “polluting” your raw directories with the preview jpgs).
Although this is perhaps easier under linux than under ms-windows or macOS.
Such a script is probably faster than using dt, if the aim is to get the jpgs to the client asap (no need to import the images into dt first).
I need to figure out Lua as well…likely easier on Linux but I have not tried to get it running in WIndows…I was thinking of using the external editor script to run something that had a print function as a way to introduce printing to the windows version…not a need more just proof of concept and occasionally useful…
Should I write a tutorial?
6 Likes
Well it would likely benefit a number of people but I always hate asking people to do something until I have made a good effort….lets just say I wouldn’t mind if you did and thanks for the offer……
2 Likes
I wouldn’t mind it either 
Rawtherapee uses embedded jpeg for preview (culling). It’s times, times faster than loading and processing every raw before showing. That’s the reason why I still use two tools in workflow - I select&pick&delete images in RT, then load whole directory to DT for final selection and processing. If I had an option (OPTION) to use embedded jpegs in culling mode…
1 Like
DT does unless you load into Darkroom then it processes…setting is in preferences to use embedded jpg or 1/2 raw…