无法解码为与输入相同的长度 [英] Failing to decode as same length as input

问题描述

这是链接使用JAVA在数字图像中嵌入消息，它们还提供了示例代码，但是当我尝试嵌入38个以上的字符时，当我运行解码部分时，它将给出不同的输出。
我正在使用111x115（6.38k）图像。

This is a Link Embedding Messages in Digital Images using JAVA, they provide the sample code also, but when i tried to embed over 38 characters, it will give different output when i run the decode part. I am using 111x115 (6.38k) image.

我的问题在本文中，它说n =（p-32）/ 8，n是消息的最大长度，P是像素数。因此，如果我计算使用的图像，它将为n =（6380-32）/8=793.5。
因为像我可以在该图像中存储793.5个字符，但是当我尝试放置38个以上的字符时，当我对部分内容进行解码时，它将给我不同的输出。 （38个字符以下就可以了）

my question is in this article, it said n=(p-32)/8 , n is the maximum length of message and P is the number of pixels. so if i calculate the image i used, it will be n=(6380-32)/8=793.5. Since like i could store 793.5 characters in this image, but when i tried to put more than 38 characters, it will give me different output when i did decode part. (under 38 character is fine)

推荐答案

对，我发现了这个错误！正如我所期望的，一些像素被覆盖了。问题出在 embedByte 函数中，特别是在for循环的条件下。

Right, I found the bug! And as I was expecting, some pixels were getting overwritten. The problem is in the embedByte function, specifically, in the conditions of the for loops.

for(int i=startX; i<maxX && count<8; i++) {
   for(int j=startY; j<maxY && count<8; j++) {

每个循环都会重复进行，直到您到达行/列的末尾或计数达到8 。当您由于到达行/列的结尾而终止时，会出现问题。为了说明这一点，这就是您的图像发生的情况。

Each loop will iterate until you either reach the end of the row/column or the count reaches 8. The problem arises when you terminate because the end of the row/column has been reached. To demonstrate this, this is what happens for your image.

第一个字符嵌入像素（0，32），（0，33），...， （0，39）。这很简单，直到您到达第11个字符为止。

The first character is embedded in pixels (0, 32), (0, 33), ..., (0, 39). This is all straightforward until you reach the 11th character, where you get the following.

(0, 112)
(0, 113)
(0, 114)
(1, 112)
(1, 113)
(1, 114)
(2, 112)
(2, 113)

造成混乱的原因是（0，114） 。在j = 114时，j循环已达到其极限并退出。由于count还不为8，我们返回到i循环，该循环递增1，然后再次进入j循环，该循环从startY = 112开始。这说明了（1，112）以及接下来的内容。这些像素尚未更改，因为它们将在第25个字符（通常是首次写入）期间被覆盖。相反，您应该获得以下信息：

The reason for this mess is at (0, 114). At j=114, the j loop has reached its limit and exits. Since count is not 8 yet, we go back to the i loop, which increments by 1 and then enters the j loop again, which starts at startY=112. This explains (1, 112) and what comes next. These pixels shouldn't have been changed yet, since they will be overwritten during the 25th character (normally written for the first time). Instead, you should have gotten this:

(0, 112)
(0, 113)
(0, 114)
(1, 0)
(1, 1)
(1, 2)
(1, 3)
(1, 4)

要实现这一点，一旦到达j的边缘，就想重置startY。您可以通过在j循环内添加以下代码来做到这一点。

To achieve this, once you have reached the edge with j, you want to reset startY. You can do this by adding the following code inside the j loop.

if(j==maxY-1) {
   startY = 0;
}

类似地，您想在中添加此更正

Similarly, you want to add this correction in the extractByte function for the decoding process.

因为您可以适应大约出现问题时，这是115个像素中的14个字符。这解释了11-> 25->39。巧合的是，11和25写入的共享像素嵌入了相同的位，并且未表示错误。但是随着39的引入，25受到了影响。

Since you can fit approximately 14 characters in 115 pixels, this is when the problem arises. This explains the 11 -> 25 -> 39. By coincidence, the sharing pixels that 11 and 25 write, embed the same bit and the bug is not expressed. But with the introduction of 39, 25 is affected.

这篇关于无法解码为与输入相同的长度的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！