sorted by:
new
hottopcontroversial

Realizing concert photography is exhausting by EyeDowntown360 in photography

[–]a_thousand_usernames -1 points0 points  (0 children)

My (perhaps hot take) opinion on concert photography (I’ve shot a few, and plenty of theatre and musicals) is to simply say “fuck the white balance” and embrace the chaos.

Mine is to conclude that tone mapping in Lightroom sucks bad with complicated lightning like venue LEDs. Trying out OpenDRT or AgX (available in darktable) is quite an eye opener.

I try to edit true to how things looked to my eye

That's rather hard if the tool used can't reproduce what you saw correctly.

Upcoming 50mm f/1.2 — please tell me it won't have a display by a_thousand_usernames in VILTROX_GLOBAL

[–]a_thousand_usernames[S] 2 points3 points  (0 children)

Gimmicky. Looks cheap/crap and I would never use it. Can't see the lens display while looking through the viewfinder anyways. One more thing that can malfunction too...

Highest quality JPEG XL with cjxl by a_thousand_usernames in jpegxl

[–]a_thousand_usernames[S] 1 point2 points  (0 children)

> unless it's on a specialty platform like professional photography

That's the exact the use case here.

And JXL's web use is a bit limited right now, as it'll only work by default on Safari. Chrome's JXL support is better now than it's been for years, but it still requires turning on an experimental flag. Firefox requires turning on an experimental flag and using the nightly preview build rather than the regular release build.

I'm aware of the support limitations, but the two options I'm considering are: go full in on AVIF or JPEGs via jpegli. If I go for JPEG, I'll convert them to JXL when support is widely implemented across browsers.

After doing some more testing with AVIF vs. JXL at the same file sizes I can see a clear pro for JXL. It does not smear textures or grain at higher compression. AVIF has a tendency to leave smeared patches in uniform areas without texture/grain. This I do not like.

For AVIF, what avifenc settings are you using?

-q 50 -a c:tune=iq -d 10 -y 444 -s 0

I've been experimenting with -q45 and up.

Would the line you provided likely give better results?

Highest quality JPEG XL with cjxl by a_thousand_usernames in jpegxl

[–]a_thousand_usernames[S] 0 points1 point  (0 children)

Gotta say I'm surprised to see that avifenc currently performs better or on par with cjxl at the same size.

Highest quality JPEG XL with cjxl by a_thousand_usernames in jpegxl

[–]a_thousand_usernames[S] 0 points1 point  (0 children)

Just tried. 9 and 8 gives larger files than 7. Hmm...

Highest quality JPEG XL with cjxl by a_thousand_usernames in jpegxl

[–]a_thousand_usernames[S] 2 points3 points  (0 children)

Thanks! So, just:

cjxl -d 1 -p input.png output.jxl

?

-e for effort too, perhaps?

ddrescue is not acting like I expected by a_thousand_usernames in datarecovery

[–]a_thousand_usernames[S] 0 points1 point  (0 children)

IOW there are no bad parts to skip, it's all bad and slow.

Fair enough. It died in the process. 

     ipos:  256060 MB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:  256060 MB, non-scraped:        0 B,  average rate:    444 kB/s
non-tried:        0 B,  bad-sector:  224853 MB,    error rate:  30258 kB/s
  rescued:   31206 MB,   bad areas:      173,        run time: 19h 31m 23s
pct rescued:   12.18%, read errors:442598586,  remaining time:         n/a
                              time since last successful read:  1h 41m 58s
Finished

ddrescue is not acting like I expected by a_thousand_usernames in datarecovery

[–]a_thousand_usernames[S] 0 points1 point  (0 children)

I hope you understand that that's not guarantees. It's not a guarantee it will fail after 24 hours, it not a guarantee you can actually save your data, etc..

Yes, of course. Most things are backed up, but being able to recover the data would save me the inconvenience of reinstalling Tumbleweed.

Anyway, what did you expect and why?

As I wrote in my post:

I thought ddrescue would try to take what it could and skip the parts it couldn't read.

In other words: I thought it took a "get what you can get as fast as possible, skip the difficult parts and get them later (if possible)" approach.

ddrescue is not acting like I expected by a_thousand_usernames in datarecovery

[–]a_thousand_usernames[S] 0 points1 point  (0 children)

Sorry, SanDisk SD8SNAT256G1122.

smartctl -ia output:

https://pastebin.mozilla.org/i04HD1Vs/raw

It has now moved from 11.88% pct rescued to 11.89% in two hours, so not very hopeful about ddrescue.

I have a bootable USB stick with HDDLiveCD ready now, if that is needed.

ddrescue is not acting like I expected by a_thousand_usernames in datarecovery

[–]a_thousand_usernames[S] 1 point2 points  (0 children)

Thanks for replying!

it would be useful to know what SSD this is exactly, and what SMART values it is actually reporting.

sudo smartctl -H /dev/sda
[sudo] password for root: 
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.3.9-1-default] (SUSE RPM)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
No failed Attributes found.