F_Kal

seems this issue hasn't been fixed so far - I realized that no matter what the source of the images, (raw, tiff, exr, 32bit-png) the panorama tool will rasterize them to SDR and clip any information that exceeds the range, crushing in the process highlights that exist in the source images (AP 2.5.5 and 2.6 beta).

thanks @Ldina! Both are very useful videos - It's actually the first video (single-photo HDR) that inspired me for my HDR-escapades. Nowadays with true HDR support in formats like png and jpegXL and more and more devices being able to actually display the extended dynamic range (eg. OLED phones), I thought that it's a good moment to start making use of the extra stops in my camera's RAW files that old-school jpeg files would clip, and thus forfeiting jpeg and storing my images into 32bit jxl instead. Perhaps the novelty at some point will wear off but for now I enjoy seeing ultra-bright artificial lightsources in my photos shot using my 2014 mirrorless!

Thanks Ldina, that's a brilliant trick! I had given up on the idea of recording macros since the develop persona was being excluded from the process On the topic of HDR merges, I've tried all possible formats as inputs, but affinity photo reads the full brightness data only from RAW files: For all the other formats, it clamps the input values to the SDR range ignoring values that are outside of it. Usually this is fine since you compensate by the overlap between the bracketed shots, but In my case I am trying to squeeze the maximum possible dynamic range out of 2 photos so even those 1-2 extra stops that these RAW files capture make a difference in the end result - Perhaps in some future test I could try compressing all the dynamic range of the RAW file into the SDR range (but with a 16/32bit precision) and use those developed images as source - food for thought!

I have a similar issue with my Olympus OM-D E-M10 mark II camera in AP. I can't compare it to Adobe's RAW rendering since I don't have an adobe subscription, but in AP intense lightsources often have high-chroma color noise inside or around them. I've attached the original .ORF file of the below example. The issue is visible when opening the raw (orf) files in AP, no need for attempting an HDRmerge (though it's more pronounced there as well) P8159719.ORF

There seems to be something off with the rendering of jxl files (or at least jxl files converted by cjxl) If I take a HDR .png file generated by Affinity Photo with an icc profile of BT2020 (Linear) and convert it to .jxl using cjxl (eg. by cjxl P8159638.png P8159638.jxl --modular=0 --effort=9 -d 0.2 --brotli_effort=11 --intensity_target=1000 -v -v -v -v -v -x color_space=RGB_D65_202_Rel_SRG) the resulting .jxl file when opened back in Affinity Photo appears as RGB_D65_SRG_Rel_Lin which is simply sRGB, not BT.2020. The image opens also very dark. Apple's Preview inspector shows the proper colorspace profile for both the png and the jxl image. Unlike Affinity Photo that doesn't respect the ones found in the .jxl file. Archive.zip

Perhaps @James Ritson?

regrding this comment, you raise an interesting point what I haven't been able to find a clear answer to so it would be nice if serif came up with some clarifications. My personal explanation of all that is that histogram's Max:2 doesn't mean 2.0eV. Max: 1 is the total range of SDR images which should be around 6 to 12eV (I'm uncertain on the exact value) and 200% would imply double that (12 to 24eV). max:1.5 would give you 12 to 16 stops. Merging 3 HDR images of -2/0/+2eV shot on a mirrorless camera with say 11eV dynamic range, means that you end up with a total of 15eV - Hence the choice of 1.5 but again, this was arbitary on my part. As for the retina display showing max 2.0 (+1eV) I think it means that the "previewing" algorithm of AP will try to display all tones up to 2 of the histogram (ie the first 12 to 16eV of the HDR range with probably some tonal compression of the values so they fit in the retina's limited dynamic range) and reserve 1 extra eV as headroom to map all the stronger values as superbright pixels. Once again I might be totally wrong. An official explanation would be great!

thanks @Ldina - From what I understand the "show EDR" checkbox is merely a previewing setting for Affinity Photo - It's not affected by (neither affecting) some inherent property of the file - it's just a switch to allow the user preview an EDR and an SDR version of his work while working. Hence, this behavior was also expected. My experience also suggests that Affinity Photo displays properly the images. The problem lies when editing these images inside Apple Photos on an iphone or mac (ie not by exporting them to AP2, but by using the built-in, non-destructive Edit function of Apple Photos)

Last month or so I've too been experimenting with HDR exports - while the jxl exporter of AP2 indeed does only SDR, the PNG exporter does work for me. Quicklook/Preview displays the image as SDR but Apple Photos does read the EDR values of the files (both on macOS Sequoia and iOS18). FWIW I also use cjxl to convert this PNG file into a smallish 32bit HDR JXL files. There are issues of course and the whole thing certainly qualifies as a mess, but I don't think it's a problem of the exported files as much as it is a problem of each company/vendor (apple, adobe etc) implementing strictly the png/jxl subset that their own software exports into. It will be some time before these encoders and decoders become comprehensive enough

I've been trying to create HDR-merges in AP2.x that are able to render as real-HDR on the OLED display of my iPhone, but it has been hit-or-miss. Process I merge -2/0/+2eV RAW images inside AP2.x (the RAW developer persona delivers 32bit HDR). I do not use the tone-mapping persona. I edit them to my liking and export the result into 32bit/BT.2020 PQ/full Range PNG. Then, I import this image into my phone's Photos library (eg via airdrop) Behavior Inside Apple Photos, the thumbnails appear as SDR which is expected. When opening an individual image it lights-up into it HDR potential (also expected). The problem however is that for some of these images (I'd say ~1 out of 2) after I click the edit button, the image gets tone-mapped into SDR and the image loses its extended dynamic range. In the attached samples, the xxxx271.png and xxxx520.phg files, exhibit the issue in their highlights (look on the light sources and the sky behind the branches) whereas the 3rd image xxx661.png works fine. Has anybody found what is triggering this inconsistent behavior and perhaps how one could circumvent it until better support comes out? Notes I haven't found any connection between the issue and the specific exposure level or curves I use during the AP2 editing, however I try to keep the Max values in the histogram below 1.5. - The image will have the issue whether the filter/editing layers are active or not. I wonder if the issue has to do with the percentage of pixels with brightness above a certain level (in other words the distribution of the histogram). Another interesting glitch for some HDR photos that I create via this method, is that when transitioning from thumbnail to full-sized image in Apple Photos, the "illumination/brigthening" of the EDR pixels doesn't happen smoothly like it does for the iPhone's photos, but for some images it happens abruptly in 1 or 2 steps. These issues get inherited to HDR jxl files that I convert from AP2s PNG using cjxl. I understand that HDR support on iOS devices beyond HEIC+gain map is still very fresh and not well-standarized of course. samples.zip

I have reached similar conclusions from the trial of v2 - at least when it comes to the issues (both annoyances and bugs) that I was encountering in V1, they are still present (most of them 4-5 years and counting). I too am on the fence whether I should buy it while it's discounted, only to futureproof myself in case the issues get finally addressed in the ...next 4-5 years.

I've been a long time user of AP/AD v1 on macOS, and while the software in terms of features matured quite quickly, a few bugs and quirks were there for a few years and never really went away: eg. spinning beach balls when resizing the handles of a layer that start after some time of playing - you need to restart the app to get it back to working (AP), random crashes, bugs with symbols (AD), not being able to cancel/exit raw development with a keyboard shortcut etc. I haven't seen any feature in V2 that I need but I wouldn't say no to upgrading if V2 had some or all of these issues resolved. what is your opinion? do you feel that V2 is less buggy than V1?

thank you John! Interesting; I've found auto-alignment to be most of the time producing inaccurate alignments - even with images from a tripod (let alone handheld) I also wonder whether this technique only yields results with extremely sharp lenses, where the sensor doesn't resolve all the detail procured by the lens. The kit and adapted lenses from the 80s that I use don't ever reach pixel-level sharpness

interesting finds @John Rostron! Could you elaborate a bit on the alignment method you used? was it auto-align or was it manually micro-tuning the individual images' perspective? Also, how do the results compare to the original images? Any chance you could share the crop of one of the original 13 images for us to see? Thank you for helping out!

I haven't had any luck with the technique; other than noise reduction which is awesome! I also can't understand the rational behind upscaling the images to 200% before importing them into the stack. What's the problem with upscaling them after the stack it created? It's dynamic anyways - isn't it? Unless this is for the auto-alignment algorithm to have more precision in alignment (though to be honest I find the alignment very ineffective) - Any thoughts on that?