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

ultrainfra

Members
  • Posts

    34
  • Joined

  • Last visited

Posts posted by ultrainfra

  1. 10 hours ago, Twolane said:

    Huh?

    Fixes & Improvements:

    • New Document: Custom Document Preset order is not retained between app sessions
    • Placed documents with bleed fail to render the top and left side correctly
    • Lens Correction in Develop Persona has no effect on non-Raw files when a Lens Profile is applied
    • Quotes can be incorrectly put on newlines and cause text to render differently compared to V1
    • Can't place image when recording a macro in Photo V2
    • V2 opens raw files slower than V1
    • Running a V1 Macro that uses 'Add Image' (Place) crashes app - also applies to Batch Processing
    • Importing .JPG and .TIFF files with Keywords only displays the last keyword in the Metadata panel
    • Straightening in the Develop Persona offsets the image from the canvas entirely, until developed or crashes
    • Exclusion blend mode causing unexpected results on 16bit file layers with blown highlights
    • Transform Panel- Differences in panel size when switching between Curve strokes and expanded objects
    • Tone Mapping Preset options missing.
    • Blemish Tool failing after developing image.
    • Develop Persona 'Sync Before' no longer functions
    • Lens Correction Mis-Centered for Port

    If I recall when the last update went out it doesn't display that information in the program itself. At least, it didn't for me. Unless it did and I forgot. My apologies

  2. I got a new laptop today, an MSI Creator laptop with Intel Core i7-12700H  @ 2.70 GHz CPU,  16 GB of DDR4 3.2 GHz RAM, and Nvidia GeForce 3050 Ti dedicated graphics card. The operating system is Windows 11. All updates have been caught up and the computer restarted after updates. 

    After installing Affinity Photo 2 on this computer it seems that it likes to crash when doing various random things. Some examples of things that have made it crash: 

    • Zooming in on a photo
    • Opening a menu (for example the Filters drop-down menu)
    • Activating or deactivating one of the tools in raw develop (for example the exposure panel under the basic menu in raw develop)

     

  3. I think at best V2 should have been a free update to V1. The introduced features are mostly things that should have been there to begin with. 

    I'm disappointed that input ICC profiles are STILL unsupported in the raw developer. It's a basic feature of pretty much every third party raw development program I know of, and if a raw developer doesn't support ICC it will usually support DCP (DNG Color profiles, ie, as used in Lightroom, Luminar). I also really would have liked to see an easy method of straightening a photo by using a measure tool. GIMP has such a feature. You can use the measure tool to form a line segment on an edge, and have it adjust the image so that it becomes even. 

    I too have found it to easily crash. Have not noticed a pattern yet as to what triggers it. Sometimes it's something as simple as zooming in or out. Sometimes it's calling a plugin. Sometimes it's moving a slider on one of the filters. 

    So, so far it's basically the same as Affinity Photo V1 with a couple new features that should have been part of a free update given how relatively minor they are, a less appealing set of buttons (though this is just my aesthetic opinion), and lacking things that should be there. Not sure if to get a refund or just keep the new version in case it is improved. However considering exporting LUTs with HSV adjustments (by checking the HSV box on the HSL filter) was never fixed, my hopes aren't incredibly high. I say all this in the spirit of providing feedback to improve the product. Obviously if I bought V2 there are more things that I like than dislike and always like to support eating into Adobe's profits.

     

  4. I developed a raw file using affinity, with the output profile in the raw developer being set to a linear profile with 32 bit output enabled in the develop manager options. 

    Upon exporting the 32 bit tiff for opening in another program (tried opening in Gimp, Darktable), the file is blank. I tried disabling the compression in the tiff export to see if that helped. It didn't make a difference. 

    I'm running Affinity Photo version 1.10.5.1342 on Windows 10. Does anyone know what the issue could be and how to fix it? 

    I apologize if this is a duplicate topic. The search function on the forums seems to be having some kind of issue at the time of writing.

  5. On 3/23/2022 at 12:24 PM, Dan C said:

    I had noticed this recently when re-watching the older official tutorial for LUTS - I believe James was using the highest quality as an example here, but it certainly could have been explained clearer as to the use and repercussions of such a setting.

    I'll be sure to suggest better wording in any future re-writes/revisions of this video!

    In regards to the quality itself, I certainly don't believe that the max value is required and this would absolutely explain the difference in load times for 'Affinity LUTs' vs non-Affinity ones - as most LUTs are created using either 16x16x16 or 32x32x32 AFAIK :)

    Hi Dan, I see you have the staff icon under your name. Do you happen to be one of the developers, or have communication with them? I was wondering if you knew if the issue I first posted about here is going to be fixed. 

  6. 10 minutes ago, iconoclast said:

    I think there must be something wrong with the self exported LUTs anyway, because if I use the ones I created myself, they take a lot more time to apply their effect to the image than all the other LUTs I have downloaded from web.


    That's odd. I haven't noticed anything like that. What dimensions are your luts? 

    If you use the small 17 * 17 * 17 cube size that's the default, it might take a longer time because there's more interpolation to be done between the points defined by the LUT. Alternatively, if you are using a very large size, that would mean the program applying the LUT has a larger file to load into memory. Good LUT sizes are 33*33*33 or 64*64*64. Most LUTs you'd download from the web are one of these two sizes. 

    It's also possible that the exported LUT contains out of gamut values (less than zero or more than one). I can't recall at the moment if these values are clipped when exporting LUTs. Sometimes that "upsets" programs that apply LUTs.

    Otherwise, I'm not really sure why that would happen to you. 

     

  7. I insalled the latest update to Affinity recently and it appears this issue still persists. Current version is 1.10.5.1342. Adjustments done with the HSV mode enabled for the HSL adjustments panel still export as if the HSV tickbox were unchecked. Hence, applying the LUT to the same image fails to reproduce the same adjustments as HSV.

    If any devs see this, do you know if fixing this issue is on the to-do list?

  8. 53 minutes ago, Aftemplate said:

    IMHO. The L slider that changes the saturation is useless. Give the user at least one option to turn it off. Now, HSL is scrap. Awesome!


    The lightness affecting saturation is part of how HSL works, so it's working properly. It's just a crappy model of color. The polar transformations of CIELUV and CIELAB, known as HCL or LCH (usually with ab or uv written afterwards to indicate which CIE color model is used as the basis) are far better at separating lightness and chroma (not saturation). HSV and HSL don't even separate luminosity and saturation from the hue well, and the same lightness/value for different hues corresponds to different lightness when measured with a device independent color space like CIELAB. HCLuv/ab is also independent of the particular working color space, being based on such device independent color models.

     

  9. 3 minutes ago, walt.farrell said:

    Not exactly.

    First, I found your HSL settings too subtle, at least with my test image. So I made a simpler one that made a huge difference in the image. I then checked the HSV box and verified that it also made a huge difference, but obviously different than without HSV checked.

    I then exported each as a .cube file, then Opened a different image, and pasted the HSL adjustment layer into it and verified that it also made a huge difference in that image.

    I then deleted the HSL adjustment in the new image, created a LUT adjustment, and loaded one of the .cube files. No difference at all. I then deleted the LUT adjustment, made another, and loaded the other .cube file. Still, no difference.

    My initial conclusion is that HSL adjustments are not captured by File > Export LUT... at all, currently. I have tested this with 1.10.4 and with the 1.10.5 beta, and in 1.10.4 with Hardware Acceleration On and Off.

    Next test (for another day) will be to see if any other adjustments are currently being captured by Export LUT..., or if the function is completely broken.


    Interesting, the HSL adjustments are captured for me. It's just that the HSV tickbox is ignored when exporting the lut. 

    If you load the luts I attached into grossgrade you can see that they are captured, and that the HSV adjustments are identical. I'll screenshot the cube representation of the luts from grossgrade, in case you don't have that installed. 

    image.png.2db87e7c374654479c254187239352e3.png

    image.png.c4539211c83f86156fee432f44aa757c.png

  10. In 1.10.4.1196 Exporting LUTs still has some issues.

    One is it seems that some adjustment layers aren't compatible with exporting LUTs. Im not sure which ones, I only know that when exporting LUTs from an image with multiple adjustment layers the results don't give the same look. And yes, the adjustment layers are all global effects.

    Second issue is that if an adjustment layer uses the blend curves feature, these are not taken into account when exporting the LUT. So, if I want to increase vibrance and set the blend curve to a linear increase from shadows (0) to highlights (1), the exported LUT will have vibrance increased equally across all tones. 

    Third issue, which I created a topic for recently, is that adustments with the HSL layer do not acknowledge the HSV box being checked when exporting a LUT. So, if I use HSV mode to create a specific look, the exported LUT ignores this entirely and treats all adjustments as HSL. Since HSL and HSV work differently, the resulting LUT is not remotely like what I created. 

    Fourth issue is that sometimes the exported LUT is just devoid of any adjustments after doing an inferred LUT. 

    Given that this topic was created in 2017, nearly 5 years later it seems that the export LUT function is still buggy. I hope these issues are given some attention by the devs in a future update

  11. HSL and HSV are different, and should behave differently as a result. 

    From Wikipedia...

    Quote

    Meanwhile, the HSV representation models how colors appear under light. The difference between HSL and HSV is that a color with maximum lightness in HSL is pure white, but a color with maximum value/brightness in HSV is analogous to shining a white light on a colored object (e.g. shining a bright white light on a red object causes the object to still appear red, just brighter and more intense, while shining a dim light on a red object causes the object to appear darker and less bright


    So, with HSL the saturation is supposed to decrease with an increase in luminosity. It also decreases with a decrease in luminosity. 

    In HSV increasing the value doesn't affect the saturation as much. If Adobe Photoshop is calling something HSL and it behaves like HSV, then they are utterly incorrect in their labeling and need to learn some basic terminology before peddling their overpriced subscription software. 😒

    Either way, I wish Affinity implemented the superior HCL color models based on either CIELAB or CIELUV. They are more perceptually uniform and do a better job of decomposing colors into three orthogonal components. 

     

  12. Running Affinity Photo version 1.10.4.1198 on Windows 10..

    In the HSL adjustments panel there is a tickbox labeled "HSV" which switches the adjustments to HSV mode. Keeping all the numbers the same, switching to HSV mode will look different since HSV has different properties. However, when you go to export a LUT , the LUT will look like HSL regardless. 

    There are other little bugs with the lut export I've come across but this one is the most problematic for me (and I dont recall the others at the moment) because it means a LUT I try to design using HSV is unable to be saved as a LUT. 

    I attached the LUTs exported using HSL and HSV modes respectively below. 

    To reproduce this:

    1. Make the following adjustments with the HSL adjustment layer:

    Yellow : Luminosity 15%
    Green: Saturation -40% ; Luminosity 70%
    Cyan: Hue -10% ; Saturation -35%; Luminosity -20%
    Blue: Saturation -5%; Luminosity 30%

    2. Leave HSV checkbox unticked. Export a LUT and name it HSL. 

    3. Re open the adjustment layer, and tick the HSV box. Re-export a LUT named HSV. 

    4. Disable the adjument layer, and create a new LUT adjustment layer. Load the HSV lut. Notice that the results appear as if the HSL mode was used. Load the HSL lut and note that it is no different in appearance.
     

    HSL.cube HSV.cube

  13. I am also having a similar experience. I am inferring a LUT from an adjusted image using the LUT adjustment layer. Works fine. The inferred lut does a good job. However, I can't export it. If I export a LUT, the LUT contains no adjustments. It just ends up being an identity LUT. I have tried merging the LUT adjustment layer as well as leaving it as its own layer, but in both cases, the exported LUT is just the identity LUT.

  14. On 11/23/2021 at 3:22 AM, kirk23 said:

    I had Xright  checker  once and  then misplaced it somewhere.   From what I remember it still had been a learning curve.  Starting from basics what ICC profiles are. 

    Recently I bought a cheap $15 color checker, no software  and it somehow works  with LUT layer  right away.  You make a picture of it , then edit color charts to colors values it  should be  and use it as a target second image during  LUT building.        But again I have no idea how precise it actually is.   

    Perhaps less precise but still looks enough to extract albedo diffuse  color  from something in blue late afternoon  shade  for example , A reason I use the checker for..

    I am not saying an ICC solution is redundant , I just found this workaround and it seems very simple an cost effective

    Thanks for sharing the knowledge. It's always good to know more than one way to do things. 

  15. 13 hours ago, kirk23 said:

    I am not against it actually.      It just requires a special soft to profile your camera.  hours of manuals reading , hours to figure out how icc profiles works  and what they are  so you wouldn't  set a camera profile as your system one.

    While this LUT building approach   from original picture and another picture  with color chart values  set by books   as a target    seems  amazingly simple to do  and moreover to  understand .   I just  adore a simple solution for a complex problem.         But  I don;t know  really how precise it  is   vs  ICC profile


    I'm not sure what approach you learned for building ICC profiles, but there are a few easy methods.  There's  Lumariver Profile editor (although the basic version only does DCP profiles) , and if you buy x-rites brand of color checker it comes with software to make ICC or DNG profiles. the QP card 202/203 also has software for ICC, though if you encounter any issues with their software (which hasn't been updated in a while) they don't respond to email at all so I'd shy away from QPcards. I suspect the company behind them is defunct. The SpyderChecker brand one I think also comes with software. Basically all you do is take a picture of your color chart, feed it the raw file or tiff, and it gives you a profile. 

    I hope that helps if you ever revisit them, but if you're happy with your current workflow, nothing wrong with that either! 

     

     

     

  16. 1 hour ago, kirk23 said:

    I truly believe  RAW development  should be merely  exposure range  choosing to clip and all .    Or not to clip straight to 32 bit file .  Never understood why people  tweak colors in RAW.   It's so much more convenient in the soft itself with adjustment layers.

    You have LUT adjustment layer where you can make your own camera/ illumination or whatever specific correcting  preset .      Aphoto have a great  advantage over Photoshop with LUT  building tool  from original and target  image pair .    Works for me  with color charts images as a home made camera "profile".

    Technically speaking the only raw color changes done are the white balance multipliers, after that, the image is demosaiced and it's a 16 or 32 bit image (depending on the raw developer) held in memory or as a temp file on the hard disk that the adjustments in a raw developer operate on.  Camera color profiles are ICC or DNG profiles applied to that demosaiced image. No reason it can't be a LUT file so long as the values in that LUT are suited to the color space the image is in. The advantage of using ICC profiles is that the values are stored as Lab or XYZ (or can also be a simple matrix profile). It's possible to convert an ICC lut to a .cube lut (or whatever lut format) so long as the software you apply it with accepts values below zero and above one. I'm not sure how affinity handles that, might be interesting to go check later.

    Nevertheless the point is, despite your personal preference, a great many people expect this feature in a raw converter. The forum is full of people who have asked for this to be (re)implemented so it meets the majority of people's minimum expectations for a raw developer , but the Affinity Photo programmers seem to be consistently silent on this. I don't know why, all they really need to do is incorporate lcms2 into their code to do it. Shouldn't be very difficult for a programmer 

  17. 17 minutes ago, RichardMH said:

    If you are that fussy about colour, buy 3D LUT Creator. It does RAW conversions and has 16 colour spaces you can work in.

    Are you addressing me or the OP? 

    If me, I'd hardly call it being fussy. Lch is objectively a better color model. Though personally I don't care if it's in the develop persona, since I don't use it anyway given that the raw developer in affinity lacks the ability to use input profiles. So, I typically convert to tiffs with dcraw, maybe sometimes use darktable or rawtherapee, and do anything else in AP 😁 

  18. 27 minutes ago, NotMyFault said:

    Can you elaborate in more detail what you are expecting? Photo has LAB/16 Color Model, and can use Curves and Levels Adjustment in LAB/16 mode even if document stays in RGB mode.
     

    Colors can be defined as LAB/16, too, but only on combined 2 La / Lb axis (not as 4 separate axis).

    What is missing?


    What I mean is replacing HSL with CIE Lch , which can be based either on CIELAB or CIELUV. It would operate just as the HSL panel currently does, but the advantage is perceptual lightness and saturation are more stable when doing hue rotations.

    To see this, go to this HSL slider online, leave saturation and lightness at a fixed value. Slide the hue. Notice how as the hue changes, the apparent lightness and saturation alters despite the L and S values remaining fixed. Now go here to the CIELch slider and do the same.  Notice how much more stable the brightness and saturation are when leaving the values fixed and adjusting only hue

    When using the CIELch model, it is easy to see that colors with the same lightness value are equally perceptually light, and any colors with the same chroma are equally perceptually saturated. So, when using an Lch color panel adjustments can be made to an image with much smoother gradients.

    So yes LCh can be just a transformation of the lab color model but it gives an interface with the ability to focus on particular hues etc just like HSL

×
×
  • 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.