Jump to content

Gary.JONES

Members
  • Posts

    112
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. But - there is one thing that needs to be fixed ... In the scanner info panel, it lists scanners by the name of the driver software - rathe3r than the PRINTER name. For networks like mine, I have a zillion Epson WF7620 printers, but when using AP there's no way to tell which is which. AP needs to interrogate the printer to display its NAME - rather than the name of the driver.
  2. Well - I think I need to order a huge helping of humble pie ... I just launched AP, and the scanner popped up before I even knew what happened. Apparently, I was too impatient when AP displayed 'Waiting for scanner' for first time ... Now it works perfectly ... ¯\_(ツ)_/¯
  3. Hi Paul, By 'System Preferences', do you mean you can't add the scanner as a peripheral ? That is a bit strange if it still works using ImageCapture. Im using Mac OS 10.14 - my scanner works fine with everything except AP - something is definitely broken there as the UI doesnt do what it says in the manual. Also - no response from Affinity on this as yet.
  4. Hi, I'm trying to acquire images from several Epson scanners. This feature does not seem to work. In short - there is no dialog and no 'Scan' or 'Show Details' buttons as described in the User guide. All my scanners works fine with PS and Image Capture, so I know the hardware and connectivity is OK. When I select 'Acquire Image ...' from the AP file menu, a window opens and my scanners are all listed. If I click on the generic icon for any scanner, AP briefly displays 'Waiting for scanner ...', then the generic scanner icon changes to an Epson icon - which confirms that AP is communicating with the scanner. AP also displays an 'eject' icon next to the printer - what is this for ??? At the bottom of the page, there is a drop-down menu that displays 'Detect Separate Items', 'Select Enclosing Box', A4, 'US Letter' and 'US Legal'. Selecting any of these items does nothing - and the selection is not displayed after releasing the mouse button. And the document on the scanner is not displayed. Is this a bug ? Gary
  5. Because I'm hoping 1.10.4 beta will fix some of the issues that carried over from 10.1.2 to 10.1.3.
  6. Hi, II've been running the v1.10.2 beta - today it is asking for a Product Key. I purchased AP via the App Store - so I dont actually have a product key. On your support page, it says to log onto my account and go to the 'Downloads and product keys' page to get the keys, but there are no keys available there - only downloads of old trial versions. How can I reactivate the beta ? BTW - I know that v1.10.3 has been released and I have installed that 0- but presumably you are ruining new betas as well ? Gary
  7. Hi James, Would appreciate if you can follow up on this issue with AP image normalisation ?
  8. Hi James, Many thanks - that (mostly) makes sense - I think. But it doesn't help me understand why FITS open in AP with a horrible muddy appearance, when they open in other apps with a nice, crisp neutral colour balance, as in the examples above. I know this can be manually fixed, but it means additional processing steps, and Im not sure AP is giving the same image quality as Im getting with other stackers/editors. Also - just hilighting my comment above ... Also, if there is no WB profile in the FITS file, then AP should not offer 'Camera' as an option. Ditto if there is no 'Master Flat'. And finally, re the UI oversight - hopefully this will be fixed in the next beta Gary
  9. Also, here are the results from stacking the same 75 FITS images in AP vs ASI DeepStack, using the default settings for each app, along with the histogram for each image :- Affinity Photo ASI DeepStack The histogram for FItsViewer is much more helpful because it has a scale, and its easier to change the x-axis scaling. AP really needs a log scale for the histogram and also for the adjustment tools.
  10. Also, here is another comparison of a FITS image normalised by Affinity Photo vs ZWO ASIFITSView vs Graphic Converter ... Affinity Photo ZWO ASIStudio / FITS Viewer Graphic Converter Each of these images in obtained by opening the same FITS file :- Affinity Photo : Uses the default Levels and Curves settings as determined by AP ASI FitsView : Uses ZWO's default normalisation method Graphic Converter : uses the Effect/Mathematical/Normalise function. Clearly, Graphic Converter gives the best result, with a neutral colour bias and low noise. I want to see a result like the GC image when AP opens a FITS file
  11. I could be wrong, but I think James is referring to what in Affinity is named "RGB/32 (HDR)." That format stores each of the color values as an unbounded 32 bit floating point number. See for example the "What is an HDR image?" section of https://www.hdrsoft.com/resources/dri.html for more about that. Also, there is the help topic https://affinity.help/photo/en-US.lproj/pages/HDR/hdr_editing.html to refer to. Thanks R C-R, Yes, I suspect you are right - but that applies only if HDR is enabled. The idea here is that unbounded ICC profile conversions eliminate interim clipping, freeing the result from color space encoding limitations. When using linear gamma profiles at 32-bit floating point precision, there is no gamut clipping even when the image color gamut exceeds the color gamut of the destination color space. For example, if you converted an image from say, an sRGB camera profile to LAB, then to XYZ then to sRGB for output, in bounded mode, clipping would happen at every step along the way whenever the resulting RGB, LAB, or XYZ values exceed any of these intermediate color spaces' respective encoding ranges. In unbounded mode this "intermediate color space clipping" doesn't happen. Unbounded mode can take two forms :- In the 'vanilla' case, values less than zero and greater than one are carried from one ICC profile conversion to the next and clipping is postponed until the point at which the RGB image is output in a file format that doesn't support negative values or values greater than 1 (eg jpegs, pngs, and 8-bit and 16-bit integer tiffs). However, if the following three conditions are met, then the RGB values aren't clipped at all: • The ICC profile conversions are done at 32-bit floating point precision. • The ICC profiles that are used have true linear gamma curve TRCs (Tone Reproduction Curves). • The RGB image is output in a format that does support floating point RGB channel values that are 0.0 and greater than 1.0 (eg PFM, OpenEXR, and floating point tiffs). But - I dont think any of this applies to the issues I've described above, because they are not specific to HDR mode - which I havent used - unless I'm missing something /:oGary
  12. Hi, Today I accidentally selected a folder containing hundreds of FITS files when creating an Astrophotography stack. I knew it was going to take ages to process the files, so I decided to abort the stacking process, but there was no way to do that. Clicking the close button on the stacking window just gave be a 'beep'. So - I had to force-quit AP - which meant I lost the previous image Id been working on. So - IMHO there needs to be a 'Cancel' button on the astrostacking process window. Gary
  13. Hey James, Many thanks for your detailed reply ... I'll respond to each one here ... FIT files and documents created via the Astrophotography Stack Persona are in RGB/32, which is a linear colour space operating with unbounded float pixel values. It's a UI issue, but there's no colour space model on the Curves, Levels and Channel Mixer dialogs for this format, which is why they appear blank. If you purposefully switch to one of the provided colour models, this will reset the adjustment parameters and will also operate in a bounded format, which you will want to avoid. Just leave the adjustments as-is. RGB/32 (aka RGBA) is a 32 bit colour format where every pixel has three 8-bit RGB values + an additional byte for the alpha (transparency) value. The Curves and Levels tools (and others) in AP facilitate adjustments to R, G, B and A, so they must be RGBA - so I dont understand what is meant by saying there is no colour model for this - or why AP doesnt assign the RGBA colour model to new (RGBA) images ?? They are not the same for every image: the gamma value will likely be some median based on an arbitrary scale to perform the non-linear stretching. On a monochrome stack of blue data, I've had a value of 0.582—another stack where I've added LRGB data simultaneously has resulted in 0.651. The initial Levels and Curves adjustments are just a convenient initial tone stretch, you don't have to use them if you prefer to perform your own tone stretching, perhaps using a different method (e.g. colour preserving tone stretch). OK - I should have tested on a wider variety of images - they are identical for FITS in the same imaging session - as I suppose you'd expect. IMHO the initial stretches are not right - they should be more neutral than they actually are. Because you are switching colour model—e.g. the most common use case is for manipulating tones using LAB/CMYK whilst still in an RGB document and vice versa. There is no feasible way to translate parameter values from one model to another, so they are reset instead. As mentioned above though, there is no need to do this for your workflow. I still dont understand this - ref #1 Could be a number of factors. Photo will debayer using an inferred pattern from the FIT metadata (the file you provided is RGGB). There is no colour profile information in the metadata according to ExifTool, so Photo will then have to assign your working space, which presumably you have changed to Adobe RGB in Preferences>Colour? Regardless of the FIT file's bit depth (yours appears to be 16-bit), it will translate the values to unbounded floats in 32-bit linear. The values in the FIT file should already be linear anyway. In terms of white balance, there is nothing mandated in the FIT data. When performing the colour space conversion and white point mapping, Photo will likely be using a D65 white point. I'll check this. The initial colour cast that is revealed when tone stretching is fortunately straightforward to neutralise or remove, however. Yes, AP uses the inferred pattern - there is no way to set RGGB (or any mode) as the default. And yes, the original FITS contains no colour profile, Adobe RGB (1988) is set as the default in AP. And yes, the original FITS are 16-bit. I presume that the RAW option in the Stack persona of 'White Balance = Daylight' is D6500 - but would be good to confirm. I also presume that 'White Balance = Camera' would not change anything if the FITS file doesnt include a WB profile. In any case, 'Daylight' really has no meaning for an astroimage. Also, if there is no WB profile in the FITS file, then AP should not offer 'Camera' as an option. Ditto if there is no 'Master Flat'. Hmmmm - how did you open that FIT in GC ? Did you stretch it ?? If you open the FIT and then select Effect/Mathematical/Normalise, you should get an image like the ones I posted above - with a neutral grey. Apologies - the FITS does not have an RGB profile - I was reading the EXIF data in GC and forgot that GC assigned Adobe RGB (1988) when opening unprofiled images. Noted—however, it's hardly unusable as-is. I've been using it since it was introduced in the 1.9 beta builds and have thrown all manner of data at it. We've just worked through any roadblocks as they've come up. There are a variety of methods for neutralising colour biases, balancing monochrome data and removing background colour casts, have you tried watching any of the video tutorials on the official Photo YouTube channel or website? Yes, Ive been doing this for a long time too - and really like the power of AP (I also vow never to buy another Adobe product because I refuse to pay recurring fees). The FITS do have a red bias on images where a UHC filter is used, BUT - the red bias is not what I expect if the app does a default normalisation - I expect to see a neutral colour bias like the one generated by GC - also the detail seems a lot sharper in the GC images. I use the 'Remove Background' filter and wind the grey down to zero, but that doesn't work nearly as well as normalising the image in GC. And yes, Ive watched all the AP tutorials - they are very good. So - overall - what Id like to see is a simpler / better implementation of a default normalisation in AP Gary
  14. Would be good to get a response on this ... To be effective building Astronomy stacks, AP needs to be able to assign levels and curves properly, and to normalise the images correctly. Can someone please follow up on this ? Gary
  15. Hi Stokerg, Many thanks for your post - a few comments below. Cheers, Gary ===== 1. Why is there no default colour mode assigned to these adjustment layers when creating a new stack ? These adjustments will work to the colour mode of the document, which should be RGB. By default when you call the adjustments up, they are set to Master, which means all channels. Nope. The document might be set to RGB, but the >>ADJUSTMENT<< layers are not ... they are set to 'nothing'. Please take a look at the image I attached above - mode ='', channel = 'master'. The adjustment layer should be set to the same as the document= RGB in this case - but it is not. Have you tested this ? ===== 2. How are the default values chosen for these adjustment layers ? These are generated from the images supplied for the Astrophotography stack. So should be different with each set of images. Nope. They are exactly the same for every image. When you select a colour mode in the adjustment layer, they are all reset - this should not happen. Have you tested this ? ===== 3. Why are the default values reset if you select a colour mode ? They shouldn't reset, but if you switch from Master to Red, you should then only see the Red channel. Going back to Master, should show you all of them. Nope. Please read my notes above - we need something more than saying they 'shouldn't' reset, when they actually do. Have you tested this ? ===== 4. Why do FITS open with a terrible muddy red/green cast on AP, when they appear as a much crisper neutral grey in other image editors ?(FYI - The debayer setting is correct, and the colour space used in AP is the same as the source image).See the example images below. I suspect this will be due to Affinity reading the actual FITS information. Which other image viewer were you using? Can you provide the FITS files used in your stack here on the Forums? Hmmm ... I actually suspect it's because AP is NOT reading the image metadata (FYI - the image profile is not in the FITS metadata. info. My images already include an Adobe RGB (1988) profile - but AP opens the doc with a message saying 'AP has assigned your working profile (Adobe RGB (1988) to this UNprofiled document.' >> This tells me that AP is not reading the profile information correctly. In any case, as AP seems to be trying to assign the same profile that is already assigned to the image, so it should still display the colours correctly. In any case, a mismatched profile would not account for the massive colour bias seen in my images - if I assign any of the other available profiles, the change in colour is very minimal. Have you tested this ? I'm using Graphic Converter as a comparison :- Graphic Converter Affinity Photo FITS files are 32.5MB - I've put one on Dropbox for you here. ===== iMac 27" Retina - OS 10.14.6 AP 1.10.2.260 =====
×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.