Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - pfile

Pages: 1 2 [3] 4 5 ... 277
31
i'm really disappointed in the thermal performance of these new macbooks... clearly there was no margin designed in.

rob

32
General / Re: Improving my glob cluster results
« on: 2019 July 29 20:53:25 »
what adam is saying is the fits file you posted is useless, because your processing is baked into it permanently. no one can process it any differently, or offer you any advice, because the image is already stretched.

if you want processing advice you have to post linear images.

rob

33
i think #4 is the most important question. my answer to anyone that asks about creating grey OSC flats is that it doesn't matter - after all, if you are using a mono camera and filters no one ever tries to make sure the flats are balanced against one another, only that they are well exposed. i realize that "well exposed" usually ends up with each flat having a similar histogram, and thus if you made an RGB image out of the flats it would be nearly grey, but that is a side effect, not a goal.

the guy at CN was saying that the SNR of the red channel of the integrated image was lower if he did not first normalize his flat. i can believe that because of the way PI weights integration input images, that there could be something to this. however it looks like bernd could not reproduce that.

regardless, there's only one scaling factor computed for a CFA flat, so it does make sense that a dimmer flat channel will be artificially boosted during the subsequent division into the light. if that has a knock-on effect of creating a suboptimal integration for the weak-flat channel, then that's bad.

if it were not for this, i too would just say "hey just do BN and CC and forget about it, as long as you have enough flat subs such that the weak flat channel has a decent SNR". but if the SNR loss is real then it bears investigation.

rob

34
is it possible this is a color space problem? usually before uploading i do ICCProfileTransformation to bring the image in-gamut for sRGB. for a while i wasn't tagging the image with AssignICCProfile because astrobin seemed to have some problem with tagged images, but i'm told this is fixed now.

rob
 

35
General / Re: K-Value versus statistics
« on: 2019 July 27 13:45:40 »
that's good to know, i didn't see that thread. i don't really agree with jared that CR2/unscaled FITS data would necessarily still be incompatible.

anyway for me this is largely a thing of the past for me, though ironically rescaling of the 14-bit data into 16-bit space was necessary when processing my 2017 eclipse images.

rob

36
General / Re: K-Value versus statistics
« on: 2019 July 27 08:39:08 »
yes you are right, these libRAW/DCRAW options are normalizing the data to [0,1] rather than just scaling the data to 16-bit.

i don't know why SGP chose to do the expansion; it has been several years since i looked at this but i seem to recall they are just using DCRAW in a similar fashion to normalize the data. i guess if a driver expands the x-bit data to 16-bits then in my mind that's sort of part of the hardware, but the canon SDK does not do this and so i would have hoped that SGP left the data alone - to me it's a sin for a capture application to silently modify the data coming from the camera. i did ask the developers about adding an option not to do this in SGP but they did not want to change things - once they started doing it this way it was too late. but it does make CR2 and FITS from SGP incompatible with one another which occasionally leads to people having trouble with calibration.

rob

37
thank you for posting this - i had hoped the CN poster would ask over here and as you say s/he never did, so it is good to have juan's input on this. the SNR problem is also was was concerning to me, but i was too lazy to try to reproduce it.

rob

38
General / Re: K-Value versus statistics
« on: 2019 July 26 17:07:07 »
your understanding is correct - but it does go farther than this. some canon cameras have 12-bit ADCs so in that case 4095/65535 would be full saturation (0.0625). however there haven't been any 12-bit cameras from canon in a long time so this is probably not something we'll see a lot more of.

i don't know if it is universally true that FITS files will be expanded, but it is true that Sequence Generator Pro expands non-16 bit data to fill the 16-bit space before writing a FITS file from a connected DSLR. i don't know what other capture programs do but there's nothing that says they have to behave this way if writing out FITS.

with PI now using libRAW i'm not sure if there is an option to expand the data. i think DCRAW could do it but i'm not sure if there was a way to configure PI so that it would call DCRAW with the argument it wants to do the expansion (-d). i think perhaps in libRAW unticking the "no highlights clipping" checkbox will expand the data, since it mentions the "pink shades" issue you sometimes see with 14-bit cameras when the data has not been expanded.

rob

39
one thing i would do to make your life easier is to put a slightly pink t-shirt over the telescope when taking flats. that will balance the flat histogram a little better. it's not mandatory but will make sure the SNR of your flat's red channel is on par with the SNR of the other channels. of course when you do this you will have to increase your flat exposure and the method will likely not work with twilight flats unless you take some seriously long flats.

rob

40
you'll have to do something like this: create the starless image, then load both the starless image and the original image, and subtract the starless image from the original using pixelmath. if you are using mono images, now you have the best starmask that could ever be created. if using RGB images, you'll probably want to extract the L* from the difference image and use that as a star mask. maybe for good measure you might blur the star mask just a little bit with Atrous.

then you can do any number of things including the typical morphological transformation to dim down stars, or perhaps do a different stretch of the original image where the stars are not pushed as much, and then use pixelmath to replace the stars in the original image, thru the mask, with the dimmer stars.

rob

edit: also i forgot that of course you could blend the starless and original images together with pixelmath. although there are probably some screen-type formulae that might work best, doing a weighted average of the two images would probably be a reasonable start.

41
General / Re: Bayer pattern for Canon 2000D Super UV-IR Cut
« on: 2019 July 25 12:40:37 »
aldo, this is exactly what bernd is saying. the current libRaw included in PI 1.8.7 apparently can only partially handle a 2000D CR2 file.

try waiting for the next release of pixinsight if bernd's suggestions for fixing your files are too hard to do.

rob

42
ok so that warning just means that if you come up with a tensorflow.dll that better supports your cpu it will run faster. i think the PI module checks if it can run and won’t install if it can’t, the most common reason being that the cpu lacks the minimum set of vector instructions. so that’s not the problem you’re having.

as for how to install the PI module, i am not sure since i usually use macosx and haven’t tried installing it on my windows machine (the module only exists for windows at this time.)

rob

43
i wonder if the Xeon processors don't have all the vector instructions that the starnet module needs. a sanity check is to download starnet++ and see if it runs.

https://sourceforge.net/projects/starnet/

rob

45
that looks right for an SHO narrowband image. glad it is solved.

rob

Pages: 1 2 [3] 4 5 ... 277