Jump to content

Search the Community

Showing results for tags '16-bit'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Affinity Support
    • News and Information
    • Affinity Support & Questions
    • Feature Requests, Suggestions & Discussions
  • Learn and Share
    • Tutorials (Serif and Customer Created Tutorials)
    • Share your work
    • Resources
  • Bug Reporting
    • Report a Bug in Affinity Designer
    • Report a Bug in Affinity Photo
    • Report a Bug in Affinity Publisher
    • (Pre 1.7) Affinity Range Bugs Forums
  • Beta Software Forums
    • Affinity Designer Beta Forums
    • Affinity Photo Beta Forums
    • Affinity Publisher Beta Forums

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 5 results

  1. Hi folks, anyone noticed the colour change when converting down from 32-bit to 16-bit? Searched the forum for a while and it doesn't come up. I'm working with 32-bit EXR render and at some point you need to convert down to a lower bit depth and when you do any editing on the scene, it changes the colour. Do the same in Photoshop and it stays correct. You can try it with anything: Exposure or Curve to make it visible. Set up the exact same settings in both AP and PS and convert down to 16 bit and then compare both images. Or even just do it in AP. Have your layer stack in full 32 and change the format down to 16 and then switch back and forth to see the difference. I think this is a huge drawback. Whatever is handling the conversion in the background, somethings off. Cheers, Bo
  2. Hi, so, I am reporting a rather obscure error. It may be difficult to reproduce unless duplicating fairly exact conditions, so I will be specific. System / Software Operating System: Windows 10 Pro 64-Bit 1709 Build 16299.371 Hardware: Gigabyte 15X - i7-7700HQ / 16GB Ram / 1.5TB NVMe SSD / Nvidia GeForce GTX 1070 Max-Q GPU Affinity Photo: v 1.6.4.104 Capture One Pro: v 11.1.0.140 Issue Description Using Capture One (C1) 'Edit with' to edit an existing NEF raw file, a 16-Bit uncompressed TIF file is generated and saved in C1 and then sent to Affinity Photo (AP). Once this file is updated and saved within AP, the TIF file is successfully returned to C1. However, on trying to edit the filename in C1 immediately afterwards, C1 says that the file is locked by another process. This happens on all successive similar edits of NEF files. If one exits C1, and goes back to those files, they are no longer locked and can be renamed. To Duplicate 1. In C1, select a file such as a raw NEF file named IMG-1234567.NEF.2. In C1, right click the image thumbnail, and use 'Edit with' to edit in an external app, selecting Affinity Photo.3. In C1, this creates a TIF file in the same directory, in this case naming the file IMG-1234567.TIF.4. In AP, this TIF file is opened up. The image is simply adjusted (such as brightness or curves) and the image is flattened.5. In AP, use 'Save' in the File menu (or Ctrl-S) and then Exit (you can alternatively just exit AP using the close window button and confirm saving changes to the file on exit).6. In C1, after being returned from AP, the image thumbnail looks okay, updated and all looks fine. 7. In C1, however, it is not possible to RENAME the file, as C1 says the 'item is being used by another process'. Essentially the file is locked from file-based operations, unable to be renamed or deleted. Investigation 1. This occurs when a raw file is converted to a 16-bit TIF files that are uncompressed, using any ICC profile, 300 px/in. fixed 100% scaling, before being sent to AP. This problem does not occur when converting to and sending 8-bit TIF files, jpegs, PSD files or any other from C1 to AP. 2. It only seems to occur when raw files are converted to 16-bit TIF prior to sending. Editing an original jpeg or TIF file, where a 16-bit TIF is made and sent to AP does not produce any issue. 3. I have tried out this problem on a similar hardware system, with the same operating system (Windows 10) freshly installed, and the same issue occurs. However, on a Windows 7 system, this issue does not occur. 4. Using SysInternals diagnostic software, I have ascertained that when the TIF file is returned from AP to C1, the process that has locked the image file is in fact C1 itself, as though it has stalled on some operation on the file once returned from AP, thus locking the file until the software is restarted. 5. Sometimes, when I have tried this, 10% of the time there is no issue, but I cannot determine the reason for this variation. 6. Using 'Edit with' in C1 to call other editing software, such as Photoshop or OneOne PhotoRaw, using a 16-bit TIF is not an issue. Using software, such as Lightroom, to call AP is also not a problem. It is specifically when pairing C1 with AP, using a 16-bit TIF as the round-trip file format. 7. I have had one other user say that they were unable to duplicate the issue, although I cannot be sure that the exact operating system, software and GPU setup were the same. While I do not expect much of an outcome on this issue, I place it here for reference should the issue ever hit another user with similar hardware, operating system and software versions. In many cases, when people try to duplicate such an issue, one of the common reasons that the issue is not duplicated is due to some variable, environmental condition or procedural steps not being mirrored. However, should anyone with this setup like to report back their own findings, I would certainly welcome the information. Thank you, Cass.
  3. Summary: The image is 4988 x 2814px, 14.04 MB, 7 layers: 1 background pixel layer, 5 masked curve adjustment layers, 1 B&W layer in RGBA/32 (HDR), ProPhoto RGB (Linear). Using Document, Color Format to convert this image in 32-bits to 16-bits RGBA/16 - ProPhotoRGB takes over 8 minutes of processing time on a relatively well-spec'ed machine. Adobe Photoshop CS6 using the same image in 32-bits, similar number of layers and same color space to 16-bits in same color space takes about 5 seconds. Affinity Photo takes an inordinately long time that is not acceptable for the workflow. Details: The machine: Windows 7 Professional 64-bit up-to-date per Windows Update Service Pack 1 Processor: Intel Core i7-3770 CPU @ 3.40GHz 32.0 GB RAM Windows Experience Index 7.7 (on a scale of 1.0 to 7.9) Graphics card: GeForce GTX 970 version 385.69 NVIDIA Control Panel reports (see attached PNG) More details on machine in attached PNG. Disk C: is a SSD and has both Affinity Photo and Adobe Photoshop CS6. The software: Affinity Photo 1.6.1.93 RAM Usage limit 25,599 MB Renderer: Default (NVIDIA GeForce GTX 970) Adobe Photoshop CS6 64-bit, using the NVIDIA GeForce GTX 970) Using Photo Affinity's Document, Color Format, RGB 16 bit it takes slightly over 8 minutes to have hourglass disappear and the RGBA/16 - ProPhotoRGB to appear. During this time Windows Task Manager reports (see attached PNG's). CPU utilization by Affinity Photo is essentially 100% during this time. Trying 32-bit to 16-bit conversion on the same image in the beta version 1.6.1.93 (Beta) does not result in Task Manager reporting "Affinity Photo (not responding)" but if anything the conversion takes even longer at about 8 minutes 55 seconds. Doing this 32-bit to 16-bit conversion of same image and same color spaces in Photoshop CS6 takes about 5 seconds of processing time. Machine Info 1.pdf
  4. I've done some controlled experiments and had another person verify this is repeatable. Steps to produce the problem: Take photo with iPhone running iOS 11 (tested with iPhone 7 and iPhone X). Photo will be in HEIF/HEIC format Export image from Apple Photos on the Mac as an 8-bit TIFF Open 8-bit TIFF in Affinity Photo 1.5 or 1.6 (tested both) - image looks fine Export the same image form Apple Photos as a 16-bit TIFF Open 16-bit TIFF in Affinity Photo 1.5 or 1.6 and the right 10% of the image will be sort of a grey, metal-looking digital mess The same 16-bit TIFF looks fine in quick look and in Macphun's Aurora HDR 2018 Rather than clog up the system with giant files here's the 8 and 16-bit versions of the same photo in Dropbox so you can see for yourself: 8-bit: https://www.dropbox.com/s/nityjdgibkfc9td/boogs 8-bit.tiff?dl=0 16-bit with mess on the right: https://www.dropbox.com/s/0t2kv4x2o7t0ft5/boogs16-bit.tiff?dl=0
  5. FYI, this question has to do with AP: Looking at a recent image, I noticed some faint banding that was visible when I applied a color gradient (maybe it was there in the B&W version, but I couldn't see it). See the darker of these two images: https://forum.affinity.serif.com/index.php?/topic/20687-photos-from-a-mountaintop/(FWIW, I see the banding on my non-retina, late 2013 iMac; I haven't checked on other machines). Searching the forums I came across a comment about the "Dither Gradients" preference and the different effects if you are working in 8-bit or 16-bit (see MEB's comments in this thread: https://forum.affinity.serif.com/index.php?/topic/13742-unwanted-noise-in-gradients). So, my question: If I'm working in 16-bit, is it better to leave "Dither Gradients" preference checked? Or unchecked? Thanks, Darin
×