You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
This bug is more of an oversight that we've known about for quite some time, but apparently we didn't have an issue to track it yet.
Stash-Box automatically creates a downscaled copy of any image above 1280px in either dimension. For example, scene covers are often downscaled from 1920x1080 to 1280x720. These downscaled images are then served throughout Stash-Box's UI as well as the various Stash-Box scrapers in Stash. This of course is intentional and expected behavior.
The problem is that this behavior is not sufficiently transparent to the user. Once an image has been downscaled, the full-size image is still saved and accessible within Stash-Box. But, it is hidden completely within the UI. This very helpful userscript created by peolic is the only method I'm aware of to find these original full-size images, or to even identify which images have been downscaled. I believe this userscript has become a double-edged sword because the most experienced contributors on StashDB (myself included) often forget that its functionality is not actually available in vanilla Stash-Box yet. This may be why nobody (again, myself included) has taken the time to even write up this issue addressing it yet.
From my perspective this is primarily a problem within the edit queue, but I believe these inconsistencies are apparent elsewhere too. Within the edit summary, the images and resolutions displayed are of the downscales. However, draft submissions often remove the full-size image to replace it with the downscaled image previously scraped into Stash. As a result, the summary shows a secretly downscaled image being replaced with itself. An example can be seen here:
Please note that the image being removed on the left is actually 1920x1080, so this edit is unintentionally downgrading a full-size image to a smaller one. But without peolic's userscript, the contributor and most voters can only see two identical images with the exact same resolution. All it would take to correct this edit is to click the "Reset Images" button within the scene edit form. But since Stash-Box shows two identical images, there doesn't appear to be any reason to click that button. Editors can't fix a problem if they don't even know the problem exists.
To Reproduce
Edit a scene that already has a scene cover
Replace the scene cover with an image larger than 1280x720
Make sure to click "Upload", creating the downscaled copy
Click on the "Confirm" tab to view the edit summary
Notice the new image and its displayed resolution is smaller than the original, with no other indication it's been changed or that the full-size image has been preserved
Expected behavior
The edit queue should list the actual sizes of each image. Emulating the current behavior of peolic's userscript would be ideal. In addition to showing accurate resolutions, it provides hyperlinks to both the full-size images and their downscaled counterparts. The userscript also includes tooltips for each hyperlink, which would help to explain the situation to new users. It is now clear that this edit is removing a full-size image and replacing it with a downscaled copy.
The userscript also adds the same (R) hyperlink to the full-size image in the top right corner of the scene details page.
The userscript also performs a similar function for performer images. A resolution is displayed underneath the image carousel, again including the (R) hyperlink for the full-size images that have been downscaled:
It also adds the same resolutions and hyperlinks to the various edit forms (the circled arrow opens a new browser tab):
For the sake of users less familiar with Stash-Box and peolic's userscript, we could slightly change this behavior. I assume the (R) is meant to stand for "resized", but it points to the full-size image instead of the resized one. More confusingly, clicking on "1920 x 1080" in the edit queue will open the image downscaled to 1280x720 and not the full-sized image. It might be best if the full-size resolution labels were a hyperlink to the full-size image and the (R) links pointed to the "resized" images.
There is also less of a need for image resolutions and hyperlinks to be displayed outside of the edit forms and edit queue for most users, so we could leave those additions out of vanilla Stash-Box if we feel it adds too much clutter to the other pages.
It's also worth noting that the solution laid out above still does not address the widespread problem of full-size image covers being replaced by their downscaled copies with draft submissions from Stash. Contributors will still need to recognize that the edit initially tries to downgrade the scene cover and then remember to click the "Reset Images" button to prevent that. However this situation may be mitigated if we could lock down individual fields including scene covers (as explained in issue #213), preventing them from being overwritten by a simple draft submission.
The text was updated successfully, but these errors were encountered:
Hey, it's a weird bug, I didn't detect it in Dev because it is caused by the CDN.
I'm working on a PR right now to fix this. Won't add new features, we can discuss this as a separate thing, but will at least make sure the numbers are correct.
Full resolution images are still hidden without peolic's userscript, but the correct sizes are now listed in the edit queue. Closing as resolved by #724
Describe the bug
This bug is more of an oversight that we've known about for quite some time, but apparently we didn't have an issue to track it yet.
Stash-Box automatically creates a downscaled copy of any image above 1280px in either dimension. For example, scene covers are often downscaled from 1920x1080 to 1280x720. These downscaled images are then served throughout Stash-Box's UI as well as the various Stash-Box scrapers in Stash. This of course is intentional and expected behavior.
The problem is that this behavior is not sufficiently transparent to the user. Once an image has been downscaled, the full-size image is still saved and accessible within Stash-Box. But, it is hidden completely within the UI. This very helpful userscript created by peolic is the only method I'm aware of to find these original full-size images, or to even identify which images have been downscaled. I believe this userscript has become a double-edged sword because the most experienced contributors on StashDB (myself included) often forget that its functionality is not actually available in vanilla Stash-Box yet. This may be why nobody (again, myself included) has taken the time to even write up this issue addressing it yet.
From my perspective this is primarily a problem within the edit queue, but I believe these inconsistencies are apparent elsewhere too. Within the edit summary, the images and resolutions displayed are of the downscales. However, draft submissions often remove the full-size image to replace it with the downscaled image previously scraped into Stash. As a result, the summary shows a secretly downscaled image being replaced with itself. An example can be seen here:
Please note that the image being removed on the left is actually 1920x1080, so this edit is unintentionally downgrading a full-size image to a smaller one. But without peolic's userscript, the contributor and most voters can only see two identical images with the exact same resolution. All it would take to correct this edit is to click the "Reset Images" button within the scene edit form. But since Stash-Box shows two identical images, there doesn't appear to be any reason to click that button. Editors can't fix a problem if they don't even know the problem exists.
To Reproduce
Expected behavior
The edit queue should list the actual sizes of each image. Emulating the current behavior of peolic's userscript would be ideal. In addition to showing accurate resolutions, it provides hyperlinks to both the full-size images and their downscaled counterparts. The userscript also includes tooltips for each hyperlink, which would help to explain the situation to new users. It is now clear that this edit is removing a full-size image and replacing it with a downscaled copy.
The userscript also adds the same
(R)
hyperlink to the full-size image in the top right corner of the scene details page.The userscript also performs a similar function for performer images. A resolution is displayed underneath the image carousel, again including the
(R)
hyperlink for the full-size images that have been downscaled:It also adds the same resolutions and hyperlinks to the various edit forms (the circled arrow opens a new browser tab):
For the sake of users less familiar with Stash-Box and peolic's userscript, we could slightly change this behavior. I assume the
(R)
is meant to stand for "resized", but it points to the full-size image instead of the resized one. More confusingly, clicking on "1920 x 1080" in the edit queue will open the image downscaled to 1280x720 and not the full-sized image. It might be best if the full-size resolution labels were a hyperlink to the full-size image and the(R)
links pointed to the "resized" images.There is also less of a need for image resolutions and hyperlinks to be displayed outside of the edit forms and edit queue for most users, so we could leave those additions out of vanilla Stash-Box if we feel it adds too much clutter to the other pages.
It's also worth noting that the solution laid out above still does not address the widespread problem of full-size image covers being replaced by their downscaled copies with draft submissions from Stash. Contributors will still need to recognize that the edit initially tries to downgrade the scene cover and then remember to click the "Reset Images" button to prevent that. However this situation may be mitigated if we could lock down individual fields including scene covers (as explained in issue #213), preventing them from being overwritten by a simple draft submission.
The text was updated successfully, but these errors were encountered: