Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

BackyardEOS 3.1.0 Release Candidate 03 is ready for download.


admin

Question

BackyardEOS 3.1.0 Release Candidate 03 is ready for download.

 

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

 

I still had some issues with image being downloaded in the TEMP folder but was not copied to your selected download folder.  The bug seems to be related to the new commercial library (GdPicture API) I purchased to load raw images <_ and it seems to be a the heart of several issues including performance issues. in this rc03 i no longer using gdpicture decided use dcraw load raw image data. have sent build users who repeatably reported with rc01 rc02. all bug fix so hopeful is now behind me fingers crossed.>

 

Change log (from RC02)

- JPG and RAW images now have the same time stamp as in V3.0.x.

- Using DCRAW to load raw images for stability and performance.

- Minor performance improvement

- 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-RC03.exe

 

PLEASE REPORT ISSUES using RC03 in this thread.

 

Thank you,

Link to comment
Share on other sites

  • Answers 40
  • Created
  • Last Reply

Recommended Posts

Hello Guylain

 

  I am still having the same problems with jpg file names being about 500 ms later than the CR2 and Exif txt file name.

 

Ron

 

Grrr, I forgot to upload the latest setup file.  Give about 30 minutes and download RC03 again.

 

Sorry.

 

 

Link to comment
Share on other sites

I don't know much about DCRAW or what is really does, (I leave that sort of stuff to you code guys)  but I do know that Pixinsight invokes it when calibrating/debayering Canon CR2 files for integration.  If there is an outside chance that it being part of both applications will make any sort of positive difference in my using both BYEOS and Pixinsight for my imaging software kit, then I'm all over this like white on rice. B)

Link to comment
Share on other sites

I don't know much about DCRAW or what is really does, (I leave that sort of stuff to you code guys)  but I do know that Pixinsight invokes it when calibrating/debayering Canon CR2 files for integration.  If there is an outside chance that it will make any sort of positive difference in my using both BYEOS and Pixinsight for my imaging software kit, then I'm all over this like white on rice. B)

 

Is is completely irrelevant to what PixInsight does.  BYE uses DCRAW to load the image to display it, it does not alter the RAW image data in your .cr2 file in any way.

 

Hope this helps,

 

 

Link to comment
Share on other sites

I don't know much about DCRAW or what is really does, (I leave that sort of stuff to you code guys)  but I do know that Pixinsight invokes it when calibrating/debayering Canon CR2 files for integration.  If there is an outside chance that it will make any sort of positive difference in my using both BYEOS and Pixinsight for my imaging software kit, then I'm all over this like white on rice. B)

 

Is is completely irrelevant to what PixInsight does.  BYE uses DCRAW to load the image to display it, it does not alter the RAW image data in your .cr2 file in any way.

 

Hope this helps,

 

 

I understand BYOES only uses DCDRAW to load the data files, but does it have the capability to do anything else?  Or is it just for data transfer?

 

Not that it really matters to me, if you deem it good enough for BYEOS and Pleiades thinks it's good enough for PixInsight, then I'm a happy camper.  I'm a user, not a designer.  All I really need is a rudimentary knowledge of what is going on.

 

 

Link to comment
Share on other sites

Hello Guylain

 

  All of the features I reported problems on are working as expected now.  All testing was Dining table top and included planetary just in case.  Never had any problems with planetary anyhow.

 

  Thanks for your efforts.

 

  Hope you make it out camping this weekend.

 

Ron

Link to comment
Share on other sites

In RC01 while BYEOS was still taking images I was reviewing some of the images already taken to look at their quality.  I selected an image by clicking on the thumbnail image below the main image.  I then expanded the image to 100% to look for star trails.  When I clicked the button to again Fit the image to the screen the image was displayed rotated 90 degrees, i.e., horizontal was now up and down, and, up and down was now horizontal.  The image was reduced in size so that the entire original horizontal FOV now fit in the vertical direction.  I was not able to get the image to display "un-rotated" in the Fit to Screen mode.

 

Steve

Link to comment
Share on other sites

In RC01 while BYEOS was still taking images I was reviewing some of the images already taken to look at their quality.  I selected an image by clicking on the thumbnail image below the main image.  I then expanded the image to 100% to look for star trails.  When I clicked the button to again Fit the image to the screen the image was displayed rotated 90 degrees, i.e., horizontal was now up and down, and, up and down was now horizontal.  The image was reduced in size so that the entire original horizontal FOV now fit in the vertical direction.  I was not able to get the image to display "un-rotated" in the Fit to Screen mode.

 

Steve

 

Can you post a screen shoot?

 

Thank you

 

 

Link to comment
Share on other sites

Hello Guylain

 

  All of the features I reported problems on are working as expected now.  All testing was Dining table top and included planetary just in case.  Never had any problems with planetary anyhow.

 

  Thanks for your efforts.

 

  Hope you make it out camping this weekend.

 

Ron

 

Yeah, thank you Ron for your patience :)

 

Regards,

Link to comment
Share on other sites

OK, I'm taking dark flats.

 

I put the lens cap on, and do a preview and get a dark pic with the histogram hard left, as expected.

 

http://glenn.ws/web/images/PREVIEW_20140731-20h40m25s064ms.JPG

 

Now I start capture, but instead of pics like the above I get noisy pics with big fat histograms:

 

http://glenn.ws/web/images/LEDFLATS_DARK_FLAT_Tv1-13s_1600iso_+68f_02203stdev_20140731-20h40m05s673ms.CR2

 

I checked the EXIF data and both ARE at the same exposure, so what's up? Is the DC RAW lib "boosting" the values to display in 8 bits or something?

 

Seems like it would be difficult to use  previews and histograms to judge exposures under these conditions.

 

I thought I noticed something funny the other night (with RC3). Previewing at 12800 iso to get the exposure and then multiplying that shutter time * 8 to image at 1600 ISO was way over exposed, as judged by the raw histogram.

 

I guess I can do a capture plan of 1 instead of a preview but I don't think this is the desired behavior.

 

 

 

 

 

 

 

Link to comment
Share on other sites

OK, I'm taking dark flats.

 

I put the lens cap on, and do a preview and get a dark pic with the histogram hard left, as expected.

 

http://glenn.ws/web/images/PREVIEW_20140731-20h40m25s064ms.JPG

 

Now I start capture, but instead of pics like the above I get noisy pics with big fat histograms:

 

http://glenn.ws/web/images/LEDFLATS_DARK_FLAT_Tv1-13s_1600iso_+68f_02203stdev_20140731-20h40m05s673ms.CR2

 

I checked the EXIF data and both ARE at the same exposure, so what's up? Is the DC RAW lib "boosting" the values to display in 8 bits or something?

 

Seems like it would be difficult to use  previews and histograms to judge exposures under these conditions.

 

I thought I noticed something funny the other night (with RC3). Previewing at 12800 iso to get the exposure and then multiplying that shutter time * 8 to image at 1600 ISO was way over exposed, as judged by the raw histogram.

 

I guess I can do a capture plan of 1 instead of a preview but I don't think this is the desired behavior.

 

 

 

 

 

 

 

Your cr2 link is broken so I can't download it <_>

 

A preview is a JPG image as-is from the camera.  In this respect the camera firmware is processing the image, including white balance.

 

A capture plan image in RC03 is loaded using DCRAW with the following parameters...

 

-c        Write image data to standard output

-w        Use camera white balance, if possible

-h        Half-size color image (twice as fast as "-q 0")

-T        Write TIFF instead of PPM

 

In this RC03 I chose to use the -h parameter so speed things up (this is not high quality but it is important to note that RAW data remains unchanged and is of high quality, only the image display on screen is of less quality), I suspect the -h parameter may be the cause.  However, I have taken over 1000 images with 3 different cameras before releasing and I did not see the behavior your are seeing.

 

I'll run some tests with and without the -h parameter and try the -q 4 parameters for highest quality.

 

I'll also try the -6 parameter for loading 16 bits instead of 8 bits.

 

DCRAW is a proven alternative, looks like it will take a round or two to nail down the perfect combination of parameters for both performance and quality.

 

Thanks for posting,

 

 

 

 

 

 

 

Link to comment
Share on other sites

Also it occurs to me that trying to mach the in camera jpeg histogram may not be what we want anyway? I think that was an issue brought up before?

 

If so, maybe an option to preview with raw vs. jpeg? 

 

Sure, we still need to understand the DCRAW histogram and make sure it's correct, but it might be a good idea to fix the any/all preview vs. image capture differences at the same time.

 

DCRAW is very very fast, at least on my laptop, so I wouldn't see any downside to preview via raw.

Link to comment
Share on other sites

Also it occurs to me that trying to mach the in camera jpeg histogram may not be what we want anyway? I think that was an issue brought up before?

 

If so, maybe an option to preview with raw vs. jpeg? 

 

Sure, we still need to understand the DCRAW histogram and make sure it's correct, but it might be a good idea to fix the any/all preview vs. image capture differences at the same time.

 

DCRAW is very very fast, at least on my laptop, so I wouldn't see any downside to preview via raw.

 

You can already preview images in RAW.  Just go to settings and select "in-camera" for image quality.  BYE will use your current camera setting, just make sure it is RAW.

 

Regards,

Link to comment
Share on other sites

Guylain,

 

3.1 RC3 Is giving me pink pictures!

 

In the screen capture attached the first thumbnail is a JPG preview and the second is a CR2 from the image capture plan. As you can see the RAW pictures have a 'nice' pink tinge! I have repeated this a few times closing and re-starting BYE 3.1 RC3 between attempts.

 

The histogram of the JPGs is roughly spread across the whole graph, see below, whereas as you can see in the RAW pictures all that shows is a few spikes.

 

 

post-3081932-141893877131_thumb.jpg 

 

 

 

 

I'm running BYE under Windows 8.1.

 

Same scene but with a JPEG preview selected to display.

 

 

post-3081932-141893877141_thumb.jpg 

 

With BYE 3.0.3 the JPG and RAW are very similar.

 

 

*** Added 02/08/2014 Forgot to say the actual CR2 RAW file displays fine in other display software and looks similar to the JPEG. *******

 

Regards

 

Jim

 

 

 

Link to comment
Share on other sites

I just tried RC03 and have the same issue with the color balance being off when displaying CR2 images. The displayed histogram has the 3 colors widely separated with red being well to the right and blue being well to the left.  This gives the image a violet cast.

 

The copy that was stored in the camera displays correctly on the LCD display.

 

My guess is that the in-camera color balance is not being applied correctly to the raw image when it is converted for rendering.

Link to comment
Share on other sites

I just tried RC03 and have the same issue with the color balance being off when displaying CR2 images. The displayed histogram has the 3 colors widely separated with red being well to the right and blue being well to the left.  This gives the image a violet cast.

 

The copy that was stored in the camera displays correctly on the LCD display.

 

My guess is that the in-camera color balance is not being applied correctly to the raw image when it is converted for rendering.

 

Right now my best guess is that DCRaw does not apply the WB properly, or at least it applies it differently.  I'll run a few test with reading the image in 16 bits instead of the default 8 bits and see if that renders the image more closely to what the in-camera rendering does.

 

Regards,

Link to comment
Share on other sites

Guylain, what is the best way to uninstall Candidate 01 and 02? Through Control Panel or just by deleting subdirectory?

Jerry

 

BackyardEOS 3.1.0 Release Candidate 03 is ready for download.

 

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

 

I still had some issues with image being downloaded in the TEMP folder but was not copied to your selected download folder.  The bug seems to be related to the new commercial library (GdPicture API) I purchased to load raw images <_< and it seems to be a the heart of several issues, including performance issues.  In this RC03 I'm no longer using GdPicture, I decided to use DCRAW to load raw image data.  I have sent this build to 3 users who have repeatably reported issues with RC01 and RC02.  All 3 users reported the bug fix so I'm hopeful this is now behind me, fingers crossed.

 

Change log (from RC02)

- JPG and RAW images now have the same time stamp as in V3.0.x.

- Using DCRAW to load raw images for stability and performance.

- Minor performance improvement

- 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-RC03.exe

 

PLEASE REPORT ISSUES using RC03 in this thread.

 

Thank you,

Link to comment
Share on other sites

Guylain, what is the best way to uninstall Candidate 01 and 02? Through Control Panel or just by deleting subdirectory?

Jerry

 

BackyardEOS 3.1.0 Release Candidate 03 is ready for download.

 

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

 

I still had some issues with image being downloaded in the TEMP folder but was not copied to your selected download folder.  The bug seems to be related to the new commercial library (GdPicture API) I purchased to load raw images <_ and it seems to be a the heart of several issues including performance issues. in this rc03 i no longer using gdpicture decided use dcraw load raw image data. have sent build users who repeatably reported with rc01 rc02. all bug fix so hopeful is now behind me fingers crossed.>

 

Change log (from RC02)

- JPG and RAW images now have the same time stamp as in V3.0.x.

- Using DCRAW to load raw images for stability and performance.

- Minor performance improvement

- 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-RC03.exe

 

PLEASE REPORT ISSUES using RC03 in this thread.

 

Thank you,

 

Both, first control panel.  This will uninstall it properly... but the config files are left behind so you need to delete the folder afterwards.

 

Regards,

Link to comment
Share on other sites

Guylain,

 

Another thing that I have noticed with RC03 is that shortening the exposure time causes the displayed image to become more washed out (approaching white) and shortening the exposure and lowering the F/stop value causes the image to darken and the histogram peaks to shift to the left.

 

This is may also be related to some issue with DCRAW.

 

 

Link to comment
Share on other sites

Guylain,

 

Another thing that I have noticed with RC03 is that shortening the exposure time causes the displayed image to become more washed out (approaching white) and shortening the exposure and lowering the F/stop value causes the image to darken and the histogram peaks to shift to the left.

 

This is may also be related to some issue with DCRAW.

 

Thanks Rick. I'm out camping with my wife this weekend... I'll check that later this week. Regards,
Link to comment
Share on other sites

Please also check the linearity. e.g. I want to take previews at the highest possible iso, and use those to estimate the exposure at the iso I'll be imaging at.

 

The logic is these are are equivalent (in terms of histogram results):

 

60 seconds @ 12800

120 seconds @ 6400

240 seconds @ 3200

480 seconds @ 1600

etc.

 

With RC3 that's not the case. It takes a lot less exposure, at say 1600, than the exposure at 12800 would indicate.

 

Also the histigrams for captures are spread out compared to previews. It's like DCRAW is zooming in on the small section of the preview histogram (in addition to different white balance).  

 

Thanks

 

 

Link to comment
Share on other sites

 

 

Both, first control panel.  This will uninstall it properly... but the config files are left behind so you need to delete the folder afterwards.

 

Regards,

 

Candidate 01 and 02 uninstalled. Took less then a minute.

Jerry

Link to comment
Share on other sites

In RC01 while BYEOS was still taking images I was reviewing some of the images already taken to look at their quality.  I selected an image by clicking on the thumbnail image below the main image.  I then expanded the image to 100% to look for star trails.  When I clicked the button to again Fit the image to the screen the image was displayed rotated 90 degrees, i.e., horizontal was now up and down, and, up and down was now horizontal.  The image was reduced in size so that the entire original horizontal FOV now fit in the vertical direction.  I was not able to get the image to display "un-rotated" in the Fit to Screen mode.

 

Steve

 

Can you post a screen shoot?

 

Thank you

 

Sorry but I don't have a screen shot.  My mount is back for repair, so, maybe I can play with the camera indoors to see if I can recreate the problem.

 

Steve

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use