BackyardEOS 3.1.0 Release Candidate 04 is ready for download.

[admin]

BackyardEOS 3.1.0 Release Candidate 04 is ready for download. 

 

I'm hoping this is the last RC before full production release... unless of course a major issue is found.

 

Free upgrade from 3.0.x to 3.1.0 to everyone as usual.

Change log (from RC03)

- bug fix: Image rotation when camera was on its side.

- bug fix: Images, specifically darks, are now properly displayed.

- bug fix: Histogram control not rendering properly on very rare occasion.

- bug fix: Planetary recording .avi files was not always copied to your download folder, it was left in the TEMP folder.

- bug fix: JPG image are now -always- created when AstroTortilla is used to capture an image for plate solving... even if you have selected RAW only.

- bug fix: If you had selected <sequence> in your file name template images were not copied to download folder.

- change: <sequence> in file name template now use in-camera image number for sequence when images are store to "PC+Camera", otherwise it starts at 1 between BYE restart.

- change: Box grid in Drift Align, removed inner circle.

- Testing on XP, Vista, W7, and W8

 

This Release Candidate will NOT overwrite your current v3.0.x installation.

http://www.binaryrivers.com/download/setup-BackyardEOS-v310-RC04.exe

 

PLEASE REPORT ISSUES using RC04 in this thread.

 

Thank you,

[dts350z]

Just for predicting exposure. 

 

I haven't checked the "linearity" of this latest version with updated DCRAW settings, but in 3.0 I could predict the proper exposure at iso 1600 with a short preview shot at iso 12800. a good 60 sec jpeg histogram at iso 12800 meant a good raw histogram with 480 seconds @ iso 1600. If this latest version acts like that, I guess I don't need raw previews. I just figured that with raw previews there wouldn't be any surprises with different histograms (jpeg vs. raw).

 

 

 

 

 

[admin]

Just for predicting exposure. 

 

I haven't checked the "linearity" of this latest version with updated DCRAW settings, but in 3.0 I could predict the proper exposure at iso 1600 with a short preview shot at iso 12800. a good 60 sec jpeg histogram at iso 12800 meant a good raw histogram with 480 seconds @ iso 1600. If this latest version acts like that, I guess I don't need raw previews. I just figured that with raw previews there wouldn't be any surprises with different histograms (jpeg vs. raw).

 

 

Well... I predict you will see next to zero difference between linearity between raw and jpg... I predict the linearity will be maintained just the same in RC4... fingers crossed

 

I'm willing to bet a cold beer

 

Regards,

[dts350z]

I just ended up my imaging session and Dark Master told me one of my sub files was only 1 second in duration, when the file name was marked 480s.

 

Viewing file it is dark/just noise. Clearly this should have been in the Abort folder or something?

 

Let me know if you want the logs.

 

 

 

[admin]

I just ended up my imaging session and Dark Master told me one of my sub files was only 1 second in duration, when the file name was marked 480s.

 

Viewing file it is dark/just noise. Clearly this should have been in the Abort folder or something?

 

Let me know if you want the logs.

 

 

 

I'll run a few tests but if is was aborted the file name should start with "ABORT", if is does not that is a bug.

 

What does the exif data tells you?  1 second or 480 seconds?

 

Does that dark look anywhere close to the other 480 seconds darks?  Trying to find out if this is a BYE issue of DM.

 

Regards,

[dts350z]

Well if I could load the image back into BYEOS, without a camera, I could tell you the EXIF data 

 

It must be 1 sec. Where else would Dark Master get the info from?

 

...OK, Picasa can load CR2 and read EXIF. It says 1 second.

 

RE Darks, I did not take darks on that object, but I do remember switching to "dark" before changing the object name to "DARKLIB" and this is the last image (by time stamp) in the object folder.

 

The file name contains "LIGHT", however. I did do an ABORT during dithering or just after, as the fog had rolled in on my last exposure. Checking the ABORT directory... Yeah, there a 11s abort image there, but it's time stamp is from the end of the darks, not the lights. Oh yeah, the abort file name has "dark" as well. No aborts from the lights, I would have thought there would be some, unless each abort was during dithering.

 

No, the 1 second light file "looks" different than the 8 min dark I took next. It's strange. it looks like a high iso high temperature dark. Lots of noise with the (picasa) histogram spread over the left half in a lowish hump. In the 480 sec dark there is less noise and the histogram is hard left and reaches the top.

 

 

[admin]

Well if I could load the image back into BYEOS, without a camera, I could tell you the EXIF data 

 

It must be 1 sec. Where else would Dark Master get the info from?

 

...OK, Picasa can load CR2 and read EXIF. It says 1 second.

 

RE Darks, I did not take darks on that object, but I do remember switching to "dark" before changing the object name to "DARKLIB" and this is the last image (by time stamp) in the object folder.

 

The file name contains "LIGHT", however. I did do an ABORT during dithering or just after, as the fog had rolled in on my last exposure. Checking the ABORT directory... Yeah, there a 11s abort image there, but it's time stamp is from the end of the darks, not the lights. Oh yeah, the abort file name has "dark" as well. No aborts from the lights, I would have thought there would be some, unless each abort was during dithering.

 

No, the 1 second light file "looks" different than the 8 min dark I took next. It's strange. it looks like a high iso high temperature dark. Lots of noise with the (picasa) histogram spread over the left half in a lowish hump. In the 480 sec dark there is less noise and the histogram is hard left and reaches the top.

 

 

 

Odd, send me both log files and I'll try to reconstruct the events as they occurred.

 

Regards,

[dts350z]

It happened again last night. A file that should have been 480 seconds is named:

 

ETN UL_LIGHT_480s_3200iso_+77f_00076stdev_20140823-22h30m31s015ms.CR2

 

but is only a 1 second exposure, according to the EXIF data and is dark and noisy.

 

The disturbing thing is I'm pretty sure that was a 480 second exposure. I was doing a mosaic and took 4 exposures for each mosaic "frame". The particular frame/folder has (only) the four 480 second named files, but the last one is 1 second, so I only got three good exposures.

 

I think the bug may be somehow related to an abort, because I had originally planed 6 exposures per mosaic frame, but in this frame I decided to cut it down to 4, so as not be out too late, and aborted after the 4th exposure.

 

Is it possible that aborting during the dither/download/load/dcraw process is causing the bug?

 

I will send logs.

 

 

 

 

[dts350z]

OK good news (for my "missing" exposure anyway).

 

This file:

 

"C:\Users\gnewell\Pictures\BackyardEOS\ABORT\2014-08-23\ABORT_LIGHT_480s_3200iso_+48f_01640stdev_20140823-23h12m01s690ms.CR2"

 

is my "missing" 480 seconds exposure. So it looks as if the "abort bug" is putting the good file in the abort folder, and a 1 second aborted file (?) in the "good" folder.

 

 

 

[admin]

OK good news (for my "missing" exposure anyway).

 

This file:

 

"C:\Users\gnewell\Pictures\BackyardEOS\ABORT\2014-08-23\ABORT_LIGHT_480s_3200iso_+48f_01640stdev_20140823-23h12m01s690ms.CR2"

 

is my "missing" 480 seconds exposure. So it looks as if the "abort bug" is putting the good file in the abort folder, and a 1 second aborted file (?) in the "good" folder.

 

 

 

 

No matter what I do here I can not reproduce.

 

I think the issue may be related to the sub-folder.  What sub-folder config are you using in settings?

 

Regards,

[dts350z]

Date Style 2

 

 

[dts350z]

Also, in case you didn't notice, I have spaces in my target name. "ETN UL" in this case. Elephant Trunk Nebula space Upper Left.

[admin]

Also, in case you didn't notice, I have spaces in my target name. "ETN UL" in this case. Elephant Trunk Nebula space Upper Left.

 

Yeah, I tested that inside out and it works as advertised so space in the name is not the cause.

 

Thanks,

 

 

[imarek]

Hello Ghylain,

always a little problem with DriftAlign mode in RC4. Typically with rotate function using arrow or mouse wheel. The Drift Alignment Image Center becomes black !

Here is a part of my Log.

 

Regards,

Lionel

 

-----------------------------------

2014-08-26 14:45:28,457 [Main] INFO  - Application state changed: 'DriftAlign'

2014-08-26 14:45:28,473 [PropertyGet] DEBUG - IGNORE: PropertyEvent_PropertyChanged Fired! (PropertyId=PropID_Evf_OutputDevice), (inParam=0)

2014-08-26 14:45:28,489 [PropertyGet] DEBUG - SKIP: PropertyEvent_PropertyChanged Fired! (PropertyId=PropID_Evf_DepthOfFieldPreview), (inParam=0)

2014-08-26 14:45:28,504 [PropertyGet] DEBUG - SKIP: PropertyEvent_PropertyChanged Fired! (PropertyId=PropID_Evf_ExposureSimMode), (inParam=0)

2014-08-26 14:45:32,810 [Main] ERROR - Input string was not in a correct format.

2014-08-26 14:45:32,810 [Main] ERROR -    at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)

   at BinaryRivers.BackyardEOS.Modes.DriftAlignMode.DisplayImage(Bitmap image)

2014-08-26 14:45:32,950 [Main] ERROR - Input string was not in a correct format.

2014-08-26 14:45:32,950 [Main] ERROR -    at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)

   at BinaryRivers.BackyardEOS.Modes.DriftAlignMode.DisplayImage(Bitmap image)

 

[admin]

Hello Ghylain,

always a little problem with DriftAlign mode in RC4. Typically with rotate function using arrow or mouse wheel. The Drift Alignment Image Center becomes black !

Here is a part of my Log.

 

Regards,

Lionel

 

-----------------------------------

2014-08-26 14:45:28,457 [Main] INFO  - Application state changed: 'DriftAlign'

2014-08-26 14:45:28,473 [PropertyGet] DEBUG - IGNORE: PropertyEvent_PropertyChanged Fired! (PropertyId=PropID_Evf_OutputDevice), (inParam=0)

2014-08-26 14:45:28,489 [PropertyGet] DEBUG - SKIP: PropertyEvent_PropertyChanged Fired! (PropertyId=PropID_Evf_DepthOfFieldPreview), (inParam=0)

2014-08-26 14:45:28,504 [PropertyGet] DEBUG - SKIP: PropertyEvent_PropertyChanged Fired! (PropertyId=PropID_Evf_ExposureSimMode), (inParam=0)

2014-08-26 14:45:32,810 [Main] ERROR - Input string was not in a correct format.

2014-08-26 14:45:32,810 [Main] ERROR -    at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)

   at BinaryRivers.BackyardEOS.Modes.DriftAlignMode.DisplayImage(Bitmap image)

2014-08-26 14:45:32,950 [Main] ERROR - Input string was not in a correct format.

2014-08-26 14:45:32,950 [Main] ERROR -    at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)

   at BinaryRivers.BackyardEOS.Modes.DriftAlignMode.DisplayImage(Bitmap image)

 

 

Send me the full log file, seeing what lead the the error is key in finding the root cause.  Send it to support@binaryrivers.com.

 

Regards,

[dts350z]

I had BYEOS RC04 get stuck in 5x mode on frame and focus tonight. The button turned off but the display was still 5x.

 

Only going to image mode and back would clear it.

 

 

 

[admin]

I had BYEOS RC04 get stuck in 5x mode on frame and focus tonight. The button turned off but the display was still 5x.

 

Only going to image mode and back would clear it.

 

 

 

Send me the log file.  Nothing has changed there since v3.0.0 was released last year <_>

 

Regards,

[dts350z]

Last night's strangeness is one of my 480 second exposures has EXIF data showing 481 seconds. The file name says 480s.

 

 

 

[admin]

Last night's strangeness is one of my 480 second exposures has EXIF data showing 481 seconds. The file name says 480s.

 

 

 

No, not strange... this has been brought up for years.

 

Windows timers are not that exactly accurate.  It will occur from time to time where an exposure will be off by 1 seconds.  This impact on long exposure however is not that much, almost nothing actually, so use that exposure just the same.

 

The seconds in the file name comes from the capture plan.

 

Regards,

[dts350z]

OK thanks.

 

Do you happen to know if there is a utility to edit EXIF data. I'd like to set it back to 480 so DarkMaster and DSS don't treat it as a separate case, for which I don't have matching calibration files.

 

 

 

[admin]

OK thanks.

 

Do you happen to know if there is a utility to edit EXIF data. I'd like to set it back to 480 so DarkMaster and DSS don't treat it as a separate case, for which I don't have matching calibration files.

 

 

 

Exiftool can do it... come to think of it maybe I should do it automatically?

 

 

[dts350z]

Wouldn't hurt to be a setting, in case purists would prefer to leave it alone.

[s3igell]

OK thanks.

 

Do you happen to know if there is a utility to edit EXIF data. I'd like to set it back to 480 so DarkMaster and DSS don't treat it as a separate case, for which I don't have matching calibration files.

 

 

 

Exiftool can do it... come to think of it maybe I should do it automatically?

 

 

While it would be nice if the resolution of the Timer used to trigger the End-of-Image were tighter, I'm guessing that there is too much going on within Windows and VS to gain much additional accuracy...

 

If that is the case, then adjusting the EXIF Data (would need to be thorough to hit all the data items which include Exposure Duration) is the next best solution.

Since there have been some issues with aborted exposures of substantially different durations, should you perhaps embed a rule that you only "Adjust EXIF Exposure" by max 1sec ??  That would cover the cases where the issue is "slow propagation of a command" rather than ones where Abort or other issues produce a wildly short exposure...

[admin]

Since there have been some issues with aborted exposures of substantially different durations, should you perhaps embed a rule that you only "Adjust EXIF Exposure" by max 1sec ??  That would cover the cases where the issue is "slow propagation of a command" rather than ones where Abort or other issues produce a wildly short exposure...

 

Actually exposure duration for all bulb command in the CR2 exif data is rounded to the next 1 second by Canon anyway.

 

Regards,

[Ron Hillstromb]

Hello

 

  I have noticed that I get a number to pop up in the box where I would expect to see the number of images being processed.  I have no images to be processed but a number shows from time to time.  Usually when I start BYE there is a number as well as at what appears to be random times.

 

  Using my own, probably distorted, logic I expect it is the Backgrounder processing a task in the background.  I haven't lost any images or gained any either.  I would just like to know if in fact it is just the Backgrounder program processing a task, like getting the weather data or such so I don't let it distract me.

 

Ron

[admin]

Hello

 

  I have noticed that I get a number to pop up in the box where I would expect to see the number of images being processed.  I have no images to be processed but a number shows from time to time.  Usually when I start BYE there is a number as well as at what appears to be random times.

 

  Using my own, probably distorted, logic I expect it is the Backgrounder processing a task in the background.  I haven't lost any images or gained any either.  I would just like to know if in fact it is just the Backgrounder program processing a task, like getting the weather data or such so I don't let it distract me.

 

Ron

 

That is because reading the "Weather Center Info" is also dispatched to the background worker and when it does you'll see the counter go up be one for a few second then go back down by 1.

 

Regards,

 

 

[Ron Hillstromb]

Thanks. 

 

Ron

[admin]

I have locked this thread because BackyardEOS v3.1 RC05 is released and ready for download.

 

http://forum.otelescope.com/post/backyardeos-3-1-0-release-candidate-05-is-ready-for-download-7087384

 

Thank you

[ldesign1]

OK thanks.

 

Do you happen to know if there is a utility to edit EXIF data. I'd like to set it back to 480 so DarkMaster and DSS don't treat it as a separate case, for which I don't have matching calibration files.

 

 

I use [ExiftoolGUI version 5.15] to modify EXIF.

 

Here's a link.

 

http://u88.n24.queensu.ca/exiftool/forum/index.php?board=7.0

 

Ralph