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…
No the reason is that you have not read the dt doc!
1 Like
Effect of using Alt+W (fullscreen sticky preview) - utilizes embedded JPG, very fast but look at these pixelized artifacts, especially strong in contrasty parts:
1:1 screenshot, view after click:
Impossible to evaluate sharpness, even roughly. Ergo - usable only to delete absolutely bad shots.
When user wants to view fullscreen 1:1 preview (“z” shortcut), DT processes RAW. And (why?) it takes 2-3 times longer than opening ing darkroom mode. No option to view embedded JPEG 1:1 even if “dont use JPG preview” option is off.
Worse - it’s rendered with so strange artifacts that picture looks like scratched with comb:
Crop from “full view”:
Veery slow (2-3 times slower than “culling” in darkroom mode) and completely unusable.
I though that my camera got some fault and deleted many good shots. Glad that I always make backup before “importing”.
The same photo in “inspect” mode in RT:
No artifacts, as fast as DT’s “sticky preview”. RT’s “Inspect” uses just the embedded jpeg and displays it 1:1. Depsite Panasonic embeds 1/4 size jpeg in RW2, it still represents actual image much better than any preview mode in DT.
When using Canon cameras, I get 100% resolution jpeg in CR2 files and this is utilized by RT’s “Inspect” module. DT utilizes jpeg only in “sticky preview” and “culling” modes, but resized down with strange effects (1st screenshot), wasting all potential of fast and detail-accurate preview.
You see, I really have read manual. And had “Don’t use JPEG preview but 1/4 RAW” option turned off. Before taking part in this topic, to not waste your (all helping guys) time.
2 Likes
Press Alt-W, or “sticky preview” in the Lighttable to enable a full-screen mode. W to exit.
" why would one need to shoot raw+jpeg and waste more storage if there are already perfectly usable jpegs in the metadata. One just needs an easy way to access it."
This is a very valid point and quick access to the JPG would be nice feature.
1 Like
Edited my previous post instead of replying. I have strange results
/
|
3 posts up.
What do dt and RT consider “1:1 preview”? I.e. is it 1:1 wrt to the full raw size, or 1:1 wrt the embedded image? And is it the same for both programs?
There’s no direct relation between a “full screen” view and a “1:1” (100% zoom) view. Which do you want? And what are the sizes of yuor embedded jpegs and your screen? Those artifacts look like you get an embedded jpeg blown up to fill your screen, with the jpeg being smaller than your screen… For information, for me an embedded jpg is 1616×1080 pixels, my screen is 1920×1080, so a decent fit. If you use a 4k screen, the poor program has no choice when you ask it to show the image full screen while using the embedded preview
If dt wants to show a 1:1 of raw size, it has to process the raw data, for at least some cameras. The speed difference compared to darkroom mode is caused by dt using a quick and dirty demosaicing when you’re at zoomed-out view (like on opening; see configuration → darkroom → demosaicing for zoomed out darkroom mode).
===
Btw, Editing a post that has replies isn’t really that comfortable for the other users. For one, it becomes impossible to decide what’s replied to…
It would be the same for both programs - embedded jpeg is the same size, no matter which program you use to extract ad view it.
And this was mentioned as big disadvantage by few guys in this topic. No possibility to show 1:1 (pixel by pixel) jpeg in DT, which would be fast and accurate method when evaluating/sorting photos. Processing full demosaiced raw for this purprose is too slow. And, what I mentioned with examples, DT deforms details in “fit to screen” jpeg previews, and when processing raw for 1:1 preview purproses - picture details (especially edges) are even more deformed. (see screenshots - the same bug for Panasonic RW2 and Canon CR2 files).
So - recommended view modes are not only unusable but also make good pictures looking like they were only worth deleting.
That’s the point. In case of wildlife serial shoots, selecting/sorting/evaluating requires fast rolling between sometimes 200-300 pictures of almost the same scene. Embedded jpegs (even from cameras that embed jpeg with 1/4 of raw resolution) are detailed enough to use with 1:1 preview (eg. to check how bird’s nails are clamping a branch) as well as “fit to screen” preview to decide which picture shows best position. If program utilizes embedded jpegs, selection takes minutes. Processing every raw with full demosaicing, every time user scrolls back/forth for 1:1 preview, takes hours for the same session.
Fault, “misclicked”, not intentionally. Normally I reply with quuted fragments if needed. Fortunately not big inconsistence this time.
I guess I’ll drop out of this discussion, you ignored most of my questions (or misunderstood them?)
Once again, if you ask dt to show a 100% preview(*), then you have to demosaic the raw. dt offers several options for that, but of course it’s slower than just slamming a jpg on the screen. If that is not what you want, stick to a zoom that is acceptable for your embedded jpgs. For my current camera, those are 1616×1080, vs 6000×4000 for full size raw, so 1 px in jpg represents ~16px in raw… Not ideal to see those fine details in the jpg…
And if you use a 4k screen, a jpg with 1080 on the short size must be scaled up to “show in full screen”. Of course that gives the artifacts you showed.
Both of these points you chose to ignore in your reply…
Bye
(*: as dt is a raw processor, it is not illogical that relative sizes are relative to the raw image size, i.e. in 100% view, 1 screen pixel == 1 raw pxel)
If you want to use the embedded JPEG, you can quickly cull your images using e.g. Geeqie.
1 Like
Absolutely not ignored (and thanks for your patience). Maybe misunderstood approach or not speak clear enough. Just looked for any method of showing embedded jpegs 1:1 which means “1 embedded jpeg pixel = 1 screen pixel”. Nothing more, nothing less and no matter what screen size/density. Inside DT, to have everything in 1 tool instead of culling in external software. All my remaining workflow (after selection) can be done with DT.
For Canons I use, Embedded jpeg size is 100% raw size. Of course you/I can “extract” more details from raw (especially with fur or feather) and that’s one of reasons we use raw, but jpeg is accurate enough to evaluate particular shot “delete or save”.
Even my Panasonic’s embedded 1920x1440jpeg (for 14Mpix sensor) is in most situations enough to evaluate a shot. If it was displayed pixel:pixel on screen.
First screenshot is embedded jpeg, scaled down, not up. When using Alt+W “sticky preview”.
Second screen is just that. Raw processed in culling mode and not scaled (“preview zoom 100%” - that it’s called in DT). Gives worst artifacts.
No matter which demosaicing method I choose for darkroom, I don’t get these artifacts, only time differs (and omitably small difference in details). 2-5 seconds to get full resolution not scaled preview in darkroom. In culling mode when I press shortcut for “preview zoom 100%” I get “scrapped” image as shown in second screenshot, in 40 seconds.
Third screen is Panasonic’s embedded jpeg, not scaled, shown by RT.
For picture evaluation/culling, embedded jpeg is worth more than artifacted preview produced in 40 seconds.
Thanks.
I use Rawtherapee for that purprose - it shows embedded jpegs shrunk to fit screen or not scaled 1:1 (jpeg pixel = screen pixel). Instantly. And it works. Quick cull, mark for delete. After culling whole session I delete marked pics with 1 operation. Raws that left in directory, I load to DT and process. Was searching to do the same in DT.
@Igor64: would you care to share the raw (or another exhibiting the problem), along with your darktablerc?
Of course. All raws make the same problem. RW2, CR2. Also tried NEF.
darktablerc.txt (34.4 KB)
Trying to upload 11MB (7zipped 18MB RW2) thru our satellite connection. Forums attachment failed, timeout. Trying by sharing platform. Not bad today, says 7 minutes left.
EDIT: link to RAW pCloud
@Igor64 @Pascal_Obry I was checking out ART yesterday and they have a really nice inspector window in their browse…I could imagine adding extract the embedded jpg from this type of view as an added icon to their tool bar…agriggio / ART / wiki / Quickstart — Bitbucket scroll down a few pages to see what I mean in the quickstart guide for art …there is a nice selection of several ways to view your preview…Would be a nice add to have something like this in DT…for example where ART lets you do a quick preview with a couple of types of curves ie linear vs std…DT could do a similar thing but let you compare say basecurve vs scene referred quick preview… I would be interested to hear what you think??
Will likely test all ART’s options, thanks.
Ok, trying to download ART.
Igor, I’ll try and make some measurements. I’m dead tired today, but I have not forgotten.
Version 1.61 id the most current…as RT and the fork ART also use the embedded JPG as a reference for their automatch tone curve I guess it plays a more central role in that software than in DT
While I did not find performance to be unbearable, it is inconvenient (W takes 2-3 seconds on my machine, but it’s a very old box).
The quality of the preview is absolutely horrible, useless.
Already processed image with Alt+W sticky preview:
Zoomed in:
Same image in darkroom:
In darkroom, zoomed in:
JPEG preview displayed in Geeqie:
JPEG preview in Geequie, zoomed in:
I then disabled the ‘prefer performance over quality’ setting, and there was a change, but it’s only a blurry image instead of a pixelated one (a different shot, to better show image quality):
Sticky preview at 100%
Darkroom:
JPEG preview in Geeqie, zoomed in:
@Pascal_Obry: this has just occurred to me: does the relevance of the ‘prefer performance over quality’ flag indicate that the culling view (even at 100%) is generated from the small preview image (the one normally displayed in the darkroom top-left)?