For centuries, saffron has been a prized dye
Bizarre that such a costly substance would be used as a dye for clothing. Why pay what’s likely the equivalent of HP ink when you can just get a box of Rit yellow dye at the supermarket?
Surely the price will drop when someone figures out that drones can fly around and harvest the saffron.
As a test, I enabled js on the onion site and tried again to post from the onion connection. Again my message was simply blackholed. So noscript’s default disabling of JS is not the issue.
(edit) then I posted from the clearnet site mader.xyz… no issue. This problem is onion-specific.
I would assume the extent of the uniqueness is probably unknown at this point. The researchers probably meant uniqueness within a group. Though I suppose the population is small enough that the names could be unique globally.
That was my intuition but then consider this bug in
unpaper
:https://github.com/unpaper/unpaper/issues/230
I have a script that runs unpaper on PGM files. When the DPI is 600, that bug in unpaper is triggered, but no problem if the source is 300dpi. So it means there is a difference. Although I suppose it’s possible that it’s not really DPI that causes unpaper to produce a truncated image; it could come down to sheer number of pixels. Guess I could work that out by testing further with smaller source scans.
The reason for my question is that I’d like to write my script to work around that bug. If a source file has more than 300 dpi, I would use ImageMagick instead of unpaper to do the bileveling.
(update)
I cropped a 600dpi image in half using GIMP. Then fed that into
unpaper
. The bug was not triggered and the full canvas was processed correctly. So I think you are right… DPI is not a concept on PGM files. Which implies unpaper’s bug is simply a limitation on the number of pixels it can handle. It’s apparently incidental that scanning a full size page at 600 dpi results in more pixels than unpaper can handle.