Jump to content


  • Content count

  • Joined

  • Last visited

About ch22

  • Rank

Profile Information

  • Gender
    Not Telling
  • Location

Recent Profile Visitors

192 profile views
  1. Sorry, my reference to the Photoshop model was somewhat irrelevant... and it does not matter. The key point is, whatever the actual model used in the AP colorimetric model, that putting saturation to 0 in the HSL adjustment makes the (Max, Mid, Min) trio replaced with (Max, Max, Max). This can be checked in a practical way by monitoring what happens to RGB components of a color sample in the Infos panel. Then, switching to the difference blending mode makes the original trio replaced with (0, Max-Min, Max-Mid). Since the largest component is now Max-Min, the second HSL adjustment puts the three components to Max-Min.
  2. Alfred : thanks dmstraker : finally the sorcery can be easily explained, provided that HSV model is really the cylindrical HSL model used in Photoshop Adobe color requester. In this model, if the RGB components are sorted in decreasing order as (Max, Mid, Min) — think of these components as reduced quantities varying from 0 to 1— the HSL components can be then written as H =(Max-Mid)/(Max-Min) ; S = Max -Min ; L = Max where H actually is the decimal part of a reduced hue varying from 0 to 6, with an integer part depending on which colors correspond to Max and Min components. This formulas can be inverted as Max = L ; Min = L-S ; Mid = L-TS Now, following the dmstracker process : (i) putting S to 0 in the first HSL adjustment makes the three components replaced by L (the largest component) (ii) switching to the Difference blending mode replaces the (Max,Mid,Min) trio with (0,S,TS). Since T<1, the largest component is now S (there is also a hue jump but it does not matter) (iii) opening the 2nd HSL adjustment and putting the Saturation slider to 0 makes the three components all equal to the largest component, i.e. S : we thus obtain the wanted mapping of the initial picture saturation. Unfortunately, I am not sure this Photoshop model really is the HSV Affinity model, since when one moves the Luminosity slider the above RGB components do not change in agreement with the above formulas... But maybe that's another story!
  3. My file is a macro record ; you must import it in the AP macro ou library panel
  4. I return to the original post of dmstraker. Though the recipe looks somewhat sorcery, it really builds a grey picture with R=G=B=Max-Min where Max and Min are the largest and the smallest of the original RGB components, i.e. the genuine absolute saturation in HSL models. I wrote a script which performs this computation and I obtain exactly the same results. This script can downloaded at http://www.oitregor.com/numeric/affinity_photo/divers/selection_saturations.afmacro Of course, this does not yield saturation in LAB sense, but in practice this should have little consequence. I also wrote a script for chroma — SQR(a^2+b^2) — but I failed to convert it from Photoshop to AP.
  5. Hello I hope I attach the file you were asking for. The whole experiment is very simple luminance_selection.mp4
  6. I experimented with Granger chart (see picture –can be obtained with a superimposition of a "spectral " gradient (RYGCBMR) and a BW gradient in luminosity blending mode) in 8-bit, 16-bit or 32-bit mode. The so-called "luminance" selection as given by the shortcut CMD-SHIFT-click takes three different forms! Seemingly the luminosity concept would change when switching from 8-bit to 16 or 32-bit RGB mode: I can hardly accept that. 16-bit RVB ou 16-bit LAB yield the same results — though it could have been expected that the "luminance" selection in LAB mode would be the true LAB luminance selection. Only the 32-bit result seems to stick to the expected result, namely true LAB luminance selection. I attempted to look at possible changes in the 1.7 beta version but I was unable to locate the "Document > Color Format" menu.
  7. ch22

    [AP] Unexpected display in 16-bit mode

    Well ! (and thanks for your interest) Unfortunately, after converting to Adobe-98, slightly moving the yellow to (249, 249, 32) makes the bug reappear
  8. ch22

    [AP] Unexpected display in 16-bit mode

    Thanks to ">|<". My original file was written with pixel layers instead of fill layers, but the anomaly looks the same. Sorry for cjoint. Surprised, too, I have used it for years.
  9. I met up against an unexpected display in RVB-16 mode with a very simple picture: background layer filled with plain yellow (255,222,0) upper layer filled with a black to white gradient, in luminosity blending mode The result is shown in the attached picture. The display returns normal when I switch to RVB-8 mode. The anomaly appears only for yellow hues near the quoted (255, 222,0) A bug ? My 16-bit file can be found at https://www.cjoint.com/c/IAmkbZvQIjD . It seems that the odd display is not Mac-specific
  10. A bug? The various sliders can be adjusted either directly or through the Colour Picker action, but these two actions cannot be mixed : as soon as the Colour Picker is used, all the direct adjustments of sliders are erased. A regret : at the opening, the default positions of sliders (all at 100%) result into rather poor pictures (for instance a pure chromatic circle is rendered as solid pure white). Why not to use default positions nearer the natural values of the various colors ?
  11. OK. The AP value for S (33%) is consistent with the formula given in this Wiki paper, in Fig.14-d. But what does it mean ? Saturation should not become almost meaningless. This Wiki paper does not seem internally consistent for me. In the beginning, the saturation is explicitely defined as Saturation = "colorfulness of a stimulus relative to its own brightness" = Chroma/Lightness" In the case of my near-white color, this leads to Saturation = (Max-Min)/255 (i.e. 6/255 = 2%) and this does not agree with the formula mentioned above. At the end of the paper, I read Using the same name for [various] definitions of saturation leads to some confusion [...] Even worse, the word saturation is also often used for one of the measurements we call chroma above... Oh yes! I must confess I make the confusion myself ; even worse, I consider the chroma the most interesting quantity for image processing. Anyway, thanks for the answer!
  12. For (RGB) = (243,249,247), through the Color panel or the Information panel, Affinity Photo claims the saturation is 33%. How such a high value can be obtained ? In my opinion, for this special case, the saturation value should be (249-243) divided by a number between 256 and 243 (depending on the colorimetric model), i.e. near 2%.
  13. Thanks for this answer. Although "There are reasons we have intentionally done this" sounds rather mysterious. For instance, this suggests that the original size could be recovered ; so far, not by the current resizing menu.
  14. Another extravagant feature : I returned to my surprising document with 4 pixel layers and 4 adjustment layers with empty masks (the hardcopy of the layer panel is attached) and its 300x215px version, weighting 106.5 Mo. After flattening it and resaving it, the weight is hardly changed, to 105.6 Mo. What can AP do with such a lot of Mo for a single 300x215 px layer ? I could upload the file if anyone wishes to delve into it. Now a better new : I rebuilt the whole document by copying each of the four lines of the layer panel into a new document with the same size. Saving the new document leads to a far more reasonable file of 808 ko.
  15. Hello There is something very odd when saving files in afphoto format. I came up against it when trying to reduce the weight of a document with 4 pixel layers and 4 adjustment layers (with empty masks) before sending it on the web. The weight was a logical 218 Mo for a 4600x3400 px picture size but it remained as high as 105 Mo when the picture was crushed down to a 100 px width. This seems ridiculous, does not it? So I looked for a simpler experiment. I simply loaded a JPEG picture and resaved it as an afphoto file. Then, several times, I halved its size and I resaved it. Here are the successive sizes of the picture and the corresponding weights of the afphoto files : 1800 x 1350 px : 651 Ko, surprisingly low (PSD file : 6,9 Mo) 900 x 675 px : 2130 Ko 450 x 338 px : 1008 Ko 225 x 169 px : 639 Ko, abnormally high (PSD file : 150 Ko) I joined the initial JPEG file so that anyone can repeat the experiment.