From Stefanie Milam (firstname.lastname@example.org), working with John Stansberry, reported at ETC review #2:
For any extended source it makes more sense for the spectrum to be normalized in surface brightness units (MJy/sr, mJy/square-arcsec,...). The ETC currently seems to normalize the spectrum such that the *areal-integral* of the flux-density from the source is normalized to whatever value the user requests.
A symptom of not doing the normalization in SB units is that if you put in an extended source (say it has 10"^2 area when you define it), normalize the flux to 1mJy at some wavelength, then go back and change the area of the source, the brightness of the object per pixel changes (so if the adjusted source is 4"^2, it would end up being 2.5x brighter after the change).
That symptom tends to show up because of a bug, and a separate 'feature' of the ETC:
Bug) The dimensions of extended elliptical sources
weren't correctly implemented, at least in the
scene sketch view. E.g. and ellipse specified
with a 'major axis' of 4" ended up being 8"
across. I think that may only affect the scene
sketch, not the calculation-tab detector view,
but that just made it even more confusing.
Feature) The detector view on the calculations tab
is extremely limited in size, and varies without
warning (or even info being provided), depending
on the type of calculation. So, it's impossible
to make a full-size Jupiter due to the size limit,
and even if you make a mini-Jupiter it may fit
in the FOV for a MIRI calc, but not for a NIRCam
calc. Then you have to go muck with the extended
source size, and then the issue of not working
in surface brightness means that the source
gets brighter or dimmer when you change its size.
This could be improved if the user could
specify the size of the scene they want, up to
some reasonable limit (20" across?), and that
the size applies regardless of what instrument
or mode is used for a calculation. It could
default to something smaller, and maybe just
have a fixed, small size for point sources,
but the current implementation is really hard
to work with when trying to plan multi-mode