AP raw stack CTD: 1.10.1.1142 (windows), using X3Fs

[Wumpus]

Hi.

Retried some image stacking recently, and it is working amazingly well. Bravo. Excited for 2.x. It would be completely usable for me now, for focus and tonal mapping, and panorama.

Just wanted to mention that importing any extent (# images) of any kind of stack using X3F (raw format) results in a crash to desktop.

However, bringing the files in using a 16-bit (per primary) TIFF works very well.

Reading posts here, it mentions that you lose the automatic raw Development persona doing Stack image loads (which makes sense). But it sounds like it is still feasible (though streamlined) using other raw formats. I also know that X3F gets handled a bit differently than other raw formats (it's not using LibRaw).

My question was if a Dev could check whether that crash to desktop occurs because AP is treating X3F like other raw formats (maybe there's another existing group that wouldn't use LibRaw, and so would work better with X3F). If so, it would certainly be extremely convenient and appreciated if that could be fixed.

If it would be all custom Dev work, then its not high priority, as it is still functional using TIFFs, and its just a bit more prep work.

Thanks very much.

[stokerg]

Hi @Wumpus,

Can you provide some sample X3F for a stack that cause a crash for you and i can get this looked into.  Feel free to upload them to our Dropbox here: https://www.dropbox.com/request/qYFHwGjfBKlw64zlRzo4

If you could also upload your crash report to the above link that will help show where the crash is.  To find the crash report see this post  

[Wumpus]

Hi @stokerg:

Thank you so much for investigating this, and my apologies for not getting back sooner (12-14 hours days in a crazy time of year).

I did tests using an Sigma SD14 and an Sigma SD1M, both of which are 1:1:1 X3F raw files ( a bit unlike the Quattro Sigmas, and very unlike the 'fp' Sigmas, if that's of help). I varied the available controls presented through the "New Stack..."  dialog, so you could see the results in the dump file with a variety of different settings. The files are in your drop box: two SD1M files and two SD14 files, and three dump files representing all the various settings.

As 16-bit TIFFs, these same images work flawlessly in the same steps, so I have a workaround. Unfortunately, Sigma makes getting quality images out of the X3Fs a bit work work, so it would be convenient to do it through AP, but if too much effort, I'll understand (I also do development).

The main reason I mentioned this is that most Sigmas use a very unusual raw data format, and so you don't treat them identically to other CFA raw formats (which is good: those changes you made drastically improved your X3F handling, and I am a grateful user for that). Which led me to think (again, as a developer) that perhaps this routine was undergoing the same processing as for other raw formats, and so crashing. Perhaps (and yes it's one more tiny bit of code baggage) a condition could be put in to check the format and route it appropriately.

Anyway, that was my little idea and request if someone could see how onerous that was.

Keep up the good work.

[stokerg]

23 hours ago, Wumpus said:

The main reason I mentioned this is that most Sigmas use a very unusual raw data format, and so you don't treat them identically to other CFA raw formats (which is good: those changes you made drastically improved your X3F handling, and I am a grateful user for that). Which led me to think (again, as a developer) that perhaps this routine was undergoing the same processing as for other raw formats, and so crashing. Perhaps (and yes it's one more tiny bit of code baggage) a condition could be put in to check the format and route it appropriately.

 

That could very well be the case.  I will get this logged as a crash is always unwanted behaviour.  I did notice on our RAW list here the Sigma SD14 is marked as 'raw decode only' and its likely the Stacking dialog is using a different pipeline behind the scenes, as i know this is the case for the Batch jobs.  This could also explain why we don't get a preview of the thumbnails on the Stacking dialog. 

[Wumpus]

Very much appreciated. The SD14 has a much lower usage rate nowadays, and likely will be even less so when Sigma finally releases their upcoming model (2022/2023) that should work similarly (except be full frame), so that has lower importance for me, and likely similarly for your other Sigma users. The SD1M is still in heavy use by the Sigma community, and would be a higher priority to accommodate. Anyway, that's just some marketing context, if that helps.

I never realized that there should be thumbnails: that woud be quite helpful! Thanks again so much again for your consideration.

[Wumpus]

Just checking in if there's been any progress. I know sometimes things get a bit hectic here, and occasionally things fall through the cracks.

[Wumpus]

Hi @stokerg

Just a little 'keep alive note' to check if there's been any progress.

Thx

[Wumpus]

Hi @stokerg

Just my weekly check-in for any progress or updates...

Thank you.

[Wumpus]

Hi @stokerg

Just thought I'd check in case once something gets 'logged', that means that it's basically back-burnered for eternity, or whether someone was going to address my original question one of these weeks. I do understand this happens a lot, so hoping for a notion of when I might expect some response.

Thanks very much

[walt.farrell]

10 hours ago, Wumpus said:

that means that it's basically back-burnered for eternity, or whether someone was going to address my original question one of these weeks. I do understand this happens a lot, so hoping for a notion of when I might expect some response.

"Logged" means that it's in the hands of the Developers, who will confirm there's a bug, prioritize it with the other known bugs, and fix it on their schedule (which is known only to them). There will generally be no comment on when that fix will occur, unless the bug is a severe one that basically prevents all users from using the program.

I'm not sure what your original question was that is waiting an answer (and, obviously, I'm not stokerg nor a Serif staff member  ), but I wanted to make one comment. I would generally recommend not stacking RAW images. There are two distinct paths for using RAW files currently:

1. In Photo, File > Open or New Batch Job both go through the complete Development phase, which includes all the actions controlled by the Develop Assistant (Lens Correction, default Tone Curve, Exposure Correction, Noise Correction, etc.).
2. All other uses, whether in Photo or one of the other Affinity applications (including File > Place, New Stack, etc.) go through an abbreviated Development process that skips all the actions controlled by the Develop Assistant. This means that unless you have turned off all the Develop Assistant options, if you use RAW files  any way except those in #1 above you will get a different (probably worse) result than if you used File > Open or New Batfch Job to Develop them completely, then exported them to a loss-free format such as TIFF or PNG.

[Wumpus]

Thank you @walt.farrell and again, I might add. Was hoping for a timeframe, such as backlog grooming frequency and priority.

For a product with some great development, the support seems to continually let me down with rare responsiveness (despite checking who is following a post and specifically naming its audience,  as you taught me in similar historical circumstances).

It always falls upon the user community, such as good folk like yourselves, to speak up for the product owners and product support teams. I wonder how any other organization would feel if I took it upon myself to publicly act as their public representative, on their behalf. Users have zero authority and accountability, plus incomplete knowledge, exactly because they aren't Affinity employees. Its a highly unusual and new Management technique for the business world.

Further, the double-speak of "logging" infers someone will review it, thought the backlog here appears to undergo a grooming frequency aligned with the duration of the Mayan calendar.

Bottom line, the current model always yields a very brief and very false hope to its customers, which of course always turns to a negative sentiment. I still can't get my head around that peculiar business model.

I fully understand your position, Walt, and thank you for it. I'm just repetitively annoyed at the support model. The customer service team can come out from their cupboards yet again, because as per 'business as usual', a non-employee has had to step in and do their job for them. A sort of RACI chart without the letters R or A.

Thanks.

[walt.farrell]

1 hour ago, Wumpus said:

Was hoping for a timeframe, such as backlog grooming frequency and priority.

As you've noticed, Serif does not provide that.