Put texture proportion in description on upload?

[Christina Halpin]

An obvious problem in SL is that the height and width of a texture are not saved on upload. (Only the proportion is needed.) A scripter could deal with this problem if the height and width were saved in the description field of a texture.

The description field seems to be empty. It can't be that hard to change the upload image program so that it includes this, and it already has the numbers.

Sorry if this has been asked.

[Rolig Loon]

I'm sorry.  What's the question?  If you are suggesting a new feature, the way to do it is to submit a JIRA report and tag it as a new feature request. 

[Christina Halpin]

I will do that if no one knows anything wrong with this request. Thanks.

[Quistess Alpha]

AFAIK, there's (currently) no way to get the description field of a texture via script.

[Christina Halpin]

and that's an idea killer. Alas. Thank you!

 

[Bleuhazenfurfle]

We have a space for this feature ready and waiting for it to be implemented: llRequestInventoryData

Having access to the description would be a good fallback in the event the DB simply doesn't have that information presently, but I'd prefer to see the description working as an actual description.  But if they really don't want to add a separate field for this, then shoving aspect ratio at the start of the description field, and letting us access it, would indeed be a reasonable fallback.

Just off the top of my head, I see two problems here;

1) I suspect there arises a problem of privacy with giving us access to the description field, since you need to be able to look up an images size/aspect by UUID alone, and we can't know if/what else that description could contain — especially if we're ever allowed to actually use it for its intended purpose.  So to make this work, they need to at least come up with a scheme to distinguish it from description text, so they're only giving us the aspect part.  And at that point, it'd be easier to just add a new field and do it right.

2) The killer issue, though…  I don't think the texture HAS a description field.  (At least, not one we'd be allowed to poke at.)  Pretty sure the description field is only on the inventory item, which is only available if the texture is there in the prims own inventory, and can be different for each and every instance of that texture.  This would still be fine for a large number of use cases, however, so a reasonable interim fallback, given just the scripts ability to read inventory descriptions.  (And having it in inventory also removes the privacy consideration above.)  But in those same cases, we already have it's name, and can just put it in there instead..

So I think llGetInventoryDescription is still a reasonable thing to keep pushing for in it's own right (feels weird we don't already have it…  unless LL are themselves using the description field of some items for something, and don't want us to find out — maybe that's where they hide their friday night pub limericks or something), and I am VERY certain I've seen Jira's requesting access to inventory description, but I guess another one won't hurt — let them know we still want it!

But asking specifically for image aspect ratio by that means, I strongly expect would be DOA.  And probably not much better for asking for an inventory field for it (plus I don't think that's really want you want, either).  llRequestInventoryData is the right place for this, since the sim almost certainly never actually needs this information itself, and because we really want it to work on textures by UUID which the sim quite likely has no reason to have any knowledge of at all.

So on the topic of llRequestInventoryData specifically…  (Which last time I checked, returns zip for textures presently.)

There's at least one already; my Jira:  https://jira.secondlife.com/browse/BUG-232877

Some similar discussion around the topic just recently: https://jira.secondlife.com/browse/BUG-234448

In that case, no new commands are needed or anything, and as I suggest in at least one of those, if they stick to a float aspect ratio as the response, they could return a flat "1" for images that are lacking the original size information.  A "1" like that would both be interpreted as the most useful value in a float cast (the same value we currently assume for all textures), and also be trivially distinct from a proper stored "1.000000" aspect ratio.

Edited October 1, 2023 by Bleuhazenfurfle
Typo, wordo, and forgetto fixing mostly… As per usual.

[Christina Halpin]

For me, I want an object to be able to find out the correct aspect ratio of an texture within that same object. So that would not seem to be a privacy issue for using the description field. And the description field is so freely offered to the public (for objects at least) that I can't imagine someone putting private information there.

Is there any way to even fill the description field of a texture on upload? I assumed it was always blank. Pictures, I see, have a description.

My guess is that a string like 1043x987 would be the easiest way to put the info into the Description Field. The numbers could be easily extracted, and the format would be very distinctive.

[Wulfie Reanimator]

13 hours ago, Bleuhazenfurfle said:

1) I suspect there arises a problem of privacy with giving us access to the description field

What kind of privacy issue? An inventory item's description is always visible, even if you're not the owner.

14 hours ago, Bleuhazenfurfle said:

2) The killer issue, though…  I don't think the texture HAS a description field.

It does!

[Frionil Fang]

35 minutes ago, Wulfie Reanimator said:

It does!

Actually, the inventory asset has the description, the texture itself doesn't. That might be the issue referred to here.

Both inventory assets are copies of each other, the UUID is the same, but each has their own description.

[Wulfie Reanimator]

3 minutes ago, Frionil Fang said:

Actually, the inventory asset has the description, the texture itself doesn't. That might be the issue referred to here.

Both inventory assets are copies of each other, the UUID is the same, but each has their own description.

Well yeah, but aren't we talking about inventory assets? The main point might be about textures in specific, but the description as we interact with it isn't any different between inventory item types. It's always readable regardless of owner/permissions, scripts just don't happen to be able to read it.

[Quistess Alpha]

Also of note, inventory of in-world objects do seem to have a description field. . . as well a sale price and buyable flag.

[Christina Halpin]

I should have said this. There is such a thing as good composition in art. Picasso has it, Pollock has it, Van Gogh has it, and a lot of artists have it. When their pictures are displayed in the wrong proportion (aspect ratio), the good composition goes away. And the art isn't enjoyable. So, art wise, the frequent mis-proportioning of pictures is a real problem at SL. Most people don't consciously notice a mis-proportion, so you may be unaware of the problem and unbothered by it, but it is taking away some of your enjoyment of art.

So the time-consuming and tedious act of getting the right proportions is a problem, and people make mistakes even when they care about this issue. So if there is an easy solution, it probably should be made. I will try to add to a ticket.

(And I understand that "serious art problem" is semi-oxymoronic. This just seems to have an easy solution. Someone said that reading descriptions of textures has already been proposed.)

 

 

[Qie Niangao]

6 minutes ago, Christina Halpin said:

I should have said this. There is such a thing as good composition in art. Picasso has it, Pollock has it, Van Gogh has it, and a lot of artists have it. When their pictures are displayed in the wrong proportion (aspect ratio), the good composition goes away.

Maybe everybody else got this right away but it's a different problem than I thought at first. I thought it was about scripts knowing the X, Y resolution, perhaps in order to show square pixels, but the problem instead is a single floating point value to represent the correct X/Y proportions of any surface presenting the image, regardless of its resolution. (Indeed, depending on content, the sharpest image per megapixel may use far from square pixels.)

So yeah, this is real metadata that would need to be recorded with the image, not anything that could be extracted by examining its representation.

[Love Zhaoying]

1 hour ago, Qie Niangao said:

So yeah, this is real metadata that would need to be recorded with the image, not anything that could be extracted by examining its representation.

Interesting that there is not any LSL function for this. You basically have to know about your texture before you start to use it.

This "makes sense" for things like "animated textures" where each "section" represents a "frame"..

But for normal textures, you'd think the X/Y metadata is stored in the texture already (as with most graphic formats!!!), there's just no LSL function to query it, from which you could then use that info in a script.

[Quistess Alpha]

2 hours ago, Qie Niangao said:

So yeah, this is real metadata that would need to be recorded with the image, not anything that could be extracted by examining its representation.

Actually, I just realized SL ~Does store the original x,y dimensions of every texture, just not in a way scripts can access. Details of how to access it vary by viewer, but it's usually underneath the texture in the 'texture picker' window when you try and texture an object. The default wood texture is 512x512, the blank white texture is 32x32.

[Lucia Nightfire]

llGetInventoryDesc() allegedly is coming soon.

It has certainly been asked for many times this year, let alone, over the years.

Maybe @Rider Linden can tell us when? 🤔

[Christina Halpin]

I created the suggestion for a new feature (add for example 452x923 to the description field of a texture on upload). If adapted, it would be very simple to build a picture frame that automatically adapted to the picture's proportion (once this information can be read).

And it seems like such a simple and safe change.

Thanks to everyone here for helping me understand how my concerns fit in with SL, to encourage me to even make that suggestion.

[Rolig Loon]

2 hours ago, Quistess Alpha said:

Actually, I just realized SL ~Does store the original x,y dimensions of every texture, just not in a way scripts can access. Details of how to access it vary by viewer, but it's usually underneath the texture in the 'texture picker' window when you try and texture an object. The default wood texture is 512x512, the blank white texture is 32x32.

That's true.  However, when a texture is uploaded to SL, the system modifies its aspect ratio automatically by setting X and Y pixel values to the closest power of two below whatever the original had.  So, a 256 x 256 image will be uploaded as a JPEG2000 256 x 256, but so will a 300 x 256 image.  A 250 x 256 image will be uploaded as a 128 x 256 image.  I'm not sure whether the note in the Description field will ever tell you what the original pixel dimensions were.

[Bleuhazenfurfle]

On 10/2/2023 at 8:21 AM, Frionil Fang said:

Actually, the inventory asset has the description, the texture itself doesn't. That might be the issue referred to here.

That is exactly what I was saying, yes.  A texture can be applied by UUID alone — where we don't have the original name, description, or anything of the sort.  And I'm not sure we want to let people read the description, even if it had one (presumably one given to the texture at upload time).

Having size on the inventory item alone seems mostly pointless.  Handy when you're building, sure, but in that case you'll usually have access to the original — or should…  and you can always include the size in the name of the image, that's what I generally do (because I know I'm not going to remember it).  Don't need anything extra for that at all.  (And I'm no artist, but even I know that'd go double for "art" destined for a gallery — how an artist can fail to note it in the image name, is mind boggling.)

The missing piece, is for scripts and viewers.  I think most of us have probably made a photo frame at some point, that at least shows a random image dropped into it's inventory…  that was like the second or third script I ever wrote when I was first learning, followed not long after by another much better one that ended up being the basis of a wedding present for an SL friend…  (Like you see those billboards with the slats that rotate to show the next image, with a little staggering so it went across as a wave, and then would load the next image onto the previous faces…)  As it was, she stretched it to a shape that suited the images she wanted to show, and then clipped and re-uploaded a few to fit properly.  Would have loved to be able to adapt to each images aspect ratio.  (I remember having that discussion, and offering to make it scale according to a code in the image name, but she said that sounded unneccesarally complicated, and I wasn't particularly inclined to argue the point.)

And the reason my Jira mentions size, with aspect ratio as an after-though, was exactly recognition that knowing the actual image size could be useful for some weird esoteric cases, and since we know how the images get scaled, we can figure things out when needed, so long as we have all the information…  But then the question of formatting comes up ("x" is pretty standard, but CSV would probably be better), what if they change the way they do the scaling…  And even just the question of what format to use could well block the feature (if it hasn't already)…  So I included the suggestion of a simple aspect ratio as fall-back.

The one point raised here that I hadn't accounted for in recent thinkings on the topic…  Is that images are stored scaled, but rectangular.  I know better, but for some reason I was thinking they were all stored square when I came up with my "use '1' for default" idea.  Still…  If it uses the usual 6 decimal places for real aspect ratios, and only 5 or fewer for the defaulted ones…  That'd work just fine (the "guess" will be wrong by far more than that, anyhow, unless the image was actually a power of two originally).  Not ideal, and I'm not sure it even matters, which being both a totally transparent indicator, and likely adding next to nothing to the complexity.

Edited October 3, 2023 by Bleuhazenfurfle

[Christina Halpin]

1 hour ago, Bleuhazenfurfle said:

 

Having size on the inventory item alone seems mostly pointless.  Handy when you're building, sure, but in that case you'll usually have access to the original — or should…  and you can always include the size in the name of the image, that's what I generally do (because I know I'm not going to remember it).  Don't need anything extra for that at all.  (And I'm no artist, but even I know that'd go double for "art" destined for a gallery — how an artist can fail to note it in the image name, is mind boggling.)

It actually would be useful. (Look how long this answer is!) First, you don't realize how often people get it wrong. You don't realize how many people aren't even aware of the problem.  And the solution is simple -- anyone who builds a picture frame in the future could have the object resize to fit the picture.

Suppose I want my object to cycle through 20 pictures, which means changing size to fit the picture. You are asking me to rename 20 pictures. Or, my programmer is asking me to edit 20 pictures to add size to the description field. If I have 4 of these objects, that's 80 pictures. And I will probably make 1 mistake, though I will see it. And if I make it up to 20 of these objects . . .

Now, ordinary people upload pictures SL. They don't know the simplest way to do things. And it's not obvious to them what size to make a picture that is 565x793 as an image and should have a height in SL of 2.0, the width is. Test how many people would even try to figure that out.

I have probably uploaded 1000 images, so I know the quickest, easiest way to figure out that fourth number  And if you can save just 2 minutes of my time for each, that's 33 hours.

And, it is easy to script a frame to change size IF you know how the information about proportions is stored. If SL puts the picture size in the description field, that standardizes everything. If people create their own method, a scripter who is selling a frame won't know how the information is encoded. So putting the information in the description field, which is currently empty on download, would improve the SL lives of anyone who uploads and image or sees art on a wall or gallery.

[Rider Linden]

22 hours ago, Lucia Nightfire said:

llGetInventoryDesc() allegedly is coming soon.

It has certainly been asked for many times this year, let alone, over the years.

Maybe @Rider Linden can tell us when? 🤔

llGetInventoryDesc has already been included in the Fall Colors simulator. 

If all goes according to plan, I should be handing that off to QA at the end of next week... 

Other fun scripting things in Fall Colors:

• llIsFriend
• llListFindListNext (no doc yet)

And perhaps, feasibly, possibly, maaaaaayyyyybeeeee something having to do with rezzing objects from scripts.

[Wulfie Reanimator]

7 minutes ago, Rider Linden said:

And perhaps, feasibly, possibly, maaaaaayyyyybeeeee something having to do with rezzing objects from scripts.

You look very handsome today, new hat?

[Love Zhaoying]

29 minutes ago, Rider Linden said:

llGetInventoryDesc has already been included in the Fall Colors simulator. 

@Rider Linden, the WIki page shows llGetInventoryDesc() returning a "key", but the example shows a "string".  I realize that "keys can be used as strings", but this seems misleading in the Wiki function header and example.

Function: key llGetInventoryDesc( string item );

Returns a key with the description of the inventory item.

(Sorry for the formatting, I pasted as formatted from the Wiki page.)

default
{
    touch_start(integer total_number)
    {
        integer count = llGetInventoryNumber(INVENTORY_ALL);
        integer index;
        for (index = 0; index < count; ++index)
        {
            string name = llGetInventoryName(INVENTORY_ALL, index);
            string desc = llGetInventoryDesc(name);
            
            llSay(0, "Item: \"" + name + "\" -- \"" + desc + "\"");
        }
    }
}

 

[Rider Linden]

It returns a string.  I'll fix the doc.

[Bleuhazenfurfle]

3 hours ago, Christina Halpin said:

It actually would be useful. (Look how long this answer is!) First, you don't realize how often people get it wrong. You don't realize how many people aren't even aware of the problem.  And the solution is simple -- anyone who builds a picture frame in the future could have the object resize to fit the picture.

Suppose I want my object to cycle through 20 pictures, which means changing size to fit the picture. You are asking me to rename 20 pictures. Or, my programmer is asking me to edit 20 pictures to add size to the description field. If I have 4 of these objects, that's 80 pictures. And I will probably make 1 mistake, though I will see it. And if I make it up to 20 of these objects . . .

The intent is useful, absolutely — we want the same thing, in fact.  I was referring only to the specific method you are asking for.  And I had hoped the little story in the middle of my last post would have made my understanding of your issue clear, though perhaps I cut it back a little too much — my post was about twice as long as I'd originally written it…

And you're making some unfounded and distasteful assumptions there, which is always a bad footing from which to present an argument — try not to presume what someone else does or does not know, unless you at least actually know them.  The little story I had in the middle of my last post was intended to signify that yes, I get the issue quite clearly — back in 2012 when I wrote my picture frame thing, I faced precisely that issue, as I suspect many others have before and since — you are not the first person to discover this issue.  (Nor even to suggest that specific remediation, I should add.)

Subsequent to this features implementation, all NEW images should be tagged appropriately, and it would not be an issue.  Likewise, for the older ones if the original size information is present and merely not yet exposed, then also it will not be an issue.  And whether it gets stored in the description as you suggest, the name as can be done right now, or another internal field, is largely irrelevant within the specific and very limited use case you have presented.  My counter-argument was merely that the description is a bad place for it to begin with (for reasons I have only briefly touched on, and you appear to be unaware of), and fails to support the more general cases for which a path is already mostly clear and accepted.

To make that one point clear; for any images prior to this feature being implemented where size information is absent, then yes, neither your suggestion nor mine is going to magically add size information to existing textures that lack it, and you would hence indeed have to rename those pictures to manually include it (or otherwise make some other equally manual alteration to the image inventory metadata).  So I'm afraid that most of your argument there is utterly redundant and void — we will continue to do what we must, as we always have, ere this feature gets implemented.

Edited October 3, 2023 by Bleuhazenfurfle