height map for normal input sharp edgesheight map brings weird resultalternatives for operator's report() function?Get same bump from a photo to a modelheight map brings weird resultCreate height bitmap from meshGenerating height map of group of objectsHeight Map to Mesh conversion considering TransparencyIs there a way to “clip” or “clamp” the height of a normal, so that bumps go to a certain height and then abruptly flatten, as if chopped off?Bump map height still the sameHeight Map: how to deleted unwanted faces?Height Map Using Vertex World Height (Z) as RGB ValueIs it possible to use height maps from substance designer in Blender and how?

lightning-datatable row number error

Why is it that I can sometimes guess the next note?

height map for normal input sharp edges

Can I sign legal documents with a smiley face?

C++ debug of nlohmann json using GDB

Are the IPv6 address space and IPv4 address space completely disjoint?

Fear of getting stuck on one programming language / technology that is not used in my country

2.8 Why are collections grayed out? How can I open them?

Electoral considerations aside, what are potential benefits, for the US, of policy changes proposed by the tweet recognizing Golan annexation?

Open a doc from terminal, but not by its name

Terse Method to Swap Lowest for Highest?

How should I respond when I lied about my education and the company finds out through background check?

Loading commands from file

New brakes for 90s road bike

copy and scale one figure (wheel)

Is aluminum electrical wire used on aircraft?

Can Legal Documents Be Siged In Non-Standard Pen Colors?

Problem with TransformedDistribution

What should you do if you miss a job interview (deliberately)?

Closed-form expression for certain product

Registration and login script

Why is so much work done on numerical verification of the Riemann Hypothesis?

Added a new user on Ubuntu, set password not working?

What does chmod -u do?



height map for normal input sharp edges


height map brings weird resultalternatives for operator's report() function?Get same bump from a photo to a modelheight map brings weird resultCreate height bitmap from meshGenerating height map of group of objectsHeight Map to Mesh conversion considering TransparencyIs there a way to “clip” or “clamp” the height of a normal, so that bumps go to a certain height and then abruptly flatten, as if chopped off?Bump map height still the sameHeight Map: how to deleted unwanted faces?Height Map Using Vertex World Height (Z) as RGB ValueIs it possible to use height maps from substance designer in Blender and how?













1












$begingroup$


So I have generated this simple height map to test my add on:
enter image description here



That's the node setup and the result that I am having in Blender:
enter image description here



What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result



Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)



and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
enter image description here










share|improve this question











$endgroup$







  • 1




    $begingroup$
    It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
    $endgroup$
    – cegaton
    4 hours ago











  • $begingroup$
    @cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago







  • 2




    $begingroup$
    32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
    $endgroup$
    – cegaton
    4 hours ago











  • $begingroup$
    @cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
    $endgroup$
    – SerhiiPoklonskyi
    3 hours ago







  • 1




    $begingroup$
    will do it soon. Thank you again
    $endgroup$
    – SerhiiPoklonskyi
    3 hours ago















1












$begingroup$


So I have generated this simple height map to test my add on:
enter image description here



That's the node setup and the result that I am having in Blender:
enter image description here



What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result



Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)



and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
enter image description here










share|improve this question











$endgroup$







  • 1




    $begingroup$
    It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
    $endgroup$
    – cegaton
    4 hours ago











  • $begingroup$
    @cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago







  • 2




    $begingroup$
    32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
    $endgroup$
    – cegaton
    4 hours ago











  • $begingroup$
    @cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
    $endgroup$
    – SerhiiPoklonskyi
    3 hours ago







  • 1




    $begingroup$
    will do it soon. Thank you again
    $endgroup$
    – SerhiiPoklonskyi
    3 hours ago













1












1








1





$begingroup$


So I have generated this simple height map to test my add on:
enter image description here



That's the node setup and the result that I am having in Blender:
enter image description here



What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result



Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)



and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
enter image description here










share|improve this question











$endgroup$




So I have generated this simple height map to test my add on:
enter image description here



That's the node setup and the result that I am having in Blender:
enter image description here



What is happening here (basically, that's a theory, I did not analyze the actual pixel values programmatically): Blender Bump node is interpreting each slightest variation in the pixel value (say, 0.985 white and 0.99 white) as variation in height. What you have as a result are the ugly cutoffs. By the way, a similar question with the same problem, unsolved: height map brings weird result



Now, if I do converting in CrazyBump, I have the opportunity to ignore small details, and, if I convert with CrazyBump, the map is displayed correctly in blender. By their nature, any height map, even 16K will not be absolutely smooth because the set of possible heights is a set of discrete values, it will never be smooth. The task of an algo would be to produce smooth normals from this. And this is what Bump node obviously does not do. Any suggestions? (using other software does not work, I want to achieve it specifically in the node editor of Blender, for any BW map)



and just to prove the point: if I twick the small details all the way up in CrazyBump, I will get essentially what the BumpNode in Blender is doing: overexaggerating non-significant value variations:
enter image description here







height-map






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 4 hours ago







SerhiiPoklonskyi

















asked 4 hours ago









SerhiiPoklonskyiSerhiiPoklonskyi

464




464







  • 1




    $begingroup$
    It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
    $endgroup$
    – cegaton
    4 hours ago











  • $begingroup$
    @cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago







  • 2




    $begingroup$
    32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
    $endgroup$
    – cegaton
    4 hours ago











  • $begingroup$
    @cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
    $endgroup$
    – SerhiiPoklonskyi
    3 hours ago







  • 1




    $begingroup$
    will do it soon. Thank you again
    $endgroup$
    – SerhiiPoklonskyi
    3 hours ago












  • 1




    $begingroup$
    It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
    $endgroup$
    – cegaton
    4 hours ago











  • $begingroup$
    @cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
    $endgroup$
    – SerhiiPoklonskyi
    4 hours ago







  • 2




    $begingroup$
    32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
    $endgroup$
    – cegaton
    4 hours ago











  • $begingroup$
    @cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
    $endgroup$
    – SerhiiPoklonskyi
    3 hours ago







  • 1




    $begingroup$
    will do it soon. Thank you again
    $endgroup$
    – SerhiiPoklonskyi
    3 hours ago







1




1




$begingroup$
It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
$endgroup$
– cegaton
4 hours ago





$begingroup$
It might have to do with the bit depth of the height map. 8 bit images are not enough to resolve subtle gradation. Try using images in a higher bit depth. Also, images used for bumps and normals should not be interpreted as color, but as Non-Color-Data (linear)
$endgroup$
– cegaton
4 hours ago













$begingroup$
@cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
$endgroup$
– SerhiiPoklonskyi
4 hours ago





$begingroup$
@cegaton thanks for responding. bpy.data.images['...'].depth tells me it's 32 bit depth (is this the right indicator?). Also, changing to non-color does not affect the result. take a look at the last illustration: CrazyBump can algorithmically ignore or exaggerate those cuttoffs by setting its degree of attention to fine details
$endgroup$
– SerhiiPoklonskyi
4 hours ago





2




2




$begingroup$
32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
$endgroup$
– cegaton
4 hours ago





$begingroup$
32 bit is 8bit per channel+Alpha (8 bit x 4). Try creating the image as a 16 bit per channel file. Non-color data should always be used for bump and height maps to avoid the distortion caused by the 2.2 gamma curve used in image encoded in sRGB. You might get better results using a displace modifer and subsurf than using displacement in the material or shader.
$endgroup$
– cegaton
4 hours ago













$begingroup$
@cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
$endgroup$
– SerhiiPoklonskyi
3 hours ago





$begingroup$
@cegaton holy Jesus! it has solved the problem! marry me, cegaton! I totally agree with you with regard to displacement but my idea was to combine individual alpha elements to produce reliefs and cravings easily. now it will work thanks to you. if you so wish, post an answer for others, probably with a bit of explanation on depth and how it affects the result
$endgroup$
– SerhiiPoklonskyi
3 hours ago





1




1




$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
3 hours ago




$begingroup$
will do it soon. Thank you again
$endgroup$
– SerhiiPoklonskyi
3 hours ago










1 Answer
1






active

oldest

votes


















2












$begingroup$

short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.



A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:



len(set(bpy.data.images['My8BitImg.png'].pixels))


This has returned 256, while



len(set(bpy.data.images['My16BitImg.png'].pixels))


has returned 42891 in my case.






share|improve this answer









$endgroup$












    Your Answer





    StackExchange.ifUsing("editor", function ()
    return StackExchange.using("mathjaxEditing", function ()
    StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
    StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
    );
    );
    , "mathjax-editing");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "502"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fblender.stackexchange.com%2fquestions%2f135103%2fheight-map-for-normal-input-sharp-edges%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2












    $begingroup$

    short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
    Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.



    A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:



    len(set(bpy.data.images['My8BitImg.png'].pixels))


    This has returned 256, while



    len(set(bpy.data.images['My16BitImg.png'].pixels))


    has returned 42891 in my case.






    share|improve this answer









    $endgroup$

















      2












      $begingroup$

      short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
      Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.



      A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:



      len(set(bpy.data.images['My8BitImg.png'].pixels))


      This has returned 256, while



      len(set(bpy.data.images['My16BitImg.png'].pixels))


      has returned 42891 in my case.






      share|improve this answer









      $endgroup$















        2












        2








        2





        $begingroup$

        short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
        Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.



        A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:



        len(set(bpy.data.images['My8BitImg.png'].pixels))


        This has returned 256, while



        len(set(bpy.data.images['My16BitImg.png'].pixels))


        has returned 42891 in my case.






        share|improve this answer









        $endgroup$



        short answer: as @cegaton has pointed out, save your image with 16 bits depth. If you are baking like me, this has to be done before bake, because resaving later does not generate information lost while baking.
        Go to 'Save as' dialog, there in the lower left corner choose 16 bits depth.



        A (not so) technical explanation: if you are not familiar, depth is the number of bits used to store the pixel color. With 8 bits, you store 2^8 = 256 color values at maximum, with 16 bits that's 2^16 = 65536 possible colors. What was happening in my case is the following: for the different height values in the geometry that I was baking, an approximation was generated to store the height. In other words, for heights x-0.01, x, x+0.01s, it would simply put x, because it has no bits to store all the three. Hence the flat areas in your image, where the color gets 'simplified'. For my 8 bits image, I did for learning purposes:



        len(set(bpy.data.images['My8BitImg.png'].pixels))


        This has returned 256, while



        len(set(bpy.data.images['My16BitImg.png'].pixels))


        has returned 42891 in my case.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 2 hours ago









        SerhiiPoklonskyiSerhiiPoklonskyi

        464




        464



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Blender Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            Use MathJax to format equations. MathJax reference.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fblender.stackexchange.com%2fquestions%2f135103%2fheight-map-for-normal-input-sharp-edges%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Are there any AGPL-style licences that require source code modifications to be public? Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?Force derivative works to be publicAre there any GPL like licenses for Apple App Store?Do you violate the GPL if you provide source code that cannot be compiled?GPL - is it distribution to use libraries in an appliance loaned to customers?Distributing App for free which uses GPL'ed codeModifications of server software under GPL, with web/CLI interfaceDoes using an AGPLv3-licensed library prevent me from dual-licensing my own source code?Can I publish only select code under GPLv3 from a private project?Is there published precedent regarding the scope of covered work that uses AGPL software?If MIT licensed code links to GPL licensed code what should be the license of the resulting binary program?If I use a public API endpoint that has its source code licensed under AGPL in my app, do I need to disclose my source?

            2013 GY136 Descoberta | Órbita | Referências Menu de navegação«List Of Centaurs and Scattered-Disk Objects»«List of Known Trans-Neptunian Objects»

            Mortes em março de 2019 Referências Menu de navegação«Zhores Alferov, Nobel de Física bielorrusso, morre aos 88 anos - Ciência»«Fallece Rafael Torija, o bispo emérito de Ciudad Real»«Peter Hurford dies at 88»«Keith Flint, vocalista do The Prodigy, morre aos 49 anos»«Luke Perry, ator de 'Barrados no baile' e 'Riverdale', morre aos 52 anos»«Former Rangers and Scotland captain Eric Caldow dies, aged 84»«Morreu, aos 61 anos, a antiga lenda do wrestling King Kong Bundy»«Fallece el actor y director teatral Abraham Stavans»«In Memoriam Guillaume Faye»«Sidney Sheinberg, a Force Behind Universal and Spielberg, Is Dead at 84»«Carmine Persico, Colombo Crime Family Boss, Is Dead at 85»«Dirigent Michael Gielen gestorben»«Ciclista tricampeã mundial e prata na Rio 2016 é encontrada morta em casa aos 23 anos»«Pagan Community Notes: Raven Grimassi dies, Indianapolis pop-up event cancelled, Circle Sanctuary announces new podcast, and more!»«Hal Blaine, Wrecking Crew Drummer, Dies at 90»«Morre Coutinho, que editou dupla lendária com Pelé no Santos»«Cantor Demétrius, ídolo da Jovem Guarda, morre em SP»«Ex-presidente do Vasco, Eurico Miranda morre no Rio de Janeiro»«Bronze no Mundial de basquete de 1971, Laís Elena morre aos 76 anos»«Diretor de Corridas da F1, Charlie Whiting morre aos 66 anos às vésperas do GP da Austrália»«Morreu o cardeal Danneels, da Bélgica»«Morreu o cartoonista Augusto Cid»«Morreu a atriz Maria Isabel de Lizandra, de "Vale Tudo" e novelas da Tupi»«WS Merwin, prize-winning poet of nature, dies at 91»«Atriz Márcia Real morre em São Paulo aos 88 anos»«Mauritanie: décès de l'ancien président Mohamed Mahmoud ould Louly»«Morreu Dick Dale, o rei da surf guitar e de "Pulp Fiction"»«Falleció Víctor Genes»«João Carlos Marinho, autor de 'O Gênio do Crime', morre em SP»«Legendary Horror Director and SFX Artist John Carl Buechler Dies at 66»«Morre em Salvador a religiosa Makota Valdina»«مرگ بازیکن‌ سابق نساجی بر اثر سقوط سنگ در مازندران»«Domingos Oliveira morre no Rio»«Morre Airton Ravagniani, ex-São Paulo, Fla, Vasco, Grêmio e Sport - Notícias»«Morre o escritor Flavio Moreira da Costa»«Larry Cohen, Writer-Director of 'It's Alive' and 'Hell Up in Harlem,' Dies at 77»«Scott Walker, experimental singer-songwriter, dead at 76»«Joseph Pilato, Day of the Dead Star and Horror Favorite, Dies at 70»«Sheffield United set to pay tribute to legendary goalkeeper Ted Burgin who has died at 91»«Morre Rafael Henzel, sobrevivente de acidente aéreo da Chapecoense»«Morre Valery Bykovsky, um dos primeiros cosmonautas da União Soviética»«Agnès Varda, cineasta da Nouvelle Vague, morre aos 90 anos»«Agnès Varda, cineasta francesa, morre aos 90 anos»«Tania Mallet, James Bond Actress and Helen Mirren's Cousin, Dies at 77»e