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)?
No, to me the full preview is not impacted by the âprefer performance over qualityâ flag.
Very interesting. Maybe weâre trying different things? Using different settings? The environment could cause some difference?
This is what I did:
- selected a previously developed raw (a NEF, in my case) in the lighttable
- pressed Alt+W
- Ctrl + scrolled to get 100% zoom
- Took this screenshot:
- pressed Alt+W to exit the preview
- Opened settings, and changed
prefer performance over qualityfrom true to false - pressed Alt+W
- Ctrl + scrolled to get 100% zoom
- Took this screenshot:
My screen resolution is 1920x1080. darktable is at 3.3.0+1931~g4d0071658. OS is Kubuntu 20.10.
Iâve tried toggling OpenCL, did not have an effect.
In my darktablerc (done after restoring prefer performance over quality to true):
kofa@eagle:~/.config/darktable$ grep -i qual darktablerc
database_cache_quality=89
plugins/darkroom/demosaic/quality=at most PPG (reasonable)
plugins/darkroom/equalizer/expanded=FALSE
plugins/darkroom/equalizer/favorite=FALSE
plugins/darkroom/equalizer/modulegroup=4
plugins/darkroom/equalizer/visible=FALSE
plugins/darkroom/toneequal/expanded=FALSE
plugins/darkroom/toneequal/favorite=TRUE
plugins/darkroom/toneequal/gui_page=0
plugins/darkroom/toneequal/modulegroup=1
plugins/darkroom/toneequal/visible=TRUE
plugins/imageio/format/j2k/quality=
plugins/imageio/format/jpeg/quality=95
plugins/imageio/format/webp/quality=
plugins/lighttable/export/high_quality_processing=TRUE
plugins/lighttable/low_quality_thumbnails=TRUE
plugins/slideshow/high_quality=TRUE
kofa@eagle:~/.config/darktable$ grep -i perf darktablerc
performance_configuration_version_completed=1
ui/performance=TRUE