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

Image orientation & TIFF problem


geoconrad

Question

BYE Premium v 3.1.16 Canon 100D / SL1 modified  / Skytech CLS CCD filter.

Thanks for the help on how to obtain a TIFF image. However, the TIFF images I get are black with only faint smudges of very bright stars.  The RAW/CR2/JPEG images are OK.

Also, with the Auto Rotate feature OFF, the TIFF / JPEG images are LANDSCAPE regardless of camera orientation (as they should be) but the RAW/CR2 images follow the camera orientation PORTRAIT or LANDSCAPE as appropriate.

Any help appreciated.

George

Link to comment
Share on other sites

  • Answers 10
  • Created
  • Last Reply

10 answers to this question

Recommended Posts

I'm still confused (88 tomorrow and easily confused :wacko:). The CR2 images follow the camera orientation regardless of Auto Rotate selection, the JPG copies obey the Auto Rotate selection, and the TIFF copies are landscape always.  I would do my stacking, etc. using CR2 except for the inconvenience of the Landscape / Portrait issue.  I tried converting the CR2 to TIFF using Pixilion.  Good results compared to the BYE TIFF copies which are unusable. Not sure why this is since they both start from a CR2 image. The Landscape / Portrait issue remains with the Pixilion copies, however.  Anyhow, I'll stack (DSS / Astroart) using CR2, rotate 90deg as appropriate, and continue processing until I get all this figured out.

Thanks to all for your help.

George

Link to comment
Share on other sites

Hey George,

Happy Birthday!!  (If you go in for that sort of thing...)

The CR2 files will Stack just fine in DSS (regardless of the apparent Auto-Rotate showing up when you view them).  DSS knows just like other Astro Imaging Software to simply stay with the "native" Landscape Orientation of the actual Sensor in the Camera.  And once DSS has Stacked them, and you save the result as a TIFF it will be Landscape too (DSS doesn't save any of the Orientation data).

I would be concerned to ask you what makes the BYE TIFF Images "Unusable".  Guylain's only purpose for producing them is so that they can be used in DSS or PixInsight or StarTools even when the CR2 File cannot.

Any details you can tell us would be appreciated...

 

Link to comment
Share on other sites

I tried some CR2 portrait style images in DSS and they processed fine and ended up landscape, as you suggested. Thanks. I didn't mean to sound critical of Guylain's fine work. Only that the TIFF copies didn't look right.  See below (M81).  I ran some TIFF portrait copies thru DSS and they seem to work OK other than being greyscale and still portait.  Since CR2 works I can  forget about trying to use TIFF.

Thanks again

sample TIFF copy.jpg

Link to comment
Share on other sites

George,

It is normal for both CR2 and the TIFF that was created from the CR2 to be very dark. The data is still linear and must be stretched. The JPG is not linear. It has been stretched in a non-linear way to reveal the faint details.

Can you provide a TIFF image that was created by BYE, and/or a CR2 image straight from the camera? The images may be too large to attach here or to email, but it would be possible to use a free cloud service like DropBox to store the files and then provide us a link to download them.

Thanks!

Link to comment
Share on other sites

I see M82 in that Image you posted.  With the usual tricks of Stretching and Saturation, you should get something more to your liking.  As Rick states:  This is Normal for TIFF and CR2 versions of Astro Images since they are "Linear Data".

It might be a bit confusing, but when you view an Image File, it is up to the Program doing the Displaying to determine whether and how much to "Process that Image File data" before presenting it to the User. 

  • For JPG files, which are always considered "Processed" data, the Display Program doesn't do much except to decide Orientation and Sizing. 
  • For RAW files such as CR2, which are always considered "RAW" data, the Display Program will either "cheat" by displaying the JPG Image that is usually embedded for just such cases, or will do it's own version of "Default Image Processing" (Stretching and Contrast and Saturation) before performing the Display function's Orientation and Sizing.
  • For TIFF files (which can contain either RAW or Processed data), the Display Program will usually treat it as "Processed" data and not do much but Orientation and Sizing.  (And when it is actually RAW data, that presentation is very Dim and Grey...)

So, most of what you describe is exactly as expected.

And:  YES, if you are able to Stack the CR2 Files in DSS, then you have no immediate need for the TIFF files.

If you can post a TIFF and a CR2 of the same Exposure, we can help confirm all of the above.  If you can post at least 2x of each, we can do some quick processing tests to ensure DSS is able to handle the files too.

Link to comment
Share on other sites

I upgraded my DSS to the 3.3.4 version (DSLR friendly) and all the problems disappeared. See the image (JPEG) taken last night before the clouds rolled in.

M81, M82 and NGC3077. A stack of twenty 20 second ISO 1600 CR2 images.  Thanks for all your help.  Although I have some experience with video AP this is my first effort in DSLR.  The wider field of view is impressive.

George

5aaa77977f3e0_20180314202508hypdslr20sec1600isoccdAA.jpg.a3cc7629b8c15d8493a63c7c40c5a243.jpg

 

Link to comment
Share on other sites

Nice Image Results!!

You might want to ease up a bit on the "Black Point", as sometimes the background space isn't really Black.  That is the case with the high altitude area within we find M81 M82.  Many Images will have captured strong amounts of the IFN - Interstellar Flux Nebula.

However, at only 20 sec exposures, it's hard to know if you captured any of the IFN.

Link to comment
Share on other sites

George,

I cannot help with the faint TIFF images. They are created from the raw image data and should appear like a deBayered FITS file that is created from the same raw data.

I am a bit confused. BYE does not rotate the images. It presents the CR2 and JPG images as they come from the camera. The TIFF is created from the CR2 and should have the same orientation. So are you saying that the TIFF and the CR2 images have reverse aspect ratios (landscape and portrait)? If so, the only sources for that are either 1) the DCRaw conversion function that BYE uses (perhaps it is honoring some metadata value during creation of the TIFF...this would likely be a bug) or 2) whatever program that you are using to display the TIFF image is honoring some autorotate metadata value.

I would tend to think that it may be the latter since when this issue was previously reported the cause was found to be a switch in the OP's image processing program that was causing the image to be automatically rotated. I may be remembering the post incorrectly, but I believe that the program may have been PixInsight.

Link to comment
Share on other sites

Realize that the Display Image shown for a RAW File is actually a small Embedded JPG - produced by default by the Camera even when you select RAW-Only Output.  The DSLR Designers give a set of Default Processing Values - Stretch and Contrast and Saturation - by which all JPGs are produced (including the Embedded version).  This is also one of the reasons why JPGs are of limited use for AP Image Stacking...

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