Haha it's not that serious.
\n\nIt's just, attempting to solve this problem is DCT space, especially as stenography algorithms improve over time (first, second, and even third derivative distributions are well balanced / hardly perturbed) means it should be increasingly impossible to detect the presence of a hidden message or its encoding scheme using simple stats. Even in cases like ours where we have the source code to generate the embedded images, at least I haven't been able to squeeze any real knowledge out of that.
\n\nOn the other hand, I've realized two things:
\n\nReally enjoying this comp. Wish I got into it sooner / had more time.
", "messages": [ { "id": 929821, "postDate": "2020-07-15T01:54:51.733Z", "content": "Haha it's not that serious.
\n\nIt's just, attempting to solve this problem is DCT space, especially as stenography algorithms improve over time (first, second, and even third derivative distributions are well balanced / hardly perturbed) means it should be increasingly impossible to detect the presence of a hidden message or its encoding scheme using simple stats. Even in cases like ours where we have the source code to generate the embedded images, at least I haven't been able to squeeze any real knowledge out of that.
\n\nOn the other hand, I've realized two things:
\n\nReally enjoying this comp. Wish I got into it sooner / had more time.
", "rawMarkdown": "Haha it's not that serious.\n\nIt's just, attempting to solve this problem is DCT space, especially as stenography algorithms improve over time (first, second, and even third derivative distributions are well balanced / hardly perturbed) means it should be increasingly impossible to detect the presence of a hidden message or its encoding scheme using simple stats. Even in cases like ours where we have the source code to generate the embedded images, at least I haven't been able to squeeze any real knowledge out of that.\n\nOn the other hand, I've realized two things:\n\n1. At least fifteen of the papers I've read on steganalysis feature generation all end up converting back to YCbCr space before doing anything, and\n1. Where in DCT space you may alter a single value +/- 1, at least in RGB space that same single coefficient change is directly spread out over 3x64 pixels. And if convolved with e.g. in effnet a 3x3 kernel, bleeds out even more. This increases—I think—the chance to detect anomalies, at least VS cover images.\n\nReally enjoying this comp. Wish I got into it sooner / had more time.", "votes": 12 }, { "id": 930134, "postDate": "2020-07-15T08:13:31.950Z", "content": "Re: RGB vs. YCbCr I agree working on YCbCr is where the spatial impact of DCT are measured by most stego algos, however I think RGB makes sense if you use pretrained nets that were pretrained w/ RGB images.
\n\nOne idea, no time to test it: could you re-compute the first convolutional filters (commonly named conv_stem) to accept YCbCr instead of RGB?
Think we can combine RGB and YCbCr, for example working with 4 channel Image RGB+Y (cause DCT changed mostly in Y). But agree that for pretrained models our forth channel could be absolutely useless, cause it was not trained to work with Y
", "rawMarkdown": "Think we can combine RGB and YCbCr, for example working with 4 channel Image RGB+Y (cause DCT changed mostly in Y). But agree that for pretrained models our forth channel could be absolutely useless, cause it was not trained to work with Y" } ] }, { "id": 930902, "postDate": "2020-07-15T19:53:19.420Z", "rawMarkdown": "", "votes": -10, "isDeleted": true } ], "comments": [ { "id": 930134, "author_name": "Andrés Miguel Torrubia Sáez", "author_url": "", "post_date": "2020-07-15T08:13:31.950000", "content": "Re: RGB vs. YCbCr I agree working on YCbCr is where the spatial impact of DCT are measured by most stego algos, however I think RGB makes sense if you use pretrained nets that were pretrained w/ RGB images.
\n\nOne idea, no time to test it: could you re-compute the first convolutional filters (commonly named conv_stem) to accept YCbCr instead of RGB?
Think we can combine RGB and YCbCr, for example working with 4 channel Image RGB+Y (cause DCT changed mostly in Y). But agree that for pretrained models our forth channel could be absolutely useless, cause it was not trained to work with Y
", "votes": 0, "replies": [] } ] }, { "id": 930902, "author_name": "", "author_url": "", "post_date": "2020-07-15T19:53:19.420000", "content": "", "votes": -10, "replies": [] } ], "raw_markdown_by_id": { "929821": "Haha it's not that serious.\n\nIt's just, attempting to solve this problem is DCT space, especially as stenography algorithms improve over time (first, second, and even third derivative distributions are well balanced / hardly perturbed) means it should be increasingly impossible to detect the presence of a hidden message or its encoding scheme using simple stats. Even in cases like ours where we have the source code to generate the embedded images, at least I haven't been able to squeeze any real knowledge out of that.\n\nOn the other hand, I've realized two things:\n\n1. At least fifteen of the papers I've read on steganalysis feature generation all end up converting back to YCbCr space before doing anything, and\n1. Where in DCT space you may alter a single value +/- 1, at least in RGB space that same single coefficient change is directly spread out over 3x64 pixels. And if convolved with e.g. in effnet a 3x3 kernel, bleeds out even more. This increases—I think—the chance to detect anomalies, at least VS cover images.\n\nReally enjoying this comp. Wish I got into it sooner / had more time.", "930134": "Re: RGB vs. YCbCr I agree working on YCbCr is where the spatial impact of DCT are measured by most stego algos, however I think RGB makes sense if you use pretrained nets that were pretrained w/ RGB images. \n\nOne idea, no time to test it: could you re-compute the first convolutional filters (commonly named `conv_stem`) to accept YCbCr instead of RGB?", "930902": "" } }