Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Multispectral support #138

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

michaelni
Copy link
Member

This is not to merge yet, but for discussion and of course if anyone wants to contribute/add to it

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
plane_type | ur
center_frequency | ur
frequency_response ( center_frequency ) |
color_transfer_characteristic | ur
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

color_transfer_characteristic is common to YUV (+colour_primaries, matrix_coefficients), shouldn't it be in a color info dedicated part e.g. at the end of the configuration box?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, the idea was that we need something to go from physical energy to binary values and that often is not linear. Maybe color_transfer_characteristic is a poor term for this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

transfer_characteristic wording would be misleading as the name is already used elsewhere (prefix 'color' would not be enough for differentiation IMO), so in that case it should be another name.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • color_translation?
  • color_conversion?
  • color_interpretation?

possibly add _characteristic to any of those?

@retokromer
Copy link
Contributor

On my side, I made good experiences definitying the wavelength (in nm) for each spectral band.

@michaelni
Copy link
Member Author

On my side, I made good experiences definitying the wavelength (in nm) for each spectral band.

I used hz in the hope that the whole relevant EM spectrum could be represented and as its a fundamental unit. (quite possibly ive missed something of course). with nm we would need fractional values and not just integers if we wanted to store X-ray images and use this field to hold some acccurate X-ray frequency information

@retokromer
Copy link
Contributor

I’m afraid, I’m probably missing something! It seems to me that the integers vs. fractions issue is the same when expressed in Hz or in m, which are actually both SI base units. (Context: I made that choice, because it’s the information characterising the filters we use… Anyway, the conversion between them is elementary.)

@michaelni
Copy link
Member Author

If one wanted to use integers to handle the value, with Hz that works for most of the relevant spectrum with also very good precision for the range one is able to make pictures with. visual, UV, ir, xrays are all high frequency so lots of digits precission. With really long radio waves making images will be very hard as the antenna has to scale up size wise. OTOH with meters as the base unit most of the relevant spectrum falls below 1.0 so fractional numbers need to be handled. Also with wavelength we would need to clarify if that is wavelength in air, in vacuum or in the medium the picture was taken.
But ultimately it of course makes no real difference either way can be used to store the value.
In practice maybe we should use a mantisse * 2^exponent style storage as fractions as in a/b would result in values for either a or b not fitting in 64bit integers. Ill try to come up with some better suggestion in a future patch revission


### center_frequency

`center_frequency` indicates the center frequency in hz. Or 0 if unknown or not applicable.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit Hz

Copy link

@pjotrek-b pjotrek-b Oct 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for jumping in (3 years+ later) 😄 :
Does any of you have any particular real-world examples in mind (or access to them)?
Like the xrays, long radio wave images, air/vacuum/etc recordings @michaelni mentioned?

I'm wondering if it'd make sense not to raw-parametrize this, but rather define/offer presets which can be tuned in the code, rather than as arguments? Then access these interpretation options by a given name shortcut?
(If I understood the subject alright)

I assume that any area of expertise that would create such recordings will very likely have some sets of "common parameters" - therefore domain-specific "insider terms" for those imaging types.

Like FFmpeg having "dvd_pal" containing a set of sane/valid parameters, we could have something like "xray_10nm" or "10nm-water-hot". Dunno. Something like that?

Wouldn't this also allow arbitrary choice of data-types (per imaging-type) for proper calculations?
Integers, fractions, etc - "different strokes for different (imaging type) folks" - so to say 😜

If I'm right, then this is tricky to handle in a Standards paper definition... But if x264 can be a standard and do presets, so could ffv1, I presume? 😉

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you need samples there should be lots of public stuff from astronomy and satellites. For xrays and MRT the word to search for is probably dicom image. One source for public domain samples would be any images you own the rights to, like from a medical exam. I didnt really try to find free proper raw sample images for these things previously ...

@retokromer
Copy link
Contributor

Just out of curiosity: is there any work going on here? (I will be in Vienna from Thursday to Sunday and could meet if useful. Then again the week 6–10 January.)

@kieranjol
Copy link
Contributor

kieranjol commented Oct 25, 2022 via email

@retokromer
Copy link
Contributor

FYI: I will present on this topic again in a larger context at NTTW6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants