You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The MaskingCompositor produces an LA image. That makes perfect sense. The input data are mode L and it has an alpha layer, so LA is arguable the only correct answer.
It is currently not possible to write LA images with the ninjotiff writer, as pyninjotiff supports only L, RGB, RGBA, and P.
Our preferred solution is to convert our LA image into RGBA. See below under "Additional context" what other alternatives I have considered but do not prefer.
Describe the solution you'd like
I would like a new keyword argument to satpy.composites.MaskingCompositor, return_mode="LA". If set to "RGBA", then the dataset will be converted to RGBA. If it is set to "LA" (the default), the dataset will be returned as it is today. If it is set to anything else, an exception will be raised.
Describe any changes to existing user workflow
The default situation, when no argument is passed, will be the status quo. Therefore, no changes to existing user workflow are foreseen.
Additional context
Much speaks for generating LA images and extending pyninjotiff to support them. However, our old production is giving RGBA images to our users, and their workflows expect RGBA. In the short term, it is less work to keep producing RGBA images than to tell everyone to support LA. It is user-friendly for changes to be incremental and to keep the RGBA → LA change for another time.
Instead of building this option into Satpy, we could use our own local code to do the conversion. Turning a greyscale LA into RGBA is rather inefficient, and not many other users may need this. This is the solution we used in our old (still current) production. If the Satpy developers don't think this should be in Satpy, then we can do this, but I would prefer to minimise local unmerged code. Fortunately, the change should be quite simple.
The text was updated successfully, but these errors were encountered:
What about just "mode" since this is already used in the metadata? For ninjotiffs, do you set fill_value=0 when saving the dataset? Would another option be to do L only and have the data masked with NaNs?
Feature Request
Is your feature request related to a problem? Please describe.
The MaskingCompositor produces an LA image. That makes perfect sense. The input data are mode L and it has an alpha layer, so LA is arguable the only correct answer.
It is currently not possible to write LA images with the ninjotiff writer, as pyninjotiff supports only L, RGB, RGBA, and P.
Our preferred solution is to convert our LA image into RGBA. See below under "Additional context" what other alternatives I have considered but do not prefer.
Describe the solution you'd like
I would like a new keyword argument to
satpy.composites.MaskingCompositor
,return_mode="LA"
. If set to"RGBA"
, then the dataset will be converted to RGBA. If it is set to"LA"
(the default), the dataset will be returned as it is today. If it is set to anything else, an exception will be raised.Describe any changes to existing user workflow
The default situation, when no argument is passed, will be the status quo. Therefore, no changes to existing user workflow are foreseen.
Additional context
Much speaks for generating LA images and extending pyninjotiff to support them. However, our old production is giving RGBA images to our users, and their workflows expect RGBA. In the short term, it is less work to keep producing RGBA images than to tell everyone to support LA. It is user-friendly for changes to be incremental and to keep the RGBA → LA change for another time.
Instead of building this option into Satpy, we could use our own local code to do the conversion. Turning a greyscale LA into RGBA is rather inefficient, and not many other users may need this. This is the solution we used in our old (still current) production. If the Satpy developers don't think this should be in Satpy, then we can do this, but I would prefer to minimise local unmerged code. Fortunately, the change should be quite simple.
The text was updated successfully, but these errors were encountered: