[Dachs-support] SODA error with 3d data

[Ixaka Labadie]

Thanks, Markus, for the prompt answer.

Good to know that the scaling part is expected. It's not important, 
although I think it's related.

I send you the simplest example I've tried, not "fits_standardDLFuncs" 
(although I tried it and doesn't work either). Here I don't use 
makeBandMeta or makeBandSlice, but I was expecting to be able to make 
cutouts in the velocity axis as well (technically it is possible but I 
have to invert min/max, which is not how it's supposed to be).

Sorry, I cannot share the data I'm working with, but I can show you an 
extract of the header. I also send the equivalent part of the header I 
obtain when clicking "retrieve data" in datalink. The main difference 
I've noticed in in NAXIS3 and CRPIX3. If having the same dataset could 
really help I could make a mock file.

Cheers,
Ixaka


On 2023-03-27 16:41, Markus Demleitner wrote:
> Ixaka,
> 
> On Mon, Mar 27, 2023 at 03:44:34PM +0200, Ixaka Labadie wrote:
>> I am having some trouble using the SODA resources for 3d data, 
>> specifically
>> with the velocity axis. I just made an example for cutouts with
>> "//soda#fits_genDesc" and <FEED source="//soda#fits_standardDLFuncs"/> 
>> that
>> fails when setting the velocity min and max (real values, not pixels) 
>> and
>> also fails to scale the image. The result when I click "retrieve data" 
>> is
> 
> Uh, ouch, the scaling part is expected, now that I think of it.  The
> code for scaling can only deal with pixels.  Generalising this would
> certainly be possible, but it feels somewhat scary once one goes
> beyond 3d.  So... on that, I'd probably suggest to take out the
> scaling part unless you think that would be terribly important.  I
> think fits_standardDLFuncs should automatically drop SCALE when
> there's a spectralAxis...
> 
> The behaviour you describe for vmax and vmin, on the other hand,
> clearly is a bug that requires fixing.
> 
> So... what you do is map the velocity axis to the spectralAxis in
> fits_standardDLFuncs?  If so, I'm intrigued this works at all :-)  I
> have to admit that fits_standardDLFuncs, despite its name, at this
> point is strongly biased towards spectral cubes.
> 
>> just the FITS header, with the CRPIX3 keyword changed. On the other 
>> hand, if
>> I use the inverse order, max and then min, for the velocity I can 
>> retrieve
>> the cube correctly (although CRPIX3 still changes). The cube I'm using 
>> has
>> RA--SIN, DEC--SIN and VRAD; the spatial coordinates work correctly.
> 
> The plot thickens...
> 
> I would expect you could get by unraveling fits_standardDLFuncs
> (run dachs adm dumpDF //soda and fetch the pertaining metaMaker-s and
> dataFunction-s from the body of the corresponing STREAM) and
> replacing the BAND items with your own metaMaker/dataFunction combo.
> You could use fits_makeBANDMeta and fits_makeBANDSlice procDefs as
> hints for how this could work.
> 
> However, I give you this is extremely dense stuff entangled with the
> doWCSCutout data function in a rather non-trivial way.  I'd rather
> write some somewhat more accessible documentation on that, but
> without a concrete case that's always a bit tedious.
> 
> So... can you perhaps share your RD and a dataset with me so I can
> fiddle a bit until I have some scheme I'm happy with?
> 
> Thanks,
> 
>            Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hdr_in.txt
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20230327/fc7af4f4/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hdr_out.txt
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20230327/fc7af4f4/attachment-0003.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: q_test11.rd
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20230327/fc7af4f4/attachment-0001.ksh>