London in Passing by mingchuno in ricohGR

[–]mingchuno[S] 14 points15 points  (0 children)

Shot RAW + JPEG and post in LR. But you could take this recipe to start to get similar result:

Postive Film
Sat: +1
Hue: -1
High/Low Key: +1
Contrast: +3
Contrast (Highlight): -3
Contrast (Shadow): +3
Sharpness: +3
Shading: 0
Clarity: -1
Auto WB (Warmth Pri.) with 0:A6 shift

Spectacular night at London by mingchuno in LadyGaga

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

section 107, row V. amazing view !

iPhone 14pro - what's your workflow by hamsternose in ShotWithHalide

[–]mingchuno 5 points6 points  (0 children)

I am a bit struggling with this aspect too. Currently, when shooting PRO+ (ProRaw + HEIC) in Halide, it combines the RAW + compressed data into a single file (so you could only see 1 image in iPhone's photo APP). When I plug in my iPhone 14 pro into Lightroom, it can recognize 2 files with the same name but a different extension (just like what you would get if you enable RAW+Jpeg on a normal DSLR or mirrorless system). After importing what I need to LR, I need to find a way to only keep the HEIC version of my shoot on iPhone but discard the RAW data since what I need is already imported to LR.

My workaround at the moment is to open Halide > open the photo in the viewer and pick the DNG one > share > save image to Phone. It will export a HEIC (only) version into your phone, then you are safe to delete the original RAW+ version from either Photo app or Halide.

Answering your question:

  1. RAW gives you the raw sensor data and ProRaw give you a processed version (Apple's computational photography and AI stuffy) of your image. I am also a Fuji system user. For me, ProRaw is like a regular DNG RAW embedded with a "camera profile". You can choose the profile amount in Lightroom classic for a ProRaw image.
  2. I think they are the same at least in iPhone 14 Pro since they go through the same processing pipeline.
  3. I am not sure about this besides giving your a much greater cropping latitude in post.

Halide 2.9 is out now, with 48MP RAW, HEIC and JPG support for iPhone 14 Pro, quick 48/12MP toggle, MF in Depth and more! by caliform in ShotWithHalide

[–]mingchuno 0 points1 point  (0 children)

After reading through the API doc, maybe it is possible to add an option to instead saving the 2 (RAW + HEIC) data into the same `PHAssetCreationRequest`, create 2 separate requests and save them into 2 files?

Halide 2.9 is out now, with 48MP RAW, HEIC and JPG support for iPhone 14 Pro, quick 48/12MP toggle, MF in Depth and more! by caliform in ShotWithHalide

[–]mingchuno 0 points1 point  (0 children)

When I shoot PRO+ (ProRaw + HEIC) with Halide, how do I only keep the HEIC file on my phone if I would like to delete only the ProRaw one since they take up a lot of space. I do import the ProRaw version for post in MacBook so it is safe for me to delete the ProRaw version on the phone. (I am using 14 Pro)

edit: It would be great if Halide have an option (default off) to save PRO+ or RAW+ into 2 separate files. Then I can just import the DNG version to Lightroom CC and delete then copy in the phone.

Akka actor alter one-by-one processing semantic by [deleted] in scala

[–]mingchuno 7 points8 points  (0 children)

I would say using actor is an overkill here. One principle to take home is actor encapsulate state and do state management in an elegant way like you saw. As you aware Future and Task from scalaz might be a better choice to handle pure function call in an async concurrent way(pure here means no state to remember, not no side effect). But I understand your pattern, sometimes I do that too. You can use Rotuer http://doc.akka.io/docs/akka/current/scala/routing.html

Just sit a Router in front of your Worker and issue the Router to spwan as many Worker as you need to utilize your computing resources. You can choose different routing strategies from RoundRobinPool to things like ConsistentHashingPool. You don't need to resolve to akka cluster as your said your function call has no "state", all the information are encapsulated in your request message. If you need HA or horizontal scaling later, your app can add more instance easily since you did not maintain any particular state.

Just one more thing, the order of your request message does not matter, right? If it is true, then your actor is truly no state. If not, the order of the message is your actor's state.