Jump to content
You must now use your email address to sign in [click for more info] ×

DeepDesertPhoto

Members
  • Posts

    174
  • Joined

  • Last visited

Posts posted by DeepDesertPhoto

  1. I just updated to the 1.9 version of Affinity Photo a couple of days ago and I noticed that when I created a panorama, which is what I specialize in, the pano resolution was 300 PPI, which is the same as the original individual images. In the past the default resolution for panos, stacks, HDR, and focus merge, was 96 PPI. 

    I am glad you finally corrected that little flaw because it was a hassle to have to manually change my panos from 96 to 300 PPI. Now that is a step I no longer have to do.

    Can I assume that the new resolution will apply to stacks, HDR, and focus merges as long as my original individual images are 300 PPI?

    Are there other features that were added to the program with this new update?

    Just wondering because I have not had the chance to check all the drop-down menus for any new features yet.

  2. 1 hour ago, Dan C said:

    Sorry to hear you're having trouble! This is something I've raised with the development team recently, as I too noticed this when using the Focus Merge function and have spoken with one of our Photo devs. Currently the app is hard coded to generate 96DPI files from these functions, however we're looking into reading the DPI and any common metadata from the source images and retaining this during the merge/panorama process. If multiple DPI's are detected, I suggested in the improvement log that we use the largest value available from the images.

    Would this satisfy your needs within Affinity? :)

    Yes, this was the kind of answer I was looking for.
    All I wanted to know was if AP was generating 96 PPI as some kind of default setting when creating Panoramas, HDR Merging, Stacks, and Focus Merge.
    Most of my work involves creating panoramas and focus merging multiple exposures with different shutter speeds.
    And yes, having it generate images using the PPI of the source images would suit me just fine.
    If your development team is working on it hopefully they will have an update for this later.

    On a side note, I have been recommending the AP program to friends and colleagues of mine who are getting tired of paying the monthly subscription fee for Adobe's Creative Cloud.
    That's why I got AP to begin with.

  3. 13 minutes ago, R C-R said:

    AP's macro feature is unfortunately far less powerful than the scripting support built into Photoshop.

    Well, since I don't normally do batch work I can just do the resolution changes manually.
    I originally got AP because my Photoshop quit working when I upgraded my Mac to High Sierra.
    Photoshop support techs told me that CS5 had not been tested on anything higher than El Capitan.
    And since I needed a good photo-editing program for my photography work I tried AP and found that most of its features were similar to Photoshop.
    The resolution issue I posted about is more of an inconvenience than a real problem.
    Maybe the AP developers will fix it in a later release.

  4. 20 minutes ago, R C-R said:

    I understand now.
    I was missing the terminology.
    Before I got AP I used to use Photoshop CS5 and it had a similar feature, but it was not called Macro.
    However, it did do the same thing and I did use it to make step by step presets.
    But I only used it if I needed to do batch work, which I rarely did.
    I will have to experiment with it and see if I can create my own macro.
    But if not I will just do it manually like before.

  5. 9 minutes ago, R C-R said:

    A .macro file contains a single macro & must be imported into AP's Macro panel when a document is open. From there it can be added to the Library panel. A .macros file (note the plural form) contains one or more macros & can be imported into the Library panel.

    Is a macro anything like a preset?
    I have created a number of presets for things like RAW adjustments, lens correction, and detail sharpening.
    But I have not seen anything in AP that says "Macro".
    Maybe it is the terminology I am missing here.
     

  6. 7 minutes ago, R C-R said:

    The "issue" with AP's macro recorder is it cannot record an export step (or a save step or anything else that requires user interaction other than the few macro steps that allow limited interaction via the "Edit" gear icon).

    But setting DPI via a macro is easy so it could be included in an AP batch job. Since anything developed in AP is initially in the native file format & would have to be exported to TIF, PNG, etc. anyway, a batch job might be a usable workaround, as @Old Bruce suggested.

    As I mentioned to @Fixx I can manually change the resolution. All I have to do is go to the document menu, then go to Resize Document in the menu. When the resolution window opens I simply uncheck the resample box and then change the 96 to 300. Then I just click save and that changes it from 96 to 300 PPI.
    But if AP simply made the panoramas with the same PPI that the original source images were I would not have to do these extra steps.

  7. 27 minutes ago, Fixx said:

    I think at the moment there is no other way than change manually each image to 300 dpi. If you use macro, OP's worfklow says macro is applied "manually" to each photo.

    Possibly there could be an export macro which does several operations like set dpi, apply unsharp mask, save to a specific folder. But I think export with macro had some issues...

    I can manually change the resolution. All I have to do is go to the document menu, then go to Resize Document in the menu. When the resolution window opens I simply uncheck the resample box and then change the 96 to 300. Then I just click save and that changes it from 96 to 300 PPI.
    But if AP simply made the panoramas with the same PPI that the original source images were I would not have to do these extra steps.

  8. 1 hour ago, Old Bruce said:

     

    The Nikon is 300 dpi after processing in Photo and my Canon CR2 files are 72 dpi after processing. The dpi values are from Photo not "XnViewMP". I wind up with a couple of pictures that are 13"x20" (Nikon) and 48" x 72" (Canon).

    To 300 dpi.afmacro 652 B · 0 downloads

    This works.

    I've never used one of these macros.
    I tried to open it and I got an error saying that there is no program on my Mac that can open this file.
    I tried to open it with AP but it would not recognize the file.

    I can just manually change the resolution for the finished version before exporting it as TIFs and JPGs.

  9. 54 minutes ago, thomaso said:

    Usually the pixel dimensions are relevant and define the available maximum size. Do you get in Affinity a result below 6016 x 4014 px? (regardless of PPI or DPI)

    If not, can you tell us what specific art site rejects your resulted images?

    I have accounts with many stock photo agencies and two Print on Demand websites. All of them have image requirements of 150 to 300 PPI.
    Here is a blog from Society6, one of the POD sites I sell my work through.
    In their blog they state that they require that the images be set to 300 DPI in order to produce the best prints.
    The other sites I sell through have similar requirements.

    https://blog.society6.com/prepare-art-files-printing-society6-products/

  10. 17 minutes ago, Aad Slingerland said:

    I'll send you one... Nikon D750 RAW. And yes Nikon RAW images (.NEF extension) always show up in 300 DPI when developped.

     

    dsc_2505.nef 27.12 MB · 0 downloads

    I downloaded your image just to see its specifications.
    It appears to be the same as my D810 except for the megapixels.
    Yours is 24MP while mine is 36MP.
    Yours also developed with a 300PPI resolution. Same as mine.
    Like I mentioned, the problem I have is that when I merge 2 or more photos together as a panorama, a stack, or a focus merge, the finished image ends up with only 96 PPI.
    As an experiment I converted the RAWs into TIFs and created a panorama from those and it still ended up with 96 PPI even though the source TIFs were 300 PPI.
    So this might be some kind of AP resolution default for images created by merging 2 or more together.

  11. 20 minutes ago, R C-R said:

    Unfortunately, I do not have a Nikon or any other camera that creates RAW files, so I have to make do with RAW files I have downloaded from the web. That may create some bias in my tests but what I can tell using those files & the EXIF Tool data that XnViewMP displays, there are 3 EXIF metadata values that can be extracted from (most?) RAW format files to derive a default value.

    As labeled in the XnViewMP display (which may be converted from binary data in some way?) they are X Resolution, Y Resolution, & Resolution Unit. The first 2 are integer numbers that are the same, & the third is a linear unit of measurement, usually but not always "inches."

    In most of the downloaded samples, regardless of make or model of the camera or RAW format the two resolutions are 300 & the unit is inches, but for a few of them the resolutions are 72. Developing each of them in AP results in values of 300 or 72 respectively. I have not yet found one with different X & Y resolutions but I assume that if I did those values would be used during development.

    So from that quite possibly flawed logic, I think for these multi-file processes everything defaults to 96 simply so that they all start with the same consistent value, if that makes any sense.

    I usually don't delve into the metadata that deeply. Most of the time the only metadata that matters to me is the color space, date of creation, and the camera settings such as ISO, aperture, and shutter.
    But like I said, next time I go out to do some landscape photography I will set the shutter manually instead of leaving it on auto and see if that has an effect on the panorama resolution when processed by AP.
    If the resulting PPI is still 96 then that probably means it is an AP default and I will just have to remember to manually reset it before I upload the image to a website that requires 300 PPI.

  12. 6 minutes ago, R C-R said:

    First, I have to apologize for missing the part about the artwork being rejected. I now understand why the default is a problem for you.

    However, it is still untrue that the source images themselves from the camera are set to any specific PPI (that would be in the metadata if it is included in the file), which may be why they default to the 96 value in AP. Also, at least for panoramas & I think for focus merges as well not all of the source files must have the same values in the metadata, so that also may be part of it.

    Not that it is of any help for you or you can do anything about it, but any site that looks only at the metadata & not the pixel count to determine resolution is either too lazy or too clueless to do that correctly.

    I guess the only thing you can do is post something to the feature request forum (where I think this already has a few comments) & hope for the best.

    I'm using a Nikon D810.
    When I check the image quality settings it simple says RAW and the image area covered is set to its max (36 MP), but it does not say a specific PPI.
    Yet when I open individual RAW images with AP they always open at 300 PPI. Perhaps that is the default of the Nikon PPI setting because the camera does not allow me to change the PPI.
    Since individual RAW files always open with AP at 300 PPI perhaps it is because of varying metadata when I am doing sequential shots for panoramas.
    When I do sequential pano shots I use Aperture Priority in which the Aperture is set to a specific F-stop but the shutter speed is left on auto.
    As a result the shutter speed does vary a little from shot to shot.
    Next time I will set the shutter manually so that all shots are one shutter speed and see if that has an effect on the panorama PPI created by AP.
     

  13. 14 minutes ago, R C-R said:

    The point is pixels (or dots) per inch (or any other physical measure of length) is relevant only for physical output, like for a printout. The camera does not output anything at 300 or any other PPI or DPI, just files that may include in the metadata nominal values that RAW converters may or may not use during development.

    Likewise, when sending a file to a printer, those values may or may not be used to size the print (because prints can be scaled in various ways).

    So basically, PPI/DPI doesn't matter unless/until physical output is created & resolution is defined by the number of pixels in the file.

    I know it does not matter as far as display on the screen.
    The problem is that the stock photography agencies and Print On Demand Art sites I send my images to for sale require 300 PPI.
    This means that I have to manually change the 96 PPI to 300 before I can upload the image to these websites.

    My question is why does AP produce a 96 PPI image when the original source images for the panorama or focus merge are already set at 300 PPI.
    Why does AP not simply create the final merged image at the same PPI setting of the original source images?
    It's a simple question about the way the program operates for certain tasks.

  14. 5 hours ago, R C-R said:

    I already know about this. I know that PPI is for pixels per inch and DPI is dots per inch for printing.
    My question was why does AP always make my panoramas or focus merges 96 PPI?
    The camera raw images are set to 300 PPI out of the camera.
    When I open individual raw photos with AP they are always what they were out of the camera at 300 PPI.
    Why would AP change it to 96 PPI when merging multiple images together?

  15. I don't know if this has been covered before here but I have a question about image resolution when creating panoramas, stacks, HDR merging, and Focus merging.
    Whenever I create a panorama, stack, HDR merge, or do a focus merge, the image resolution of the final image is always 96 PPI.
    Why does it always produce an image with such low PPI when the original images used were 300 PPI?

    I have gone through the preferences and cannot find a setting for the resolution when it comes to panorama, stack, HDR merge, and focus merge.
    Is there a way to make the final image from these tasks come out with the same resolution as the original images that were used for the tasks?

    Right now I have to manually change the resolution after the task is completed, which is annoying because sometimes I forget to do it and only remember after I try to upload the image to an art site and it gets rejected for low resolution.

  16. 1 hour ago, Daniel Tudosiu said:

    Hi,

    I have a similar problem where when I export I lose some fine shades from black to gray in my images, and I do not know if I do something wrong at exporting or is the limitation of the file format (JPEG/PNG/TIFF). I have attached my Affinity Photo (ver 1.8) project and the JPEG I exported. The area in question is on the two lamps above the drinks.
    Would really appreciate any help you can spare ❤️ 

    Stay safe!

    Edit: I have exported the image in JPEG format and embedded my display's ICC profile and it looks fine, but I do not think I should do it, if I remember correctly I should embed sRGB standard ICC profile right? I have also attached the custom ICC JPEG as well.

    DSCF2205.jpg

    DSCF2205_custom_ICC.jpg

    DSCF2205.afphoto 311.93 MB · 0 downloads

    If you're converting from 32 bit RGB to 8 bit RGB JPG, like the way I was, it is a limitation of the file format you're converting to, especially if it looks normal in 32 bit color.
    Like I mentioned in my posting I only encounter this problem when photographing cloudy sky with a lot of bluish grays, and I have also encountered this problem with blue skies that have gradually changing shades from light to dark.
    I was only able to solve the problem by lightening up the darker areas before converting it to a JPG.

    However, I always save a master copy in 32 bit color just in case AP releases a newer version in the future that might have better compression when converting.
     

  17. 3 hours ago, John Rostron said:

    The problem arises when you have large areas of a single hue with various shsdes. In your case, you have many shades of grey in your clouds. Grey is represented by all three channels  being the same, so, in 8-bit, you have a maximum of 256 shades of grey. The conversion from 32 or16bit grey to 8-bit does not always produce sufficiently smooth gradations, leading to banding.

    Did you convert directly from 32-bit to 8-bit? Or 32-bit to 16-bit to 8-bit? The latter may give a smoother result than the former.

    John

    When I work on these type of images I first shoot the scene in Camera RAW, in my case it is a Nikon D810 set to NEF raw.
    I then open the NEFs with AP and do the development. I have AP set to open the NEFs in 32 bit RGB HDR, which preserves 100% of the original NEF quality while I do the development.

    When all the development is done I then save the file as an AP document preserving the 32 bit RGB quality. I then use that as the master copy which I use to produce a 16 bit LAB TIF file for printing and an 8 bit RGB JPEG which is for uploading to the stock agencies I sell my work through.

    I forgot about the 256 shades of gray limitation for JPG images.
    But I can see the banding to a smaller extent in the 16 bit LAB TIF file, which has not occurred before.

  18. I was working an HDR image that looks perfectly fine in 32 bit HDR but when I convert it to 16 bit LAB or 8 bit RGB I am getting a banding problem.
    My banding problem is occurring in a storm photo I took in which I combined 3 exposures in 32 bit HDR.

    The banding appears in the smoother areas of the dark clouds in the photo.

    Like I said this banding is not visible with the original AP document that is in 32 bit HDR.

    The banding is only noticeable when converted to a 16 bit LAB color TIF file or an 8 bit RGB JPEG.
    I did not have this problem with the last version of AP so I am wondering if it is a problem with the way the newer version of AP is converting the image to the other formats I use.

    I am including the JPG version that has the banding.

    The only way I have been able to fix this is by lightening the tones of the clouds where the banding occurs, but that ruins the HDR toning, so I hope there is a fix because I do a lot of HDR photography.

    I am using the latest version of AP (1.8.4)

    FSR492-StormOverMatterhornMesaAZ-36MP.jpg

  19. Just now, Joachim_L said:

    Of course I can right-click-open-with. I assume that Serif just forgot to put in the filter list.

    That is probably more plausible since I have not used Windows since 1995.

    Patrick Conner told me to post about this because he said that AP may need some tweaking since the JPF support is a recent update for the program.
    Until Serif fixes the color shifting and scrambled LAB color I will still have to use GIMP and Apple Preview App to convert my JPFs to TIF before using AP to edit them.

  20. 2 hours ago, walt.farrell said:

    You're not alone.

    You can also filter them manually, by putting *.jpf in the filename field and pressing enter, though. But if Affinity Photo has added JPF support it ought to show up as part of the JPEG2000 filtering, I think.

    As I mentioned in reply to another commenter I am able to open JPF with AP by right clicking on the JPF file directly and in the Mac Finder dropdown menu it does give AP as a program capable of opening it.
    But AP does not show JPF in its own "Open" dropdown menu.
    Since JPF support was just added for this version of AP maybe that is why Patrick Conner told me the software does need some tweaking.

×
×
  • Create New...

Important Information

Terms of Use | 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.