fujifilm finepix s series

altwho

Yay! I have access to the hidden menu! I found the procedure in a Fujifilm service manual (the manual says it's confidential) http://www.2shared.com/document/F7HOCYRM/fujifilm_s1800_s1880_sm.html Whoops how did that get there?

In any case, the key is to make a directory called HiddenMenu in the SD card root and then do the following procedure:

1. Turn the camera on with the SD card containing the HiddenMenu directory inside
2. Press "BACK/DISP" at the "DATE/TIME NOT SET" screen
3. Press "MENU/OK" button --> "SET-UP" --> Go to the fourth tab from the left --> "RESET"
--> Press LEFT on the d-pad and at the same time (or a fraction of a second later) press the zoom rocker in the TELEPHOTO position (to the right on my S1600)

4. You should now be in the service menu, don't mess around with the calibration. I have not tried all the options and it might be possible to wrongly calibrate your camera. Some of the options require special software that used to be found at https://denhin.fujifilm.co.jp/csg_en/index.htm and http://fujifilm-di.intranets.com, however both of those links are down now. Some of Fujifilm's international subsidiaries still have live websites with presumably the same files, but they require authentication. Maybe someone from a Fujifilm repair center might be able to share those files, given that the cameras in question are mostly discontinued and out of warranty.

natrmnv

Anything (apparently) useful there?

I'm not expecting "enable RAW" and "enable manual focus" checkboxes, just something maybe. =)

apass

natrmnv
Anything (apparently) useful there?

I'm not expecting "enable RAW" and "enable manual focus" checkboxes, just something maybe. =)

Well, yes, you can enable RAW mode as far as I've tested, but only with a quirk. With manual focus - no luck.
Note that step 2 from altwho's post is not required - you can actually enter in the service menu anytime you want once the SD card has the HiddenMenu folder on it by entering the normal setup menu and going to reset option. From the description he gave I had the impression that it was the normal way to start the camera in service mode, but apparently he had the batteries removed from the camera for a long time so date and time settings were lost.
Now, for the RAW mode, start the camera with the hidden menu and go to the "DEBUG" menu (there is also a debugmode - this is not OK). In the debug menu you have the option to turn on SAVEfullYRGB. Default value is off. If you enable the option, the camera will save the raw image (if you have also SAVEfullJPEG on, the camera will save both raw and jpg format). But once you turn off the camera, the camera defaults to normal jpg saving - so that's the quirk. Each time you want to save in RAW mode you have to enter into the debug menu.
Also, the saving time for the raw file is much longer than for the jpg file (in fact, the file is 10 to 20 times larger than the jpg file so also the writing time goes up). With my card, which is just and old SD card (like speed class 1), the saving of the raw image took about 20 seconds. I should try it with higher speed class card when I'll get one in my hands.

For manual focus - there is an option in the DEBUGMODE menu, but I could not figure if it's doing something. In time - I'll experiment with some other options in the service menu.

Later edit - now... there is the problem of opening Fuji RAW formats... as far as I've seen, the Fuji RAW (RAF) world is quite small and closed - so getting from a camera a format that it was not supposed to be supported only begs for further sleepless nights....

jamakawa

😀 I hope soon we will be able to create a firmware for the
S4400 with the functions and RAW and timelapse :lol

jamakawa

apass

natrmnv
Anything (apparently) useful there?

I'm not expecting "enable RAW" and "enable manual focus" checkboxes, just something maybe. =)

Well, yes, you can enable RAW mode as far as I've tested, but only with a quirk. With manual focus - no luck.
Note that step 2 from altwho's post is not required - you can actually enter in the service menu anytime you want once the SD card has the HiddenMenu folder on it by entering the normal setup menu and going to reset option. From the description he gave I had the impression that it was the normal way to start the camera in service mode, but apparently he had the batteries removed from the camera for a long time so date and time settings were lost.
Now, for the RAW mode, start the camera with the hidden menu and go to the "DEBUG" menu (there is also a debugmode - this is not OK). In the debug menu you have the option to turn on SAVEfullYRGB. Default value is off. If you enable the option, the camera will save the raw image (if you have also SAVEfullJPEG on, the camera will save both raw and jpg format). But once you turn off the camera, the camera defaults to normal jpg saving - so that's the quirk. Each time you want to save in RAW mode you have to enter into the debug menu.
Also, the saving time for the raw file is much longer than for the jpg file (in fact, the file is 10 to 20 times larger than the jpg file so also the writing time goes up). With my card, which is just and old SD card (like speed class 1), the saving of the raw image took about 20 seconds. I should try it with higher speed class card when I'll get one in my hands.

For manual focus - there is an option in the DEBUGMODE menu, but I could not figure if it's doing something. In time - I'll experiment with some other options in the service menu.

Later edit - now... there is the problem of opening Fuji RAW formats... as far as I've seen, the Fuji RAW (RAF) world is quite small and closed - so getting from a camera a format that it was not supposed to be supported only begs for further sleepless nights....

:'( you can attach a folder with all the files? Thanks

jamakawa

:'( :'(

apass

I've read forward on the net and noticed that Kodak has basically the same options / menu (maybe they are using the same controller?). Furthermore, I found a converter from some of the Kodak files to bmp (Kodac C-633 and C-330) here http://alexpolter.narod.ru/yrgb2bmp.html.
Google translate worked for me.... A good think there is that it has also the source code available - so maybe it's possible to use it as a reference for reverse engineering.
The bad thing, however, I think the raw files from Fuji are using some kind of compression - this is judging by the file size and by the compression factor achieved while making zip files from them.
Anyway, it seems there are several RAW formats coming from the camera - activated by the options - SaveCFAonTake, SaveCFAonIRP and SaveFullYRGB which are producing DSCOxxxx.raw, CFAIxxxx.raw and YRGBxxxx.raw with the YRGB file having the least compression factor (compressed 50% by zip compared with 25% for the other formats).
As for attaching them - every individual file has a size larger than the attachment limit for the forum, even zipped, so only if you have some other mean of sharing them....

jamakawa

:'(
I sincerely hope
somebody to attach a folder with all files
which will improve the Fujifilm S4400 series
I think it is useful for all this time not exactly rosy
to buy a new digital camera
improving what you have
so far by adding the batch folder was not able to unlock the hidden submenus that let you enable RAW files
trying again and again without ever having success
I look forward to future developments 😀

DragonLord

This is my first post here, and I've got a lot to say after reading this thread and experimenting with my camera. (Note that I have a MinGW development environment on my Windows 7 machine.)

[hr]

I have a Fujifilm FinePix S1800 to fiddle with, and I have gained access to the hidden menu using the procedure mentioned in the thread. The YRGB file really isn't raw output, but is simply an uncompressed copy of the JPEG output. The converter located at http://alexpolter.narod.ru/yrgb2bmp.html (mentioned by apass earlier) requires some source code modification to work with the S1800's output. The changes required are in the following unified diff:

@@ -24,11 +24,15 @@
 } FilePropertyT;
 
 FilePropertyT fileTypes[] = {
-{C633, 2848, 2132, 9107904l},
-{C633, 2848, 1896, 8099712l},
-{C633, 2304, 1728, 5971968l},
-{C633, 1600, 1200, 2880000l},
-{C633, 1024,  768, 1179648l},
+{C633, 4000, 3000, 18000000},
+{C633, 4000, 2664, 15984000},
+{C633, 4000, 2248, 13488000},
+{C633, 2816, 2112, 8921088},
+{C633, 2816, 1864, 7873536},
+{C633, 2816, 1584, 6690816},
+{C633, 2048, 1536, 4718592},
+{C633, 2048, 1360, 4177920},
+{C633, 1920, 1080, 3110400},
 {C330, 2304, 1728, 8239104l, 2384*2}, /*{C330, 2304, 1728, 8239104l},*/
 {0}
 };
@@ -117,9 +121,7 @@
 "Kodak C633/C330 YRGBxxxx.RAW conversion utility. V1.1 (C) SwD 2007\n"
 "Usage: utility [-i] YRGBsrc.RAW output.BMP\n"
 "-i interpolate colors\n"
-"Supported modes (recognised by file size):\n"
-"C633: 2848x2132, 2848x1896, 2304x1728, 1600x1200, 1024x768\n"
-"C330: 2304x1728\n"
+"Modified for the Fujifilm FinePix S1800\n"
 );
 }

Apply the diff to the yrgb2bmp.c file. The modified code builds under MinGW GCC 4.7.2. ~~The bitmap files resulting from conversion are identical at the pixel level to the JPEG output of the camera.~~ (see reply #35)

As it turns out, the file size of the YRGB output is (image_width * image_height * 1.5). The lines in the above diff reflect that, implementing all of the S1800's output sizes.

[hr]

The output from the Take12BitCCDRawImage mode (under Debug in the Hidden Menu), however, is more likely to be real raw data. The file format seems to be a very simple data dump of each pixel, with no compression or other processing. Here are some points to note:

In a hex editor, each pixel is stored as two bytes in little-endian format, since the data looks like "70 00 85 00 32 00 ...". This is surprising because the raw data is supposed to be 12 bits per pixel. However, this characteristic makes decoding the data that much easier because the pattern is readily discernable.
The size of each raw file is exactly 24,482,400 bytes. Given that each pixel is represented by two bytes, there is a total of 12,241,200 pixels. This is not 4000x3000, but 4040x3030. It is normal for raw image data to represent more pixels than JPEG files, since some of the pixels in the extreme edges of the sensor are cropped out for demosaicing and other processing.
Raw output files begin with the letters DSCO. For exposures two seconds or longer, the dark frame is stored in a file beginning with the letters DSCB, with the four-digit image number corresponding to the DSCO file.

With this information in mind, it looks fairly easy to write a program to convert the raw data to TIFF, DNG, or other common format. (I mention TIFF because TIFF supports 16 bits per pixel; DNG is probably a bit too complicated to do in a brief project). Of course, further study of the format is needed to fully understand it. Sadly, I'm not skilled enough to write a program to do this. It would be nice to see someone actually write such a program...

--DragonLord

DragonLord

Further testing shows that the Take12BitCCDRawImage mode will not work unless the DCIM folder on the memory card contains at least one subfolder with a name within the range 100_FUJI to 999_FUJI. If this requirement is not satisfied, the data will not be written correctly onto the memory card.

--DragonLord

apass

Nice work DragonLord!

I didn't have the time to look further in the topic.... so no news from me.
However, either something doesn't add up, either I don't understand the relation between camera resolution an sensor resolution.
I mean - if the raw ccd dump has 2 bytes per pixel, where are the color sub-pixels? I would have expected, for a 4000 x 3000 resolution, with 12 bits per color, to have around 4000 x 3000 x 1.5bytes x 4subpixels = 72MB. Or at least around that value. So how come the output file has only 2 bytes per pixel?
About the YRGB file - have you made the difference between the bitmap file and the jpeg file and the result was 0? Or have you compared them only visually? Like I said, I didn't look forward into the C code to see how the data is converted so I may ask - at what stage in the JPEG conversion is this YRGB file saved?
As a note - the 1.5 scale between image size and file size makes for 12 bit per pixel.
Another point, with the exception of YRGB file, all other files seem to have around one byte per pixel (one of them is a bit larger, maybe a header in the file with some other info) - so again, where are the color subpixels? Or, again, they are some intermediate file from the JPEG conversion?

srsa_4c

apass
I mean - if the raw ccd dump has 2 bytes per pixel, where are the color sub-pixels? I would have expected, for a 4000 x 3000 resolution, with 12 bits per color, to have around 4000 x 3000 x 1.5bytes x 4subpixels = 72MB. Or at least around that value. So how come the output file has only 2 bytes per pixel?

See the following wiki article: https://en.wikipedia.org/wiki/Bayer_filter

As a note - the 1.5 scale between image size and file size makes for 12 bit per pixel.

That will be one of the YUV image formats.
Hope that helps.

DragonLord

apass
Nice work DragonLord!

I didn't have the time to look further in the topic.... so no news from me.
However, either something doesn't add up, either I don't understand the relation between camera resolution an sensor resolution.
I mean - if the raw ccd dump has 2 bytes per pixel, where are the color sub-pixels? I would have expected, for a 4000 x 3000 resolution, with 12 bits per color, to have around 4000 x 3000 x 1.5bytes x 4subpixels = 72MB. Or at least around that value. So how come the output file has only 2 bytes per pixel?
About the YRGB file - have you made the difference between the bitmap file and the jpeg file and the result was 0? Or have you compared them only visually? Like I said, I didn't look forward into the C code to see how the data is converted so I may ask - at what stage in the JPEG conversion is this YRGB file saved?
As a note - the 1.5 scale between image size and file size makes for 12 bit per pixel.
Another point, with the exception of YRGB file, all other files seem to have around one byte per pixel (one of them is a bit larger, maybe a header in the file with some other info) - so again, where are the color subpixels? Or, again, they are some intermediate file from the JPEG conversion?

The S1800 and kin, like most cameras, uses a Bayer filter, as srsa_4c has noted. Each pixel represents one and only one of the additive primary colors: red, green, and blue. A process called demosaicing is used to combine the color data in the pixels to create a full-color image.

I'll take a closer look at the converted YRGB/BMP output and see how it compares with the JPEG output when I get a chance.

--DragonLord

DragonLord

There are extremely subtle differences between the JPEG and the converted YRGB/BMP output. However, I did find an oddity when examining the YRGB file: the data seem to be organized in individual bytes, not in 12-bit groups, for that the bytes read like "80 85 87 ...". Perhaps the source code of the YRGB2BMP converter would explain what's going on?

--DragonLord

apass

srsa_4c

apass
I mean - if the raw ccd dump has 2 bytes per pixel, where are the color sub-pixels? I would have expected, for a 4000 x 3000 resolution, with 12 bits per color, to have around 4000 x 3000 x 1.5bytes x 4subpixels = 72MB. Or at least around that value. So how come the output file has only 2 bytes per pixel?
See the following wiki article: https://en.wikipedia.org/wiki/Bayer_filter

As a note - the 1.5 scale between image size and file size makes for 12 bit per pixel.
That will be one of the YUV image formats.
Hope that helps.

Yes, I know about Bayer filters - that's why I said 4 subpixels (2 green + red + blue). And I though that image sensors are using a similar approach as the displays - i.e. each pixel generated consists of separate subpixels which are used to generate the color information at the current pixel location.

DragonLord

Examination of the YRGB/BMP output and the JPEG output at 400% indicates that the YRGB/BMP file is free of compression artifacts. However, the data has already been processed with noise reduction and other in-camera processing steps. The YRGB2BMP converter contains an option -i which performs interpolation; the interpolated output has smoother color transitions at the cost of a small amount of fine detail. The difference between the interpolated and the non-interpolated output is extremely subtle in viewing, and aggressive processing of all files (with BMPs converted to TIFF using Windows Paint) using a 32-bit floating-point image processing program (RawTherapee) indicates very minor differences in tonal range.

I suspect that if we can decode the Take12BitCCDRawImage output, then we will get truly unprocessed data that has more latitude for manual processing than the JPEG or YRGB files.

[hr]

On another note, the DebugMode menu allows the selection of ISO sensitivity settings between 50 and 3200 in 1/3 stop steps, with additional steps between ISO 100 and ISO 400. Unfortunately, setting ISO 3200 through this menu produces invalid output, so the highest ISO possible is ISO 2500 at full resolution. Of course, the result is very, very ugly—both of my Pentax DSLRs produce usable output at these sorts of sensitivity levels, but the same can't be expected of a camera with a sensor only 1/13th the surface area of an APS-C sensor. The S1800's rather poor noise reduction algorithms aren't really helping here, either.

--DragonLord

DragonLord

The SaveCFA files appear to contain 8 bits per pixel data from the sensor prior to demosaicing. The file represents a 4040 x 3030 image size. This is the raw size of the sensor, and is probably very easy to decode as simple RGB data. Once we decode the data, it should be possible to determine the difference between SaveCFAonTake and SaveCFAonIRP.

--DragonLord

a1ex

Can you upload a sample from Take12BitCCDRawImage? I can try to take a look.

apass

I've been looking in the source code and I believe I understand why the YRGB file is 12 bits / pixel. As per the comments in the source code, the data bytes are organized as:
Y Y Y Y
Cb Cr Cb Cr
Y Y Y Y
Y Y Y Y
Cb Cr Cb Cr
Y Y Y Y

This actually gives a 4 x 4 pixel matrix. First pixel in the first line uses the first Y value and first Cb Cr values from the second line. The second pixel on the first line uses the second Y value and same Cb Cr values as the first pixel. Ne next pixel row starts at the 3 row in the above table - so the first pixel from the second pixel row uses the Y value from the third line and Cb Cr values from the second line in the table. This means that a group of 2 x 2 pixels (4 pixels) uses 6 bytes of data => 1.5 bytes / pixel. I hope I has clear....

Another point, the other format for the Kodak camera looks like 2 bytes / pixel - I don't know what test image did you use, but if would have been a gray image, the pattern would look like 80 00 80 00 as there would be no information in Cb Cr pixels. So I wonder - can you try to decode the ccd raw file with the other Kodak file format (c330) - given the input image size of 4040 x 3030? At least to see if it's possible to get something - good or not!

DragonLord

~~https://dl.dropboxusercontent.com/u/64649057/DSCO0001.RAW~~
10mm (56mm equiv. 135) 2s f/4 ISO 50

The image is of a red Douglas stuffed dragon, on an off-white table and shot against a yellow background. Please note that I may remove this image after one week or so because I'm trying to avoid using too much space on my Dropbox, so you might want to keep a copy and upload it yourself to an appropriate location.

Edit: off-topic rant: I have had enough seeing deceptive ads with the big download buttons. These are Google AdWords image ads served through Google AdSense. They violate the AdWords Advertising Policy for image ads as "trick to click", so why hasn't Google rejected these ads? I ended up reporting the ads at https://support.google.com/adwords/contact/feedback.

Edit 2: The link has been taken down.

--DragonLord

« Previous Page Next Page »