TestTools

Good idea Carl23. I do have Publisher, so I will try that next time...sounds like an excellent tool to use. As it was, I ended up making a grid with lines at exactly the right dimensions, then making that into an SVG. Later I needed to open it to change the color to a lighter grey, and save that into a new SVG. A tiny bit cumbersome, but it makes the .afdesign file a lot lighter too. Thanks! VisibleSpectrum-Mask-Numbers.afdesign

Thank you v_kyr. I poked around those assets that you linked to (many thanks), and in the end I made the grid again myself with lines that I eventually turned into an SVG file and imported. I would never have thought of that simple solution. It also allowed me to easily extend the UV section which was a little off. Just starting to export the variations but didn't want to delay that thanks any longer.

Hello. I have created a drawing that I want to add a grid on top of (…actually, layer 3). I made one the most cumbersome way, individual small boxes – a lot of boxes since the document is 4096x2048 pixels large. I ended up having to resize them which caused them to fall off the native pixel lines of my dislay, aliasing horribly. (It is used to give the eye help locating the Just Noticeable Difference between colors). I resized them to align with the tic marks on the main line. I will have to recreate a new grid so it displays correctly (on a 4k laser cinema projector) and place the tic marks based upon the tics. But I would like advice on how better to create a big grid without so many individual items. It prevents me from exporting in PSD FCP layers. (The dialogue box) said it had exceeded 8000 layers!) Appreciating any advice with thanks.

Hello – I want to get my document layers into Final Cut Pro, but it doesn't accept PSD files over 8 bits RGB. This drawing is 16 bit 2020 color space. I need to maintain that from AD into FCP. I have experimented getting the drawings out with the Export Persona Slice tool. It can be done. But the slices are all seperated at the dimension of the object in the layer. They don't maintain their position in the whole document, which means that I have to reposition them after importing them into FCP. I tried by putting an Artboard as a layer beneath everything in the hope that everything would come out in relation to that – but no go. The ideal would be that all the slice layers were the full size of the bottom layer, transparent except for the drawing of the layer. Is there a way to do this? Bartleson-Breneman_Triangle16Nov.afdesign Bartleson-Breneman_Triangle_Circle.tiff ball4.tiff Bartleson-Breneman_Triangle.tiff

Hello – I brought the attached drawing – exported as a TIFF file, 16 bit RGB/2020, into Final Cut Pro, which was set up for HDR. Looking at the the scope readout it seems that all colors are hitting 100 nits. Why? And if I can control this in Affinity Designer, how can I make it export TIFFs at 300? or 48? …for example. …or 1000? Thank you PS - Knowing full well that this may be an FCP setting that I have to dig into. Bartleson-Breneman_Triangle16Nov.afdesign

David, hi. Did you ever figure a clean way out of this problem? Since FCPx still doesn't accept PSD layers in more than 8 bits – and I need 12 and Designer allows 16 – I have been trying this slice solution and came up with the same problem you did, that the images don't stay placed.

@NotMyFault Thanks again. I think the issue you are describing may not apply to what I am describing. (…though I could be wrong.) I can see how different spaces may interpret with different ramps when placing something – But I am not 'placing' anything. I am creating 2 squares, then filling in the color. I don't understand why 65535 x .18=11796 in each of RGB doesn't equal the pulldown of 18% Greyness. I would presume them to be the same. But now I have tried even the most elementary example, using 256 color picker and even 8-bit Grey or 8-bit RGB in 709 space, and many in between my original 2020 16-bit space. 50% greyness and 256/2 (…or 256*.5) don't equal the same color. This happens on an iPad as well. And, I can't get help on "Grayness" in the manual. 2SquaresGrayness.afdesign

Wow! Thank you. This is going to take me a bit of study to wrap my head around. Many thanks for thinking it through and the details of explaining with graphics. I guess I have to make in-situ tests to find out what gets through the entire system most accurately.

Back in my youth, I remember something about 50% grey not being 50% grey and a trove of mystical perceptual knowledge things. Is this one of those? You will notice on this "all for education, not a copyright infringement, I promise" 2020 color space version of the MacBeth chart that I am fumbling around with (attached). I put 18% grey behind all the swatches. How did I do that? By racking up the R in the 16-bit RGB picker and typing 65,535*.18, then copy pasting the result into G and B as well. But, when I pull down to Greyness, that turns out to be 25%. In this iteration, the swatch marked 18% is "Grayness" 18% so you can see the difference between the two colors. The numbers are different for 40% (a 5% difference) and 20% (a smaller difference, 2 or 3% but I didn't write the numbers down to say for certain.) Background: The concept is to use this slide in a cinema projector that can correctly portray the 2020 gamut, and I am expecting that I can do the primaries and secondaries and greys by numbers. The little boxes in the arbitrary top two rows are the original Hex numbers (unfairly since they were made for D50 and a much smaller gamut and reflective, no emmisive), while most all of the larger sections are just my putzing around trying to use combinations of 25% increments to somewhat imitate what I understand to have been the original intention. But it is this grey issue that I am wondering about – shouldn't I expect that Greyness 18% be equal to 18% of the 3 color values? Thanks! MacBethStyle-16RGB-2020-ColorChart.afdesign

And if I do these right, then they can help people examining that tangent of science as well. Do you know anything in particular about that or have any interesting links?

Very interesting about the 'noisy bits'. My final product is eventually 12 bit TIFF in 2020 gamut that is eventually converted to X'Y'Z' numbers. The display is a 12 bit projector in 2020 or an 12 LED wall in 2020, both with up to 1,000,000:1 contrast ratio, starting at 100 nits and going into the 0.0001 region. (Or at least, that is what is advertised.) My attempt is to create slides that – when shown in a dark room – which show where the change in black level is no longer discernible by the eye. …and other slides that show the change in white level until the change can't be noticed by the eye. …and create slides that can be reliably used by spectrometers and colorimeters. And, I would like to control the Delta between the boxes that can be seen. This was somewhat simple when creating slides for the standard that is 2000:1, from 48 nits to .024. and dividing 65,535 pixel values. Not so simple now. Too many unknowns until I understand it. I have watched some of the HDR/EDR videos, though I understand that there is one dealing with OpenColorIO that James Ritson did. I am searching for that. There is a 2nd similar requirement for 300 nits to 0,005 nits, also in the 2020 space. PS – Attached is the latest Box of Greys that open correctly in both Photo and Design in HDR32 / 2020. PS2 - That is why I want to put your box of all colors into 12 bits 2020. I think it would look spectacular on a huge screen. PS3 - I have installed OpenColorIO and am also trying to learn how it can help. BoxOfGreys_HDR32_2020.afdesign

Your idea of starting blank with HDR32 in the IEC space it prefers, then changing does seem to work better than ripping all my hair out trying to get the programs to do it in one step. When I get the time, I will try to write a proper bug report about what incorrectly happens in the color transform. Even doing it in multiple steps has some incorrect color transform, though it only seems like small dithers of the calculated amounts. (For example, the original might have a calculated amount at started as 65535*.2*.99 which gave a grey number of 12976, (the first one calculated and the 2 others copy/pasted). But when put into HDR, the 3 RGB numbers will be 12,978, 12,975 12,977 – and this is consistently off on all 120 x 3 numbers that are in this particular diagram. Anyway, I didn't communicate correctly. When I said …, I meant that I was trying to make you 8bit, "chart of all 2^24 RGB colors" into a 32 bit version in 2020. Many times later, I think that maybe it is working, but I don't have a screen that will show it. What I did was replace all the 256 with 4096 and 253 with 4095 and the 16 with 128. That was what I was asking for clues for. So much to learn. I have a 500 nit screen and my computer internals say 30-Bit Color (ARGB2101010), but the MAC OS 12.3.1 doesn't allow this to be HDR. Alas. ...and I haven't considered checking my iPad. Anyway, thanks again. I am currently trying to figure out why the .exr export from HDR32 in 2020 gives a 32 sRGB IEC61966-2.1 Linear and whether this is my mistake or just the way that it goes. So much to learn.

I don't see an uploaded file! …but I like the idea and thanks for the assistance. Still trying to wrap my head around all the permutations of HDR.

Ugh; Just realized that the original RGB16 in 2020 gamut design that I put into a 32bit 2020 gamut attempt has had its RGB numbers shifted before I started making 'filtered' versions. I thought I figured out how to start a new blank page then add the old bits. I have been successful with one set of drawings. Evidently not with the early attempt, so the attachment has been removed. Meanwhile, NotMyFault, I have watched and practiced with some basics of Procedural texture filters. Many thanks for the heads up and the design you created and sent. Still can't figure how to make it into the 32bit/P3 or 32bit/2020 gamut. Any clues would be appreciated.

Wow. Marvelous. Of course, without having a clue of what you really did, I modified the document in Designer (I have 0 experience with Photo) to be a full frame 4K cinema slide (4096 x 2160) in a 2020 gamut, and changed all the 256s into 4096 and 255s to 4095 …and now have one full screen beautiful tile. I guess I have to find the magic spot to tile it up all the variations. But still, wow!

Thanks. I think I understand this and have messed with it a bit. It will take me a while til I actually grok it. Since the human eye says 'no more' long before that (+8), it would seem to be enough. But the eye after it has been in the dark for a long enough time (adaptation, right?) can see well down to about -6. Equipment won't perform that well, on either end before blooming or fading to black. TV monitors can go higher than 1000 nits, so the number of whole digits needs to be no more than what can capture 9999 …this year. The same with right of the decimal. 5 places now, 6 later? Probably more for the space people and medical. I have made some files to send to friends with filters at 10 and 1%, SVG, TIFF. I'll hopefully get some feedback that verifies the technique.

That is a simple start to my investigation! Thanks. With this (attached), it appears that I can move 1% (1/100 or 0.01) over two decimal places to 0.01%. Which, I suppose is 0.0001 of the full white level? 100:0.0001 is 1,000:0.001 is 10,000:0.01 is 100,000:0.1 is 1,000,000:1? (Sorry to have to write this out - it seemed like this in my head, but I didn't believe it. Is there something wrong with this logic? Have I reached my million:one goal already? Seems too simple. My 5K 500 nit 2017 P3 non-HDR iMac screen is beyond its range very quickly, and I don't see how I can confirm – though rolling a color picker over the adjusted blocks gives different numbers than before, and rolling over the gradient on the right seems to be a calculated number that is somewhat right, even though it is grossly pixelated. Full white (top, left, which was 100r, g and b) now measures 100.00 while full 0 black/1% at the top of the gradient measures 0.01 -so there is more granularity, seemingly more than 100:1 and seemingly a calculated number totally ignoring what is shown on the screen. I guess I will experiment with some outputs and see if that will prove the technique. Good start to the day. (I''m almost directly south of you in La Turbie, FR.) As to the rest of your ideas, like "procedural texture filter borrowed from Photo", I'll have to research to experiment to figure out what that means. Again, thanks! Box_of_Grey_HDR32-bit_less100_A1.afdesign

Hi~! I have been merrily making 16 bit slides for 2000:1, 48 Nit, 4K projection. Now I need more than 16bits will give; 300 nits and 300,000:1 Contrast Ratio. So, I am ready to dig into making HDR32 layouts – the real trick is to get down to 0.0001 into the black. I can't find any training or even much in the way of suggestions for Designer HDR, only Photo HDR techniques that don't apply. I was hoping that the color pickers in Designer would magically allow me to type in 32-bit numbers like I could type 16-bit numbers in RGB16 mode. Has anyone written up a work-flow or made videos or got any breadcrumbs to clues? I'm thinking I could make something like this attached file but divide all the numbers by 100 or 1000. Obviously the floating point can hold that much precision, but how to I input it. And does working in the 2020 space set my white point correctly for D65? …how to I set my limit to 100 nits or 300 nits? [And what questions haven't I figured out yet?] Thanks! Box_of_Grey_HDR32-bit_A1.afdesign

Deep in the memories...I remember this happening as well. Seems like the solution is to roll over the top edge or either top corner of the AD window and make the window shorter. Then lift up the window to the very top again. Then size the window correctly. (You might have to do the first step twice.

I have always found it easiest to draw a box the size of the rectangle from the right side of the left object to the center of the line. Then double the width (and center if needed.) Pull the right object left and kill the square or I will often keep it for other adjustments. Good luck to us all!

Aha! your 2nd question is exactly on point. Totally forgot about those settings in prefs. ...and didn't see the warning because it flashes off when the mouse is moved. But that is a different error to be reported. Many thanks~!

Thanks for the interesting question OBruce. The MBP is a pre-retina display, and I don't think it is in P3...certainly not DCI P3. But I put the computer in the 2020 colorspace – or the OSX approximation anyway – and then opened Designer, then stuck in the USB stick and opened it. It opened in the DCI P3 space again. I did put a copy on iCloud and opened it on the iPad. It opened in 2020... If I remember correctly, this possibly started in DCI P3 – it is being made for cinema projection tests – and I changed it to 2020. Modified the colors, etc. But I wasn't satisfied so I opened a new empty file in 2020 and copied the the elements to the new file...this file that is attached. I wonder if there is some trace of that left and that is what is making the MBP act this way. Did you download and open it? What was your experience? Any other thoughts?

SOLVED – wrong setting in prefs and the notification flashes away before being seen. =-=-= I had an open file (attached) that is in the 2020 color space, which I was working on on my iMac. I wanted to work on it on my MacBook Pro (2011) so I did a Save As to a USB stick, adding a RevA to the file name. On the MBP I Opened that file from the USB stick, then checked the Document Setup, and the file was in DCI P3. Checking my steps again, I dragged and dropped the original .afdesign file onto a different USB stick. I opened that one on the MBP and it too opened in DCI P3 space. I then Opened the RevA file on the iMac, and it opened in 2020. Perhaps this is normal behavior, but I thought I would report it. Thank you. 10Boxes4Colors-certain2020.afdesign

Thanks again. This is a good re-start. I still have to work out the anomalies to make the blends right. There is a bit more hot spotting, which I had worked out before by pure trial and trial and error (and error). But at least I know how to work with the transparency tool better. I still have to figure out how to separate the triangle colors so they don't influence the ball colors. ...a layer inserted in between perhaps...perhaps it is that there is some details that I have to learn about blend modes. There was still a very slight position difference with the red circle, even though these were all clones of each other. I've messed with it and need to mess with it again since things are now a bit out of whack...(not on this low resolution png, but the actual TIFF shows it as a tear.) But I didn't want to let time go by without another note of thanks to firstdefence and >|<. TriCircNu3.afdesign

Many thanks to you both. I'll try both suggestions soon – I messed with triangle creation, and realize my skills on making the color flow is going to take a bunch of research and practice. I must have just lucked into getting as far as I did. Just when I think that I know a bunch, I realize I am just beginning.