What if you shoot raw and JPG and use colors to flag them …if need be use the JPG to cull then color flag the ones you water mark and send out. When the client selects add a second color as keepers and then you can filter on your original color to delete the ones you don’t need…or some version of color tags to allow you to clean out ones you don’t need??
I would love to see an option when I can use the embedded preview for comparison purposes. I am not targeting to create the same exact image as the jpg but sometimes what I see (and like) during the photoshoot is lost completely when viewed in DT. Even if I am not to target the exact processing as in camera - having something to remind me what exactly did I like when I was taking the picture would be really really nice.
3 Likes
I feel like the idea is reasonable, and is reasonably stated. It is certainly not one of the “developers must do this because I know better” kind of rants we’ve all seen. It’s framed as a real life use case, and examples are given that can work for people within different contexts.
Everyone has different ways of doing things, and sometimes that’s because of different needs and constraints (like time and obligations, not compute power).
Even knowing I could use a command line tool to do this doesn’t mean I’ll ever bother. If I want to grab a few dozen photo sub-set of a shoot via GUI, and rapidly upload already-processed pics somewhere (because I won’t have time to do the raw processing for another few days), I don’t want to have to shoot (and store) raw+jpeg to have that option.
And I don’t have to. Because I do just about what he’s talking about using digiKam and batch queues. I’m not planning to ever need to shoot raw+jpeg again.
I like using digiKam and darktable (and ART) in parallel, but that’s not what everyone wants, and darktable does a lot that I skip because I do those tasks in digiKam. It’s not my impression that this is the developers’ intent. If time and effort to add this were available (and sadly, I am useless there), I feel like it would be a net positive. Not the end of the world one way or the other, but I like the idea.
2 Likes
I agree with this too. Even back when using Lightroom I used to be frustrated that I couldn’t at least look at the camera’s version. Sometimes it’s nice to have a reminder why you went “wow” looking at the preview image when you first took the shot. It’s also nice for inspiration when it comes to working on the colors, similar to how I’ve been using haldcluts recently.
This is why I have digiKam set to only show embedded previews, and I sometimes flip between them and the photo I’m processing in other software.
It sometimes also helps me spot when I’m the cause of visual artifacts through incorrect processing as opposed to something in the photo. I have a playraw submission recently with a situation like that.
1 Like
The use case here is professional: send proofs ASAP to client. Forget about visual consistency, it’s really just a business/efficiency thing: send previews to client, ask him the ones he wants you to edit, and spend time only on the pictures he actually likes. That’s images for communication purposes, like a contact sheet. Nothing related to actual processing, the purpose is actually to avoid spending time on processing the pics until the client has approved them.
I totally get it, for someone billing time, it makes sense.
2 Likes
One additional problem with relying on embedded JPEGs is that their size and quality can vary a lot between cameras. Some cameras embed positively tiny previews.
There’s actually a third option which I use: Create a style that very closely matches the camera JPEG. I wrote a program that uses data from a bunch of photos (raw + camera JPEG) and calculates a 3d lut to match the colors… now I wonder if other people might be interested in that tool too (unfortunately it’s really far from easy to use).
(I talk about it here: Fujifilm X-H1 Astia HaldCLUT - #6 by sacredbirdman)
5 Likes
This will take much more time to compute and export.
Do you ever plan to release it? The comparison of images that you show look amazing. I’d love to have a 3d lut like that for my cameras. Really cool stuff!
1 Like
I’ve tested a bunch of different raw files now for various OEM. Most of them contain either JpgFromRaw binary or a PreviewImage binary or both. In any case both JpgFromRaw and PreviewImage are completely usable even with cropping.
Fun fact. Canon EOS R5 produces 60.7MB CR3 file that contains a 6.7MB 8192x5464 pixels JpgFromRaw, a 430,8kB 1620 x 1080 PreviewImage and a 17,5 kB 160 x 120 px ThumbnailImage.
Another question. I understand that PreviewImage is used by software like DigiKam to preview, profile the images. But what is JpgFromRaw used for in software and in general? Are apps using that for previews when HiDPI monitors are in use?
It seems like it ought to be used for instead JPEG+RAW shooting?
Now that you said that…even a Canon M100 produces a 29.7 MB CR2 file that contains a 3.94 MB JPEG with 6000x4000. I never thought it would save such a big JPEG…
ERawP seems to work very efficiently.
1 Like
… but that’s what i’m saying (minus the business): the discussion goes away once you can do some default raw processing quickly enough. and that’ll be consistent with raw processing and the same for all cameras.
2 Likes
One way I would love to make use of embedded jpegs is fast culling. (Or is this already possible and I never found out how?) One reason I rarely make use of the culling mode is that it feels pretty slow, even on my desktop. I think using the embedded jpegs might speed up culling pretty much (particularly when zooming in) and in general they are good enough to judge the image and to choose between similar images.
2 Likes
This is already possible if the option “Use half sized raw instead of jpeg” is unselected.
2 Likes
This is not a way to see what you liked about the scene but what the camera think the scene was. Quite different and certainly of no interest for me. The camera rendering is just another view of the scene and not the reality. Same for the RAW edited in dt or whatever. The work as RAW developers is to give your view (not the Canon, Nikon, or whatever) of the scene and possibly taking lot of liberty about the final color.
BTW, RAW processors have not invented something here. At the time of the film roll there is none to give you the reality, Kodak, Fujifilm had all a special look.
I’m still wondering why people keep insisting of viewing the camera jpeg !
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